🤖 Agentic payments around the world

Three things the word “agentic” lumps together

An agentic payment is a payment triggered by software acting on behalf of a person or a business. The term covers three distinct mechanisms, with different players, different risks, and different rails. The first is software that drives a browser and fills in a checkout form in place of a human. The second is an agent that calls a commerce API exposed by the merchant or its provider and obtains a delegated payment credential. The third is a machine paying another machine, per unit, with no account set up in advance. Which of the three a payment flow falls into determines what the issuer sees, which rail is used and, through that rail, what recourse the payer has.

A payment rail is the infrastructure that moves funds from payer to payee. Putting an agent in the loop does not change it. An agentic purchase in 2026 runs on a tokenized card, an account-to-account transfer, or a stablecoin; no agentic protocol has created a new payment method. The protocols add an authorization layer in front of rails that already existed. A business accepting these payments keeps its acquirers, its schemes, its settlement times, and its dispute rules.

• The rail determines the recourse regime, not the protocol or the company that built the agent.
• The protocol determines the evidence available in a dispute, and nothing else.
• The market determines feasibility: an agentic flow that works in the US may be impossible in the European Economic Area because of authentication rules.
• None of the three questions can be answered at group level: they come up country by country, acquirer by acquirer.

AP2, ACP, x402: three different problems

AP2, ACP, and x402 are three private specifications for how a software agent triggers a payment. The industry mentions them in the same breath, yet they solve different problems and compete only in part. AP2 (Agent Payments Protocol), released by Google on September 16, 2025, addresses proof of authorization. ACP (Agentic Commerce Protocol), released by OpenAI and Stripe on September 29, 2025, under the Apache 2.0 license, describes a complete checkout flow between an agent and a merchant. x402 covers a case the other two ignore: paying for a web resource per unit, with no account and no invoice.

AP2 version 0.2 reorganized its mandate model. The first release distinguished intent, cart, and payment; the current specification describes a two-stage Checkout Mandate and a Payment Mandate. The open checkout mandate, of type mandate.checkout.open.1, carries the constraints: which merchants are authorized and which order lines are eligible. The closed mandate, mandate.checkout.1, embeds a JWT signed by the merchant and the hash that identifies it.

Checkout Mandate OPEN        type mandate.checkout.open.1
  constraints                authorized merchants, eligible order lines
  created by                 the Shopping Agent
  rendered by                the Trusted Surface, for the human to verify

Checkout Mandate CLOSED      type mandate.checkout.1
  checkout_jwt               JWT signed by the MERCHANT, base64url-encoded
  checkout_hash              hash of the checkout_jwt, unique cart identifier

Payment Mandate              authorizes payment for a given checkout
  payee                      the merchant
  amount / currency          what is being committed
  instrument                 the payment method to be used
  checkout hash              ties the payment to the signed cart
  iat / exp                  mandate issued-at and expiry
  optional                   execution date, risk data, PISP information
  verified by                Credential Provider, network, merchant processor

encoding of both mandates    SD-JWT (selective disclosure)

x402 is the only one of the three protocols that publishes usage figures. For the 30 days to July 14, 2026, the protocol’s website showed 75.41 million transactions worth $24.24 million, with 94,060 buyers and 22,000 sellers. That puts the average ticket at about $0.32. x402 handles micropayments for API calls and content access, not retail purchases. No card rail goes down to ticket sizes that small.

The delegated mandate and what proves it

A delegated mandate is the authorization by which a person gives a software agent the right to trigger payments on their behalf. Its strength is measured by what the merchant can produce, six months later, when an issuer disputes the charge. Four types of proof coexist in 2026, and they do not carry the same evidentiary weight. Two rest on a cryptographic signature. The third relies on trust in a card network. The fourth predates agents and lives on public rails.

• Log the mandate, not just the transaction: mandate ID, scope, limit, expiry date, and a timestamp for when it was shown to the human.
• Keep the full chain: without the hash linking the payment to the signed cart, the proof is just the merchant’s word.
• Record revocation: the date and channel through which the mandate was withdrawn determine who bears any later payments.
• Separate the agent from the human in the logs: an agent ID reused across two customers makes any investigation impossible.

Where mandate rails already exist, and where they don’t

A rail mandate is a payment authorization registered with the payer’s bank on a country’s payment infrastructure. Payment delegation predates agents. Several central banks have built such mechanisms on their instant payment rails over the past five years. An agent that could plug into them would need no new protocol. The strongest delegation infrastructure in the world is public, and no agentic protocol connects to it in production yet.

Southeast Asia has the most heavily used instant payment rails in the world. PromptPay in Thailand, run by National ITMX under a Bank of Thailand mandate since 2017, carried 27.4 billion transactions in 2025. QRIS, the standard Bank Indonesia has mandated with ASPI since 2019, has more than 32 million merchants enrolled. DuitNow from PayNet and PayNow in Singapore round out the picture. All four handle payer-initiated payments, with the payer present to scan or confirm. None of them carries a mandate, with the sole exception of Malaysia’s AutoDebit.

Cards remain the only truly cross-border rail available to an agent. Visa and Mastercard announced their frameworks a day apart: Mastercard Agent Pay on April 29, 2025, and Visa Intelligent Commerce on April 30, 2025. Both take the same approach. A card token is bound to an agent, a merchant scope, and a consent policy, and the agent never sees the actual card number.

The authentication wall, market by market

Strong customer authentication (SCA) is the payer verification required by Commission Delegated Regulation (EU) 2018/389, in force in the European Economic Area since September 14, 2019. No agentic protocol generates it. In Europe, a card payment triggered by an agent therefore falls under that regulation and under the schemes’ stored credential framework. A payment made without the cardholder is classified there as an MIT, a merchant-initiated transaction.

Visa’s Stored Credential Framework, in effect since 2017 and later adopted by Mastercard, requires transactions to be chained. The setup transaction is a CIT, a customer-initiated transaction, authenticated, which returns an identifier: the Transaction ID at Visa, the Trace ID at Mastercard. Every subsequent transaction must reference that identifier, the only proof of the mandate the issuer has at authorization time. A transaction submitted without that reference is treated as an unauthenticated card-not-present sale, and the issuer declines it.

Other markets impose different authentication requirements. India requires an additional factor of authentication for electronic payments, and a UPI AutoPay mandate is approved with the payer’s UPI PIN. Brazil has the payer approve Pix Automático authorizations in their bank’s app. The US has no equivalent requirement for cards, which is why the first consumer agentic flows launched there. The US head start reflects that regulatory difference, not a gap in technical maturity.

Who pays when the agent gets it wrong

The recourse regime is the set of channels through which a payer can get a disputed payment refunded. When an agent buys the wrong item, at the wrong price, or from the wrong merchant, who ultimately bears the loss depends on the rail used. The agentic protocol plays no part in that. Neither does the company behind the agent. The three regimes below, for cards, account-to-account transfers, and stablecoins, lead to very different outcomes.

California’s AB 316, signed into law on October 13, 2025, adds Section 1714.46 to the Civil Code: a machine’s autonomy does not shield the party using it. In a civil action, a defendant cannot argue that the artificial intelligence caused the harm autonomously. All other defenses remain available; the law rules out only that one.

• Require agent identification in the transaction data, and reject any integration that does not pass it through.
• Negotiate evidence retention with the provider of the token or delegated credential: retention period, format, and turnaround time for handing it over in a dispute.
• Set a limit per mandate and per period, regardless of what the protocol allows. The scheme’s limit is not the merchant’s.
• Write the returns policy before opening the channel: a mistaken agentic purchase is better handled with a fast refund than with a chargeback.
• Monitor the dispute rate by channel: an agentic channel that drifts above the rest of the portfolio triggers the schemes’ monitoring programs like any other.

What regulators have already written

No major jurisdiction has published rules specific to agentic payments. An agent that pays is legally an agent in the ordinary sense: a third party acting on someone else’s behalf. Agency law, payments law, and tort law therefore apply as they stand. The rules that actually govern an agentic deployment in 2026 were written for other purposes.

The timeline shows two patterns. The rules that constrain an agent most were not written for it, and no one expects them to be amended for agents for several years. Wherever a regulator has created a mandate, it has also laid the legal groundwork for future agentic payments. The UK, Brazil, India, and Australia have that groundwork, for reasons that have nothing to do with agentic commerce.

Real use cases, mirages, and what to measure

A production use case differs from an announcement in one way: it has verifiable volumes or documented transactions. In 2026, four agentic payment use cases meet that test; the rest are demos, roadmaps, or sales pitches. Vendors and the businesses evaluating them do not draw that line in the same place.

To identify agentic payments in merchant data, the channel must be explicitly tagged. Without that tag, orders placed by agents blend into the rest of e-commerce traffic, and their effects stay invisible until the first incident. Visa released the Trusted Agent Protocol with Cloudflare on October 14, 2025, so that merchants can recognize a legitimate agent by its cryptographic signature. That recognition is first a way to measure the channel, and only second a security gain.

• Tag the channel in the order data from the very first integration: without an “agent” dimension, none of the metrics below can be calculated.
• Track the payment success rate by channel: an agent triggering badly chained MITs causes an immediate drop you can pinpoint.
• Track average order value and return rate: both drift differently on an agentic channel, and the returns cost more than the extra order value brings in.
• Keep a register of active mandates: count, total limit, nearest expiry date. An uninventoried set of mandates is an off-balance-sheet commitment.
• Test revocation end to end at least once a quarter, under real conditions, with the provider.