Agentic Payments Explained: How AI Agents Can Participate in Commerce Safely

What is an agentic payment, exactly?

An agentic payment is a transaction in which software acting on a person’s behalf carries out the shopping steps — interpreting a goal, searching, comparing, selecting and submitting the order — and then presents a payment credential to the merchant’s checkout. Current state: the agent is a new kind of buyer-side actor. It is not a new payment rail, a new network, or a new form of money.

The distinction matters because most of the confusion around the term comes from collapsing two different things. An assistant that produces a shortlist and hands the customer a link is doing nothing a payment system has to know about. An agent that submits a credential to a checkout is, and everything difficult about agentic payments lives in that second case.

Emerging state: the card networks and standards bodies are working on how an agent identifies itself, how a merchant recognises it, and how a cardholder’s permission travels with the request. That work sits in specification and pilot form, not in general merchant availability. Nothing on this page describes a capability a merchant can switch on at checkout today.

Where does the AI agent’s job end and the payment system’s begin?

The agent’s job ends at initiation. It can form intent, choose a merchant and a product, assemble an order and present a credential. From there the payment system does what it has always done: authenticate the cardholder or the credential, send the authorization to the issuer, apply network rules, and settle funds to the merchant. Current state: no agent authorizes its own payment.

This is the spine of the whole subject, so it is worth stating in the negative. An agent does not decide whether a transaction is approved — an issuer does. An agent does not establish that a cardholder is present and consenting — authentication does, and in card-not-present commerce that means EMV 3-D Secure and the issuer’s own risk assessment. An agent does not move money — the acquirer and the networks do, on the same settlement cycle as any other transaction.

Keeping that line clear is the most useful test a merchant can apply to any agentic-commerce claim. If a proposal implies the agent takes over an authentication or an authorization step, it is either describing something outside the card networks entirely or describing something that does not exist yet. Ask which of the two it is, and expect a straight answer.

Why is delegated authority the hard part?

Because a payment system is built to answer one question — is the rightful cardholder behind this? — and an agent breaks the assumption that the answer is a person at a screen. The authority to spend has to move from the human to the software in a way that is provable after the fact, bounded in scope, and revocable at any moment. Neither tokenisation nor authentication solves that on its own.

Delegation has three failure modes and they are not the same problem. The agent can exceed what it was told, buying more or buying elsewhere. The agent can be manipulated by content it reads — a product page, a review, an email — into doing something the customer never asked for. And the agent can be impersonated, so that a request claiming delegated authority never had any. A control that handles one of these does not handle the other two.

The answer to all three has the same shape: make the grant explicit, make it narrow, and make it verifiable independently of whatever the agent says about itself. That is why the emerging work concentrates on credentials and mandates rather than on making agents more trustworthy. Trust in the agent is not a control. A bounded credential is.

How does a mandate record what a customer actually agreed to?

A mandate is a recorded statement of what a customer authorized an agent to do: which merchant or category, up to what amount, over what period, and with what expiry. Emerging state: the requirement is clear enough — the record has to be created at the moment of human consent, travel with the transaction, and be checkable by parties other than the agent — but no single format is settled and none is generally available to merchants.

The mental model already exists in card-on-file consent for recurring billing. A subscription works because the cardholder agreed once, that agreement is recorded, the merchant can evidence it in a dispute, and the customer can withdraw it. An agent mandate is the same idea with tighter bounds and a shorter life — one shopping task rather than an open-ended relationship.

Two consent models are under discussion and they behave differently. Under a per-task grant, the customer approves a specific job and the authority dies with it, which is the safest and the most tedious. Under a standing grant, the customer sets rules once and the agent operates inside them, which is convenient and puts far more weight on those limits being enforced correctly. Neither has been settled as the default, and a merchant evaluating a partner should ask which one it implements.

How do tokenisation and scoped credentials act as the control surface?

Tokenisation replaces a card’s primary account number with a token, and an EMV payment token can be constrained in how it may be used — restricted to a particular merchant, device or payment scenario. Current state: that restriction mechanism exists and runs in production for wallets and card-on-file. It is the same mechanism the agentic proposals reach for, because a scoped token is a spending limit the network enforces rather than one the agent promises to respect.

The property that makes it useful for delegation is containment. A credential that only works at one merchant, on one channel, cannot be repurposed by an agent that has been manipulated and cannot be replayed by anyone who intercepts it. It also fails safely: revoking a token ends the agent’s ability to spend without touching the underlying card, so a customer does not have to reissue plastic to withdraw permission.

Emerging state: what does not yet exist as a general merchant-facing standard is a way to bind a scoped token to a specific mandate and a specific agent identity, so that an issuer or acquirer can check that this agent, holding this permission, is the one presenting this token. The raw material is there — tokenisation, 3-D Secure data, network identifiers. Assembling it into an interoperable scheme is exactly what the standards work is for, and it is not finished.

Which merchant-side controls already apply to agent-initiated traffic?

All of them. An agent-submitted order arrives through the same checkout, the same gateway API and the same authorization path as any other card-not-present transaction, so existing velocity rules, address and CVV checks, 3-D Secure policy, rate limits, idempotency keys and webhook signature verification apply unchanged. Current state: a merchant does not need a separate agent control plane in order to have controls that bite.

Two of those controls do more work than usual here. Idempotency matters because an agent that retries after a timeout is a machine, and machines retry quickly; an idempotency key is what stops a retried order from becoming a second charge. Rate limiting matters because the traffic shape of automated buyers is not the traffic shape of humans, and the first sign that something has gone wrong is usually volume rather than content.

PCI DSS does not change either. Card data handled in an agent-driven flow is still card data, the same scope questions apply, and a hosted checkout or hosted-fields integration keeps a merchant’s scope where it already was. Anyone proposing an agentic integration that requires you to accept raw card data on your own servers is proposing that you enlarge your compliance scope, and that is a decision rather than a technical necessity.

What is genuinely unsettled: liability, dispute evidence and escalation

Liability first. If an agent buys the wrong item, buys at the wrong price, or is manipulated into buying at all, it is not settled who absorbs the loss: the cardholder who delegated, the agent platform that acted, the issuer that approved, or the merchant that shipped. Dispute rules were written around whether a person authorized a transaction, and that binary does not cleanly describe a delegated purchase.

Evidence is the second open question. A merchant defending a dispute today produces delivery confirmation, terms acceptance and the record of the cardholder’s consent. In a delegated purchase the equivalent evidence is the mandate and the agent’s decision trail, and there is no agreed standard for what a merchant is entitled to receive, retain or present. Until there is, an agent-initiated dispute gets defended with the records a merchant already keeps.

Escalation is the third. A well-designed agentic flow has a defined point at which the software stops and asks a human — a threshold amount, an unfamiliar merchant, a changed price, an ambiguous instruction. Emerging state: where that line sits, and who is accountable for enforcing it, is a design choice made by agent platforms rather than a rule imposed by the payment system. A merchant should assume it varies between platforms and ask.

None of this makes the model unsafe to build on eventually. It means the allocation of loss is currently governed by contract and platform policy rather than by a settled network rule, and anyone who tells you otherwise is describing their own terms of service rather than an industry position.

What should a Canadian merchant do about agentic payments today?

Understand it and leave your checkout alone. Current state: there is no general agentic-payments standard for a merchant to integrate, so re-architecting checkout for one would mean building against something that has not been fixed. The useful work is inventory — know which of your existing fraud, authentication and API controls would apply if automated buyers arrived tomorrow, because those are the controls you would use.

There is one Canadian point worth knowing. Under the Retail Payment Activities Act, payment service providers performing retail payment activities in Canada register with and are supervised by the Bank of Canada, and are required to manage operational risk, respond to incidents and safeguard end-user funds. If a third party proposes to initiate payments or hold funds in an agent-driven flow on your behalf, whether they are registered is a real question to ask rather than a formality.

A short list of things worth doing now, none of which is a bet on a particular future. Confirm your checkout does not break for a fast, non-human client that fills fields in milliseconds. Make sure your product and price data is accurate everywhere a machine can read it, because an agent acts on what it reads rather than on what you meant. Keep idempotency on every write path. And keep a clean record of what each customer agreed to, which is good practice regardless of who clicked.

Then wait for the specifications. When an interoperable scheme exists it will arrive through the networks and your acquirer, the way EMV 3-D Secure and network tokenisation did, and it will come with test environments and certification. That is the point at which building makes sense. Building before it is not being early — it is building against a moving target with no test suite.