Meet us at conferences around the world
SiGMA Europe
Seven questions to ask any payment vendor before an AI assistant touches your transaction data: what it can read, what it can never do, and who controls access.
More payment teams want to ask an AI assistant about their transaction data directly instead of exporting reports. Before connecting one, it helps to know what to ask the platform that holds that data. "Does your platform support AI?" tells you little.
The questions below focus on what an assistant can read, what it cannot do, what reaches its context and who controls access, and they apply to any payment or orchestration platform.
Payment operations teams spend much of their time on questions like why approvals dropped or what happened to a specific order. An assistant that can query the data directly can shorten that work. The concern is rarely whether the assistant is capable enough. It is whether connecting it opens a path to payment actions, platform settings or raw card data.
The Model Context Protocol (MCP) gives assistants a standard way to query a system's data and tools. MCP is a protocol, not a security model: a server can expose tools that only read, tools that take actions, or both. What a given server exposes is the vendor's design decision, so it is worth asking about directly.
Why it matters. An assistant that can only read may misinterpret data, but it cannot act on the misinterpretation.
What a clear answer looks like. A specific list of what the assistant cannot do through the AI interface: authorise, capture or refund payments, initiate payouts, move funds, change platform settings.
What to watch for. "The agent only does what you ask it to." That describes intended use, not a boundary.
Why it matters. Payment platforms usually have more than one route to an action: a processing API, a back-office API, a virtual terminal. Knowing all of them tells you where the real controls sit.
What a clear answer looks like. Each route is named, and the AI interface does not hand tasks to any of them automatically.
What to watch for. The AI interface shares credentials with an API that can execute payments or change configuration.
Why it matters. Anything returned to an assistant can end up in prompts, logs and chat histories.
What a clear answer looks like. No raw PAN or CVV is returned, and the vendor states what is returned instead, such as aggregates, card metadata or masked fields.
What to watch for. "It's encrypted", with no word on what the assistant actually sees. Also be careful with any claim that an AI connection removes PCI DSS obligations: your scope is assessed with your QSA.
Why it matters. The credential defines what the assistant can reach, for how long, and how quickly you can cut it off.
What a clear answer looks like. A restricted, time-bounded and revocable token, with documented limits on both the tools it can call and the merchant or project data it can access. These restrictions are enforced on the server, with sandbox and production credentials kept separate.
What to watch for. The assistant connects through an administrator login or a long-lived shared API key.
Why it matters. Support for a named assistant can depend on requirements, such as remote MCP support or a specific authentication method, that your corporate environment may not meet.
What a clear answer looks like. Documented setup for each client, with the requirements stated.
What to watch for. A list of supported assistants with no setup documentation.
Why it matters. The AI assistant is one consumer of the platform. Your own tooling and code generators are others, and they work best from a published specification.
What a clear answer looks like. Published OpenAPI specifications for each API, with the version stated.
What to watch for. Prose documentation only, or a specification available "on request".
Why it matters. An AI layer inherits the risk posture of the platform underneath it. A technology provider, a payment facilitator and an aggregator carry different responsibilities.
What a clear answer looks like. The vendor's role is stated plainly and supported by its contracts and funds-flow documentation. Compliance claims are checked separately through a current PCI DSS Attestation of Compliance and applicable card scheme registries; these do not by themselves establish the vendor's settlement responsibilities.
What to watch for. An unclear role, or certifications with no way to check them.
Answers given on a call are a starting point. A short sandbox pilot shows how the platform behaves in practice:
To show what specific answers look like, here is how one platform answers the seven questions, based on its public documentation. Payneteasy publishes this blog, so treat the table as a reference format and ask other vendors for the same level of detail.
| Question | Answer from Payneteasy's documentation |
|---|---|
| 1. Write methods | Through MCP, the assistant cannot authorise, capture or refund payments, initiate payouts, move funds or change platform settings. |
| 2. Separate layers | MCP reads and explains operations data; a separate UI API handles explicitly permitted back-office actions; the Processing API handles payment operations. MCP does not hand tasks to either API. |
| 3. Card data | No raw PAN or CVV. MCP returns aggregates, statuses, routing information, card metadata and masked contacts. |
| 4. Credentials | A restricted token controls which MCP tools are available. It can be time-bounded and revoked; production and sandbox credentials are separate. |
| 5. AI clients | Setup is documented for Claude Desktop, Claude Code, Cursor, VS Code with GitHub Copilot Agent Mode and other MCP clients. ChatGPT connects where the corporate environment supports remote MCP and the required authentication. |
| 6. Machine-readable APIs | The Processing API has an OpenAPI 3.1 specification. The UI API has an OpenAPI 3.0.1 specification covering 130+ services and 1,500+ operations; what an integration can call depends on its access level. |
| 7. Role and verification | A technology and orchestration platform, not a bank, payment facilitator or aggregator, and not a party to merchant settlement risk. PCI DSS Level 1, Visa Global Registry of Service Providers, Mastercard SDP; 20+ years of operation. |
Read more: MCP product page, UI API overview, Processing API OpenAPI spec, Trust & Verification. Day-to-day use cases are covered in Let AI Agents See Payment Data.
Use the seven questions in your next vendor review and back the answers with a short sandbox pilot. If Payneteasy is on your list, its MCP guide documents setup and the tools available.
No. MCP is a protocol, and a server can expose tools that read, tools that act, or both. Check the list of tools the server exposes and the scope of the credential you are given.
No. It limits what the assistant sees, but your overall PCI DSS scope depends on your whole integration and is assessed with your QSA.
For payment operations, a cautious setup keeps the assistant on the read side. A person reviews each recommended action and carries it out through the system and credentials already approved for it.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
