Agentic Payments

What an agentic payment actually is

The phrase is doing a lot of work, and most of the confusion around it comes from lumping together three different things. A form-filling assistant that pastes your saved card into a checkout page is not an agentic payment. A subscription that rebills you monthly is not one either — that is a merchant-initiated transaction, a category the card networks have handled for decades. Agentic payments are the case in between and it is genuinely new: software chooses what to buy, when to buy it and from whom, then transacts, without the person who authorized it being at the keyboard when it happens.

That gap between the authorization and the transaction is the entire commercial problem. Every mechanism the payments industry has built to answer "did the cardholder agree to this?" assumes the cardholder was present, or that a merchant is billing on a standing arrangement the cardholder set up directly. Neither assumption survives an agent that decides, on Tuesday, that the thing you described on Sunday is now in stock at an acceptable price.

The delegation problem: proving a human said yes

Card systems verify identity and authorization at the point of transaction. Agentic commerce needs to verify an authorization that was given earlier, in vaguer terms, and then prove afterward that what the agent did fell inside it. The industry's shared answer so far is the mandate: a cryptographically signed record of what the user authorized, produced at the moment they authorized it, and carried forward with the transaction as evidence.

The clearest published expression of this is the Agent Payments Protocol (AP2), an open protocol led by Google with the FIDO Alliance named as a standardization partner. AP2 splits the authorization into signed verifiable credentials. In its earlier specification these were an Intent Mandate — signed by the user to authorize an agent to buy within stated parameters while the user is absent, carrying the natural-language prompt and a time-to-live — and a Cart Mandate, signed by the merchant first and then the user, binding a specific finalized cart. A separate Payment Mandate goes to the network and issuer, and the specification is explicit that it must always carry both AI-agent presence and human-present-versus-not-present signals. Later drafts reorganize this into open and closed forms of a Checkout Mandate and a Payment Mandate; the terminology is still moving, so pin any implementation to a specific version.

The structural point survives the renaming. Instead of asking a model to prove its own good behavior, the protocol anchors the transaction to a deterministic artifact a human signed, and treats everything the agent inferred as separately auditable against it. The mistake most commentary makes here is treating the mandate as a fraud control. It is not. It is an evidence format, designed so that responsibility can be allocated afterward.

The protocols on the table, and what each one covers

Five efforts are in public view, and they solve overlapping but different problems. None of them is a settled standard.

They are not straightforwardly competitors. ACP is closest to a working commercial deployment because it solves the narrow problem of getting a payable credential from an agent surface into a merchant's existing checkout while leaving the merchant as merchant of record. AP2 is the most ambitious about evidence and liability. Visa's Trusted Agent Protocol addresses the problem the others mostly ignore: from the merchant's side, an agent and a scraper look identical, and most fraud stacks are configured to block both.

Authentication when there is no human at the checkout

Strong customer authentication was designed around a challenge — a push notification, a biometric prompt, a one-time code — delivered to a human who is present. Remove the human and the challenge either fails or becomes theater. Three approaches are being pursued, and they are complementary rather than alternative.

• Move the authentication earlier. Authenticate the human once, at mandate-signing time, using a hardware-backed device credential, and carry the resulting signature forward as proof. This is AP2's approach and the reason FIDO's involvement matters — passkey infrastructure is the only widely deployed thing that produces a phishing-resistant, device-bound human signature.
• Move the authentication into the credential. Issue a token that is scoped to a specific agent and constrained in advance, so authority is expressed in the credential rather than reasserted per transaction. Both Visa and Mastercard have taken this route publicly, building on network tokenization rather than inventing a new credential type.
• Authenticate the agent, not just the user. Visa's Trusted Agent Protocol has agents present an RFC 9421 HTTP message signature carrying timestamps, a session identifier and key identifier, cryptographically bound to the specific merchant site and page — so a merchant can tell an authorized agent from an unidentified bot, and can be passed verifiable consumer identifiers such as a Payment Account Reference for a card already on file.

What none of this resolves is the authorization message itself. Networks have long distinguished cardholder-initiated from merchant-initiated transactions, and an agent purchase is cleanly neither. That is exactly why AP2 insists the payment mandate always carry an explicit agent-presence flag — but an indicator only has value if issuers use it in their decisioning, and how they do is not public.

Disputes and chargeback rights when the agent got it wrong

This is the least settled part of the subject and the part with the most money attached. Start with what exists. Card network dispute rules today sort claims into a small number of families: the transaction was fraudulent, the authorization was defective, the processing was wrong, or the consumer has a claim against the merchant such as goods not received or not as described. In the United States, credit card billing-error rights sit under Regulation Z, and unauthorized electronic fund transfers on debit and prepaid accounts sit under Regulation E.

Now the hard case. An agent, correctly acting on a mandate the user signed, buys the wrong thing — wrong size, wrong vendor, a price the user would not have accepted. The merchant shipped exactly what was ordered. This is not fraud, the authorization was valid, and the goods matched the order. It fits none of the existing families cleanly.

AP2's stated design goal is to make that adjudication possible rather than to pre-decide it: allocate liability to real-world entities — user, merchant, issuer — in the ordinary case, and only to the agent where it made what the specification calls a load-bearing decision that was wrong. The mandate chain is the evidence. A signed cart mandate defeats a first-party misuse claim; a signed intent mandate compared against the actual cart exposes a mispick the user never approved; a valid mandate with no fulfillment record points at the merchant. That is a coherent framework. It is not, as far as has been published, a set of card network dispute rules with reason codes, evidence requirements and time limits attached — and until it is, an agentic mispurchase will be argued inside the existing reason codes, where it fits badly.

What the card networks have actually published

Both major networks announced agentic frameworks within a day of each other in the spring of 2025, and both built on tokenization rather than new credential types.

Visa announced Visa Intelligent Commerce on April 30, 2025, describing tokenized digital credentials in place of card details, consumer-set spending conditions, and the position that "only the consumer can instruct the agent on what to do and when to activate a payment credential," with named AI partners including Anthropic, IBM, Microsoft, Mistral AI, OpenAI, Perplexity, Samsung and Stripe. Visa's own corporate material describes the product as in the process of deployment rather than generally available.

Mastercard announced Agent Pay on April 29, 2025, introducing Mastercard Agentic Tokens built on the tokenization that already underpins mobile payments and card-on-file, with Microsoft and IBM named on the AI side and Braintree and Checkout.com on the acceptance side. Mastercard's stated model is that agents must be registered and verified before transacting and that all parties can identify an agent-facilitated transaction.

Since then the direction of travel has been toward shared infrastructure. In July 2026 the x402 Foundation formally launched under the Linux Foundation, taking stewardship of the x402 protocol originally developed at Coinbase, with American Express, Mastercard, Visa, Stripe, Fiserv, Circle, Google, Amazon Web Services, Adyen and Shopify among the participants. Separately, FIS announced in January 2026 an AI-powered transaction platform for banks built with Visa and Mastercard that allows AI agents to initiate transactions.

What has not been published, by either network, is the part that determines who pays: the rule changes. No public agentic-specific dispute reason codes, no published liability shift for agent-initiated transactions, no stated treatment in the fee schedules.

Who has shipped something, and who has shipped a press release

The gap between announcement and availability is unusually wide in this category, and reading it accurately is worth real money if you are choosing a provider.

Stripe is furthest along commercially: it co-developed ACP with OpenAI and sells an agentic commerce suite built on shared payment tokens, making agent-initiated purchases a marketed, documented product rather than a roadmap item. Checkout.com states it is live with Google's Universal Commerce Protocol and supports both the Visa and Mastercard frameworks. Shopify has published catalog and checkout integrations positioning its checkout as the settlement point for agent-initiated purchases. Worldpay markets agentic commerce acceptance as a named capability. PayPal has announced an agent-facing toolkit. On the risk side, Forter markets an agentic commerce product and launched a set of AI agents in June 2026 covering analytics, disputes, abuse and payments.

Against that, a large part of the acquiring industry — including several very large processors — documents no agentic capability at all. Where a provider's public material describes AI for underwriting, reconciliation or support rather than agent-initiated payment acceptance, that is a different product wearing the same adjective. Ask which protocol, which version, and whether a merchant can transact on it today.

What is genuinely unresolved

Separating the open questions from the solved ones is the most useful thing a merchant can do right now.

• Dispute rules. No published network reason code, evidence standard or liability shift specific to agent error. This is the big one.
• Regulatory treatment. Whether an agent's mistaken purchase is an unauthorized transfer under Regulation E, or a billing error under Regulation Z, is untested.
• Protocol convergence. Several efforts, overlapping scopes, active renaming. A merchant that hard-codes to one today is making a bet, not an integration.
• Issuer behavior. Agent-presence flags exist in specifications. How issuers score them, and whether agentic transactions face elevated decline rates, is not public.
• Mandate revocation. Signed mandates carry expiry, but there is no cross-industry revocation mechanism comparable to card blocking.
• Agent versus bot. Merchant fraud stacks are tuned to block automation. Until agent identity is verifiable at scale, legitimate agents will be declined as bots.

What to do about it before the rules exist

The temptation is to wait for the standards to settle. That is defensible for integration and indefensible for instrumentation, because the evidence you will need in a dispute has to be captured at the time of the order, not reconstructed later.

Four things are worth doing now, in order. First, measure agent-originated traffic before you decide whether to allow it — most merchants cannot currently distinguish it from bot traffic, which means they are already making the decision by accident. Second, log every agent identity signal, mandate reference and token identifier alongside the order record, and retain it for at least your longest chargeback window. Third, hold your merchant-of-record position deliberately rather than inheriting it from whichever agent surface sends you volume, because it determines who owns the customer, the refund and the dispute. Fourth, decide in advance what your returns policy says about a purchase the buyer's software made in error, since the network rules will not answer it for you and your policy will be the operative document.

The hypothetical worth modeling is not the fraud case. It is a business whose agent-originated orders grow to a meaningful share of volume, with a mispurchase return rate several times its normal rate, and no reason code that fits. That is an operational cost problem long before it is a compliance one — and it is the scenario the current rulebooks were not written for.

Frequently asked questions