Meet us at conferences around the world
SBC Summit Lisbon
SiGMA Europe
AI agents will not just recommend purchases — they will initiate payments. Merchants and PSPs need a way to verify that the agent is authorised, limited, and traceable.
For two decades, every card payment assumed a human at the end of it — someone who saw a checkout, read a one-time code, and tapped confirm. Agentic payments break that assumption. An autonomous software agent holds a scoped mandate from the user and completes the purchase without a person in the loop. The question stops being “how do we authenticate the cardholder” and becomes “how do we authorise the agent, and prove it stayed within what the user allowed”.
An agentic payment is a transaction that an AI agent initiates and authorises on behalf of a user, within a mandate the user granted beforehand — a spending limit, a category, a merchant set, a time window. The agent is not just suggesting a purchase; it is the party that pulls the trigger. That distinguishes it from today's automation, where a human still approves the final step.
In simple terms. Agentic payment means that a user gives an AI agent limited permission to make a payment. The agent can only pay within the rules set by the user — for example, a spending limit, merchant type, or time window. The payment system must then verify that the agent followed those rules.
Three things have to be true for a payment to be “agentic”: the agent acts autonomously inside its mandate, the mandate is verifiable by the parties downstream, and the whole action is attributable to a specific agent identity for audit and dispute purposes.
Strip away the branding and the flow has four beats.
Intent: the agent decides a purchase satisfies the user's goal.
Authorisation against a mandate: the agent presents a scoped credential and the mandate is checked — is this merchant, amount and category inside what the user permitted?
Execution: the transaction is routed to an acquirer like any other, but the risk signals now describe an agent, not a browser session.
Reconciliation: the action is logged against the agent's identity so it can be explained, capped, or revoked later.
The payment rails underneath do not have to be reinvented. What changes is the authorisation layer that sits in front of them — where the mandate lives and how it is proven.
Agentic payments do not only change who clicks “pay”. They change what PSPs and merchants need to verify before approving a transaction: the agent’s permission, the limits of that permission, and the proof that the agent stayed within them.
Authentication moves from the person to the mandate. 3-D Secure was built to answer “is the cardholder present”. With an agent there is no cardholder present by design, so the trust shifts to scoped, revocable credentials and the proof that the agent acted inside them.
Fraud and risk models change shape. An agent has no device fingerprint or behavioural pattern in the human sense; it has a mandate, a rate, and a history. PSPs that can score “is this within the agent's allowance and normal behaviour” will approve good agent traffic that legacy models would decline as anomalous.
Credential handling gets stricter. You do not hand an autonomous agent a raw card number; you give it a tokenised, limited credential it can spend but not exfiltrate. Tokenization stops being a nice-to-have and becomes the substrate of the whole model.
The hard part of agentic payments is not moving money. Payment rails already do that. The harder question is trust: how can a PSP or merchant know that the agent was allowed to act, stayed within its limits, and can be identified later if something goes wrong?
Three trust elements matter most:
1. MandateA mandate defines what the user authorised the agent to do. It should be machine-readable, limited, and revocable — for example, by amount, merchant category, or time window.
2. Scoped credentialA scoped credential is the spend-limited token the agent presents when making a payment. It lets the agent pay within approved limits without exposing raw card data.
3. Verifiable agent identityA verifiable agent identity makes the transaction attributable to a specific agent. This matters for audit, reconciliation, fraud review, and disputes.
Standards for agentic payments are still forming. For now, the safest approach is to keep mandates, credentials, and agent identity explicit and flexible, rather than hard-wiring them to one early technical model.
Agentic payments are often discussed from the customer side: an AI agent finds a product, completes checkout or makes a purchase on a user’s behalf. A separate operational use case is emerging on the merchant side. A merchant or PSP connects an AI assistant to its payment gateway so that authorized teams can ask questions about transactions, statuses, routing and reporting in plain language.
The AI assistant provides the natural-language interface, while the Model Context Protocol (MCP) standardizes how it talks to the payment platform.
In Payneteasy’s implementation, access is read-only and controlled through a restricted token tied to the relevant environment and account permissions. The assistant can inspect permitted operational data, but the exposed MCP tools cannot initiate, modify or refund transactions.
How is access controlled?The AI assistant connects to the payment platform’s MCP endpoint and authenticates with a restricted access token. The token determines which operational data the assistant can retrieve.
The connector is designed not to expose raw card data such as PAN or CVV. This separation helps minimize data exposure and additional compliance impact. However, whether a specific deployment changes an organization’s PCI DSS scope depends on the complete architecture, network connections and security controls, and should be confirmed by the organization’s compliance team or QSA.
Read-only access is not simply a product limitation. It is a risk-control model.
1. Payment authority remains boundedThe connector cannot create, modify, cancel or refund transactions. An incorrect answer therefore cannot directly become an incorrect payment action.
Read-only access does not eliminate every risk. Incorrect responses, unauthorized disclosure of operational data and compromised access tokens still need to be addressed through access controls, monitoring and token management.
2. Data exposure is minimizedThe assistant works with permitted operational records, transaction states and aggregated statistics rather than raw card credentials. Access can also be restricted and revoked without giving the AI assistant general access to the payment platform.
3. Activity can be auditedWhen each assistant or integration uses identifiable credentials and the platform records its requests, queries can be attributed to a specific integration and reviewed later.
Auditability therefore depends on how identity, token issuance and logging are configured; it is not guaranteed by MCP alone.
Some payment MCP implementations may also expose write operations. Payneteasy takes a different approach with MCP Agent Access: it keeps AI-assisted analysis separate from payment execution.
This is not only a conceptual model. Payneteasy provides documented production and sandbox MCP endpoints, a product page and a setup guide that technical teams can inspect and test. The connector operates alongside the Payneteasy platform used for payment orchestration by merchants and PSPs.
For teams evaluating agentic payments, the practical next step is to explore MCP Agent Access and determine how read-only AI access could support payment operations within their existing orchestration setup.
You do not prepare for agentic payments by rebuilding your stack; you prepare by making three capabilities first-class. Granular authorisation — the ability to express and enforce “this credential may spend X, here, until then”. Tokenization by default — agents never touch raw pan. A clean audit trail — every transaction attributable to an identity, capped and revocable. A platform that already orchestrates routing, risk and tokenization across acquirers is most of the way there: the agent simply becomes another authorised initiator inside controls you already run.
For merchants and PSPs, this is where payment orchestration becomes especially important. Payneteasy brings routing, tokenization, risk controls, and reconciliation into one layer, helping teams prepare for new payment scenarios without adding unnecessary operational complexity.
No. A subscription is a fixed, pre-agreed charge on a schedule. An agentic payment is decided by an agent at the moment of need, within a mandate — the amount, merchant and timing are not fixed in advance.
Not the rails themselves. Authorisation, clearing and settlement work as today. What is new is the authorisation layer in front: the mandate, the scoped credential, and the agent's verifiable identity.
Trust shifts from “is the cardholder present” to “did the agent act inside its mandate, at a normal rate, with a valid scoped credential”. Tokenisation and revocable mandates contain the blast radius if an agent is compromised.
Make granular authorisation, tokenisation-by-default and a per-identity audit trail first-class. Those are the same controls that make orchestration and risk management strong today, so the work compounds.
An AI connector links an AI assistant to a payment gateway so it can observe transactions, statuses and reporting and answer questions about them. The AI connection is the benefit; MCP (Model Context Protocol) is the mechanism that provides it. In Payneteasy’s implementation — MCP Agent Access — the access is merchant-scoped and read-only.
The agent authenticates with a merchant-scoped token that can only observe operations data over MCP. Read-only matters for compliance: the agent cannot move money, no cardholder data crosses the connection (no new PCI scope), and every query stays attributable and auditable.
No. They are the two sides of agentic payments. An agent-as-buyer initiates a payment on a user’s behalf under a mandate; an AI connector is the operations side — the agent observes and explains what happens inside a merchant’s own gateway, without touching the money flow.
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
