Payments initiated by software agents moved from demo to protocol in under a year. Google announced the Agent Payments Protocol (AP2) on 16 September 2025 as an open protocol for securely initiating agent-led payments across platforms, extending its Agent2Agent work and the Model Context Protocol. On 28 April 2026 it said it was donating AP2 to the FIDO Alliance and released version 0.2, which adds Human Not Present payments: autonomous execution against pre-authorised user instructions. In parallel, OpenAI and Stripe’s agentic checkout path (ACP) covers execution inside chat-style flows, and Google’s UCP handles discovery and carts.
For risk teams, the useful framing is that 2026 agentic commerce is a stack, not a protocol. Discovery and cart orchestration sit in one layer, authorisation and trust in a second, payment execution in a third. The risk concentrates in the middle. Classic card-not-present fraud is about stolen credentials; agentic fraud is about authority ambiguity: did the user authorise this specific cart, at this amount, from this merchant, at this time. An agent asserting “my user wanted this” is worthless as evidence. The whole design question is what replaces that assertion.
Mandates are the evidence chain
AP2’s answer is tamper-resistant mandates carried as W3C Verifiable Credentials. Three of them chain together: an Intent Mandate capturing what the user asked for and under what constraints, a Cart Mandate capturing what the agent actually selected, and a Payment Mandate capturing what the merchant and network charged. Together they form a cryptographically verifiable record of the transaction’s authority, designed to give merchants and payment providers proof of user authorisation rather than an agent’s self-report.
The design detail that matters operationally is that mandates encode scope, intent, and constraint. A merchant can verify that the agent stayed within the user-approved envelope: budget, product category, brand, timing. AP2 is payment-agnostic, aimed at cards, bank transfers, stablecoins, and other rails, and it is deliberately not the shopping cart or the checkout UX. It is the authorisation and liability-evidence layer underneath them, which is exactly the layer disputes are fought over.
The four fraud scenarios that matter
The scenarios worth engineering against differ from the standard CNP catalogue:
- Unauthorised autonomy. The agent completes a purchase the user did not intend in that specific form. This is the baseline dispute generator, and the mandate chain exists chiefly to resolve it.
- Scope drift and cart manipulation. The agent, whether through error, prompt manipulation, or a hostile merchant surface, assembles a cart that exceeds the allowed budget, category, or brand constraints. Detection is a comparison problem: cart mandate against intent mandate.
- Replay and substitution. A previously valid authorisation reused or altered for a different cart or merchant. Signed mandates bind the evidence to the transaction context, which is what makes this materially harder than replaying a stored credential.
- Human-not-present abuse. Version 0.2 makes autonomous execution a feature, and the feature is the risk. When no human is in the loop at execution time, pre-authorised limits and after-the-fact auditability carry the entire control burden.
Merchant and issuer controls
On the merchant side, the control stack is mandate verification, policy checks, and evidence retention. Before capture, confirm the cart matches the signed intent and the payment mandate is consistent with the cart mandate; on mismatch, decline or step up for fresh user confirmation. Retained mandate evidence directly addresses the “agent overreach” dispute, because the merchant can show the purchase sat inside the user’s stated constraints.
On the issuer side, the gain is attribution. Today an issuer decides on merchant descriptor data and its own behavioural models; an AP2-style chain adds cryptographic evidence of user intent, agent selection, and payment authorisation. That supports sharper authorisation decisions, better fraud triage, and cleaner dispute handling when a cardholder claims the agent acted outside instructions. The realistic adoption pattern is asymmetric: treat mandate evidence as a higher-trust signal when present, and fall back to existing authentication and fraud models when absent. Nothing about the protocol removes the need for those models; it adds a stronger signal to feed them.
Building while the standards settle
The stack has two competing routes, Google’s UCP plus AP2 under FIDO governance and the OpenAI and Stripe execution path, and the winner for merchants and issuers will be whichever combination delivers authorisation evidence, fraud control, and conversion together. You do not need to pick a winner to start building. The durable investments are protocol-tolerant: a verification service that can validate credential chains and check cart-against-intent consistency; a policy engine expressing per-agent limits on amount, category, and frequency, wired into your existing velocity and limits infrastructure; telemetry that separates agent-initiated from human-initiated traffic so your fraud models can learn the difference instead of averaging over it; and dispute workflows able to ingest verifiable credentials as evidence rather than screenshots.
The failure modes to avoid are equally concrete. Treating agent traffic as bot traffic to be blocked throws away the evidence-bearing cohort and pushes agents into pretending to be humans. Accepting agent assertions without mandate verification recreates the authority-ambiguity problem the protocols were built to solve. And ignoring the human-not-present category until volumes force the issue means designing your limits and audit trail under incident pressure. The protocols are young; the discipline they demand, provable authorisation and evidence that survives a dispute, is the same one payment risk teams already know. Build for the evidence, and the protocol choice becomes a detail.
FAQ
Should we block agent-initiated traffic until the standards mature?
Blocking is tempting and mostly futile, because agents that are blocked simply present as ordinary customers through the normal checkout, and you lose the signal that they are agents at all. The better position is to distinguish agent traffic, score it, and treat evidence-bearing transactions as the safer cohort. A purchase arriving with a verifiable mandate chain gives you more to work with than a typical card-not-present order, not less.
Who is liable when an agent exceeds its mandate?
Formal liability still follows network rules and applicable payment regulation; the protocols do not rewrite those. What the mandate chain changes is who can prove what. If the cart matches the signed intent mandate, user authorisation is demonstrable and the 'my agent went rogue' dispute collapses. If a merchant accepted a cart inconsistent with the intent mandate, its dispute position is weak and it should expect to eat the loss. Evidence quality will decide these cases long before case law does.
What does the FIDO Alliance donation mean for adoption planning?
Moving AP2 from a single-vendor project to FIDO governance in April 2026 signals that the trust layer is intended as shared infrastructure rather than a Google product, which lowers the strategic risk of building against it. It does not guarantee AP2 wins the stack, and the OpenAI and Stripe execution path is developing in parallel. The prudent build is protocol-tolerant: a mandate verification and evidence-handling capability you can point at whichever credential formats reach volume in your channels.