How I Connected ChatGPT and Claude to a Laravel SaaS (Safely) with MCP

Why I connected QistPay to ChatGPT and Claude

QistPay is an installment management SaaS I built. Shops that sell phones, bikes and appliances on monthly payments use it to track orders, customers, installments, branches and investors.

The people running these businesses are busy. They don't want to click through five screens to find out how much is due this week. They already chat with AI assistants every day, so the natural next step was: let them ask their own business data a question in plain language, and let the assistant do routine work like recording a payment, with the owner staying in control.

What MCP is, in plain language

MCP is an open standard, supported by both ChatGPT and Claude, for connecting an AI assistant to an outside system. Your app publishes a list of tools (for example search_orders or record_installment_payment), each with a clear description and input fields. The assistant reads that list, decides which tool fits the user's request, and calls it.

Think of it as an API designed for an AI to use, with your existing login and permissions still in charge.

Step 1: Start read-only

The first version could only read: business context, branches, dashboards, orders, invoices, installments, transactions and activity logs. Nothing could be created or changed.

This let real users try it with zero risk, and it showed me which questions people actually ask. Read-only is also the default today: when a business connects, it gets read access only unless write access is explicitly granted.

Step 2: Real login, with the owner choosing what to share

Connecting uses OAuth 2.1, the same "Sign in with…" flow people already know. The user logs into QistPay on QistPay's own page and approves the connection. ChatGPT or Claude never sees their password.

Access is split into scopes, small permission slices such as reading finance data or writing installments:

• Read scopes for profile, branches, operations, finance and invoices are the default.
• Write and delete scopes (orders, installments, transactions, catalog, branches) are never requested by default. They are separate, opt-in slices.
• Access tokens expire after an hour and refresh tokens rotate, so a leaked token has a short life.

Step 3: The AI can never do more than the person could

Scopes limit the connection. But QistPay also has staff roles: a cashier shouldn't see investor ledgers, for example. So every single tool call re-checks the user's current QistPay permissions at that moment.

If an owner removes someone's access at 3pm, that person's AI assistant loses it at 3pm too, not whenever a token happens to expire. The AI's access is always the overlap of what the connection allows and what the person is allowed to do in QistPay right now.

Step 4: Guardrails on anything that changes data

This is the part most "AI integration" demos skip, and the part that matters most for a finance product. AI assistants retry requests, misread names, and sometimes get confidently wrong. The system has to make those mistakes harmless.

No duplicate payments: idempotency keys

Every action that changes data must include a unique idempotency key. If the assistant's connection drops and it sends "record 5,000 payment" again, QistPay sees the same key and returns the original result instead of recording the payment twice.

No surprise deletions: preview, then confirm

Deleting an order, an installment or a payment is a two-step process:

1. The assistant calls a preview tool, which describes exactly what would be deleted and what else it affects.
2. The preview returns a confirmation token valid for five minutes. The delete only works with that exact token.

The token is tied to the specific user, connection, business, branch, record, inputs, and the record's current state. If anything changes between preview and delete, such as someone else editing the order, the token stops working and the assistant has to preview again. The AI can't delete something it hasn't just shown you.

No guessing which branch

Many QistPay businesses have several branches. Every branch-level tool requires an explicit branch, so the assistant has to ask or look it up rather than silently picking one.

The assistant is told to confirm with the person

The server also gives the assistant written instructions: ask for missing details one at a time, check whether a customer already exists before creating one, read the full action back in plain language, and wait for an explicit "yes" before writing anything.

Step 5: Every action is logged

Every tool call writes an audit record: who, which business and branch, which AI connection, which tool, the inputs (with secrets removed), the result and how long it took. If an owner asks "who changed this installment?", there's a clear answer, whether a person or their AI assistant made the change.

There's also a global off switch: one setting disables the whole integration instantly, and another forces read-only mode.

Beyond the code

• Tests: automated tests cover the login flow, token refresh, scope filtering, role checks, per-business data separation, idempotency and delete confirmations.
• Legal: the privacy policy and terms now include an AI-assistant section explaining that users should review actions their AI connection takes.
• Docs: a public page explains what the connection can and can't do, so customers know what they're approving.

Should your SaaS add an AI connection?

It's worth it if your users repeatedly look things up or do routine data entry in your app, and if they already use ChatGPT or Claude. Before you start, check that you have:

• A clean permission model you can check on every request
• Clear tenant or account separation, so one customer's AI can never reach another customer's data
• A plan for idempotency and confirmations before you allow any writes
• Logging you'd be comfortable showing a customer

If those are in place, a read-only connection takes weeks, not months. Writes take longer, and they should.