# Agent Payments Protocol for merchant checkout

> See how Agent Payments Protocol secures agentic checkout, what its mandates prove, who supports it, and what merchants must build first.

Agent Payments Protocol gives an AI shopping agent evidence that it may buy and pay. It does not give a merchant a catalog, checkout API, fraud policy, payment processor, or a free pass on consumer law. That boundary matters more than any protocol diagram.

A merchant that treats AP2 as another payment method will build the wrong integration. A merchant that treats it as an authorization and evidence layer can attach it to an existing commerce flow, test it without moving real money, and decide whether autonomous purchases justify the work. The current public specification labels itself AP2 v0.2 and uses two linked mandates, Checkout and Payment, in open and closed forms. Older launch material and early examples use Intent, Cart, and Payment Mandate terminology, so check the version before copying a diagram or type name.

## AP2 authorizes an agent, not the whole checkout

AP2 answers who authorized an agent to do what, under which constraints, and for which final transaction. A normal online payment assumes a person is looking at a merchant page and pressing the purchase button. An agent may discover a product in one system, negotiate with a merchant agent, obtain a credential elsewhere, and execute after the person has left. Existing payment rails can move the money, but their usual request does not prove the agent stayed inside the user's instruction.

The protocol adds signed, tamper-evident records called mandates. A Checkout Mandate concerns what the agent may purchase. A Payment Mandate concerns how the resulting checkout may be paid. Cryptographic references bind the records to the merchant's checkout and to each other, so a party can detect substitution rather than trusting a chat transcript or the agent's account of events. Receipts preserve the result.

This makes AP2 narrower than many descriptions suggest. It does not standardize product search, inventory, shipping quotes, tax calculation, returns, or order management. The v0.2 specification says it operates as a security feature inside a commerce protocol. It is explicitly compatible with Universal Commerce Protocol, or UCP, but AP2 can sit in another commerce system if that system supplies the missing lifecycle. A2A or MCP can carry interactions between software components, yet neither one turns a cart into an authorized payment.

The distinction I use in architecture reviews is simple: checkout state says what the merchant is prepared to sell, while a mandate says what authority the agent can present. Mixing them lets probabilistic agent output leak into deterministic authorization. Keep the agent free to reason about products. Make ordinary code verify signatures, hashes, expiry, audience, constraints, and current checkout state. The specification requires validation and processing to happen in deterministic code even when a role itself uses an LLM.

## Five roles divide the trust boundary

AP2 v0.2 defines five roles, and a real company may perform several of them. The split exists to assign verification duties, not to force five vendors into every payment.

- The Shopping Agent discovers products, assembles checkout details, selects an instrument, and obtains mandates.
- The Merchant owns catalog and checkout integrity, signs the checkout, verifies the Checkout Mandate, and fulfills the order.
- The Credential Provider controls access to payment credentials and scopes a credential or token to the authorized transaction.
- The Merchant Payment Processor verifies the Payment Mandate and processes or verifies payment.
- The Trusted Surface shows the authorization to the user, obtains informed consent and authentication, and creates user-signed mandates.

The Trusted Surface must be non-agentic. That requirement is easy to wave away in a demo and expensive to retrofit later. If the same LLM that interpreted the request also chooses what the consent screen displays, the system has no independent checkpoint. The trusted surface needs deterministic rendering from mandate content, clear disclosure of amount and conditions, fresh authentication when required, and protected signing keys.

The credential provider is not merely a vault API. It must verify that the agent may access an instrument, evaluate the Payment Mandate, and return a credential scoped to the transaction. Passing a reusable card number to the shopping agent defeats the separation AP2 is trying to create. The protocol's security guidance says the payment credential or token should reach the merchant only after verification of a final Payment Mandate.

Role combination changes operations, not responsibility. If a merchant also runs its payment processor, it still needs separate checks for checkout authority and payment authority. If an agent provider owns the trusted surface, its non-agentic consent path still needs isolated keys, auditable releases, and a threat model that treats the shopping agent as hostile. AP2 explicitly assumes prompt injection cannot be prevented reliably and includes agents and LLMs as potential attackers. That is the correct assumption.

## Human-present checkout signs the final facts

In the human-present flow, the user approves a finished checkout and payment while still in session. This resembles ordinary checkout from the user's perspective, but the signatures make the agent's involvement and authority portable across participants.

The shopping agent first works with the merchant to assemble a cart. The merchant creates a signed checkout, including the final items, prices, shipping terms, and other data owned by the commerce system. The agent obtains suitable instrument options from the credential provider. It then constructs closed Checkout and Payment Mandate content and sends both to the Trusted Surface.

The Trusted Surface renders the actual content, not a prose summary generated by the agent. After user authentication and consent, it signs the mandates. A hash of the merchant-signed checkout permanently links the authorization to that checkout. The agent presents the Payment Mandate to the credential provider, receives a scoped payment token, and sends the Checkout Mandate plus that token to the merchant. The merchant and processor verify their respective evidence before completing the order and issuing receipts.

A common implementation failure appears when the merchant recalculates tax or shipping after consent. The checkout now totals $214.80 while the mandate covers the signed $199.00 checkout. A permissive integration compares only an order ID, accepts the token, and silently charges the new total. A correct integration treats any material checkout mutation as a new authorization event. It creates a new signed checkout and obtains fresh closed mandates. Hash mismatch is a stop signal, not an inconvenience to catch and ignore.

Existing payment challenges still apply. An issuer, processor, credential provider, or merchant may require a familiar step such as 3DS. The user must resolve that challenge on a trusted surface. AP2 carries evidence around the agentic action; it does not cancel issuer risk controls or guarantee approval. Declines, timeouts, and abandoned challenges need ordinary state transitions and idempotent retries.

## Autonomous checkout starts with open constraints

In a human-not-present flow, the user authorizes bounded conditions before the final product, amount, or execution time is known. The agent later closes those mandates against a concrete checkout. This is the part that makes AP2 more than a signed buy button.

Consider a founder who asks an agent to buy one refundable economy ticket to a specified city, on approved dates, below a fixed total, using a company instrument. The Trusted Surface turns those conditions into open Checkout and Payment Mandates and gets the user's authenticated signature. The open Checkout Mandate can constrain allowed merchants and acceptable line items. The open Payment Mandate can constrain payee, instrument, amount range, total budget, recurrence, execution date, and its relationship to the checkout authority.

When the agent finds a match, it obtains a merchant-signed checkout and creates closed mandates bound to the open ones. The agent signs the closed presentation with the key named in the open mandate. Deterministic verifiers check the user's original signature, agent key binding, selective disclosures, expiry, the open-to-closed relationship, the merchant's checkout hash, and every revealed constraint. The credential provider scopes a token only after those checks pass.

An open mandate is not permission to improvise. Natural-language intent may help the agent search, but enforcement must resolve to machine-checkable fields. "A decent hotel near the venue" cannot become an authorization rule unless the product defines what qualifies and who supplies that fact. Use exact merchant identities, product identifiers, quantities, currency, maximum amount, dates, refund conditions, and recurrence limits wherever money can move. If a condition cannot be evaluated deterministically, require the user to return.

The merchant or credential provider can reject an unresolved constraint and convert the autonomous path into a human-present approval. Product teams sometimes call this a failure because it adds friction. It is a safety valve. The bad alternative is an agent inventing certainty so that a conversion chart looks cleaner. Design the return-to-user path before the autonomous demo, including expiration, changed price, unavailable product, and a challenge on a second device.

## Mandates create evidence, not immunity

Signed mandates improve accountability because each participant can verify a structured record instead of asking whether a model probably understood the user. They do not decide legal liability by themselves, prevent every replay, or prove that goods were delivered.

The current specification binds a closed Checkout Mandate to the merchant-signed checkout through `checkout_hash`. A closed Payment Mandate references the associated checkout through its transaction identity, while an open Payment Mandate uses a reference constraint. Open mandates carry an agent confirmation key, and closed presentations bind back to the open authorization. Selective disclosure lets each participant receive only the claims needed for its role instead of exposing the entire shopping conversation or raw payment data.

That evidence helps during a dispute: a merchant can show what checkout it signed, the credential provider can show which bounded payment it authorized, and the user can challenge a transaction that falls outside the mandate. Network rules, contracts, consumer protection, card scheme procedures, and local regulation still determine who absorbs a loss. AP2 supplies better facts to those systems. It does not write their rules.

Replay control deserves its own state, even when signatures verify. A valid open authorization may allow one purchase, repeated purchases, or a budget across a period. Your verifier needs atomic consumption, idempotency keys, expiry checks, revocation behavior, and a durable record of which closed transaction used which authorization. Two workers can find the same scarce item at the same moment. Cryptography will happily validate both unless the policy and storage layer enforce one-time or budgeted use.

Keep the evidence after success and failure. Store mandate identifiers, hashes, versions, issuers, audiences, timestamps, disclosed constraints, verification decisions, checkout and payment receipt references, and rejection codes. Do not store full prompts merely because they are available. A prompt is ambiguous, may contain unrelated personal data, and is weaker dispute evidence than the signed object derived from it. Set retention and access rules with counsel and payment partners before production.

## Agentic checkout needs a separate commerce contract

A merchant needs a commerce interface that lets an agent discover capabilities, create and update checkout state, receive fulfillment options, and complete an order. AP2 secures the authorization inside that flow. UCP is one compatible choice, and the current Google material describes AP2 as an extension for autonomous UCP transactions. A merchant can use a different deterministic API, but then it owns the mapping and interoperability work.

Do not start with browser automation over the consumer website. It is popular because a demo can reach many stores without merchant integration. It is wrong as the merchant architecture because DOM text is not a signed catalog, session state changes unpredictably, anti-bot controls become part of the payment path, and consent can bind to a page the merchant changes a moment later. Browser automation may test demand. It cannot supply the stable identities and checkout integrity that mandate verification requires.

AP2 also does not compete with every protocol whose name includes agent or payment. A2A can handle agent-to-agent messages. MCP exposes tools and resources to a model. UCP covers the broader commerce lifecycle. x402 describes a payment pattern often associated with programmatic or stablecoin access, while AP2 is payment-method agnostic and focuses on authority and evidence. OpenAI's Agentic Commerce Protocol has its own commerce and checkout model. Supporting one does not imply conformance with another. Build adapters around a canonical internal checkout model rather than mixing protocol objects throughout order code.

The practical boundary is an authorization gate just before credential release and order completion. Upstream, the agent can search, compare, and negotiate. At the gate, deterministic services freeze a merchant-signed checkout, verify mandates, evaluate policy, reserve one-time authority, request a scoped credential, and commit the order. Downstream, existing fulfillment, refunds, reconciliation, and support systems continue to run. A refund should reference the original evidence, but it should follow the merchant and payment rail's refund process unless a later protocol version defines more.

## Support announcements are not production adoption

AP2 has serious institutional participation, but the public evidence does not justify saying that every named company accepts AP2 transactions in production. Google announced the protocol in September 2025 with more than 60 collaborating organizations. Its named group included payment networks, processors, commerce companies, software vendors, and crypto infrastructure providers such as American Express, Adyen, Coinbase, Etsy, JCB, Mastercard, PayPal, Revolut, Salesforce, ServiceNow, UnionPay International, and Worldpay.

Those names signal input, endorsement, experimentation, or planned integration. They do not all mean the same thing. A network helping shape mandate evidence is different from a merchant exposing an AP2 endpoint. A processor building support is different from a live acquirer path in every region. A commerce platform endorsement is different from an individual seller being enabled. Procurement teams should ask for a supported role, version, environment, payment methods, geographies, conformance evidence, production references, and an owner for disputes.

Governance is also moving. Google contributed AP2 to the FIDO Alliance in April 2026, and FIDO's Payments Technical Working Group is using AP2 alongside Mastercard's Verifiable Intent contribution to develop agent-initiated commerce specifications. Google published v0.2 with autonomous transaction support during that transition. This strengthens the route toward an open standard, but working-group stewardship is not the same as a final, universally deployed standard. Version pinning and change management remain merchant prerequisites.

The public repository contains an Apache-2.0 implementation, schemas, SDK code, and sample scenarios. It says a packaged release will come later and currently documents installation from the repository. That is enough for prototyping and contract tests. It is not evidence that the sample's key handling, storage, mock payment provider, or agent framework should enter production unchanged. The samples use Google tooling in places, but the repository explicitly says AP2 does not require that agent framework or model.

Ask vendors to demonstrate failure, not just checkout success. Have them present an expired open mandate, a changed checkout hash, an unapproved merchant, a total above the limit, a replayed authorization, an unknown key, and a mandate from another protocol version. A partner that cannot show deterministic rejection paths has integrated a happy-path demo rather than a payment control.

## Merchant prerequisites begin with ordinary checkout discipline

A merchant is ready to pilot AP2 when its existing systems can produce stable, signed checkout facts and reject inconsistent payment attempts. Most prerequisites are unglamorous, and that is good. Payments fail at boundaries and state transitions more often than in the signature library.

Your commerce layer needs stable product and merchant identifiers, versioned checkout sessions, final totals by currency, explicit tax and shipping state, inventory reservation rules, return and refund terms, and a clear definition of material mutation. Your payment layer needs tokenized instruments, processor support for agent context, idempotent authorization and capture, decline handling, reconciliation, refunds, and a way to bind a token to the checkout. Your identity layer needs trusted signing and verification keys, rotation, revocation, audience checking, clock discipline, and isolated user authentication.

The AP2-specific work then becomes tractable. Pin a protocol and mandate version. Generate a merchant-signed checkout JWT. Verify Checkout Mandates or delegate verification under a contract that preserves evidence. Pass the checkout mandate hash and scoped payment token into completion. Verify Payment Mandates in the processor role. Produce signed checkout and payment receipts. Log structured verification results without leaking payment credentials or unnecessary personal data.

Treat cryptographic verification as a service with a small, versioned interface, not as calls scattered across the order controller. That service should resolve trusted issuers and keys, validate algorithm allowlists, reject missing audiences and stale timestamps, verify selective-disclosure presentations, and emit a decision record. Cache public keys only within their declared lifetime and decide what happens when a key endpoint is unavailable. Failing open because a discovery service timed out turns an infrastructure incident into unauthorized spending.

Key ownership needs a written map. The merchant signs checkout state. The trusted surface or its provider signs user authority under the chosen authorization model. The autonomous agent proves possession of the key bound into the open mandate. Receipt issuers sign their results. Use separate keys and audiences for test and production, rotate them under rehearsal, and retain enough metadata to verify evidence after an active key changes. Never let an LLM choose algorithms, issuers, keys, or validation exceptions.

Privacy work begins with a field-level data map. The merchant needs enough disclosure to verify purchase authority, while the credential provider and processor need enough to authorize payment. Neither party automatically needs the original prompt, the complete set of products considered, or every payment instrument the user owns. Selective disclosure reduces exposure only if implementations request and log the minimum claims. Copying the complete mandate presentation into general application logs gives back much of that benefit.

Compliance does not disappear behind the protocol. The merchant still needs to determine PCI DSS scope with its acquirer or qualified assessor, handle privacy rights, apply sanctions and prohibited-goods controls, meet authentication rules, preserve consumer disclosures, and follow local rules for recurring or delegated transactions. A scoped token can reduce direct card-data exposure, but only the actual token path and provider agreement determine scope. Do not put a "PCI safe" label on an architecture slide because the agent never saw a primary account number.

Operational ownership should follow each verification outcome. Security owns invalid signatures and unknown issuers. Commerce owns changed checkout state and unavailable inventory. Payments owns credential and processor declines. The agent product team owns constraints it cannot translate into deterministic policy. Support needs a safe view that explains the decision without exposing credentials or private disclosures. Finance needs evidence that order, authorization, capture, refund, and receipt amounts reconcile. This division turns AP2 failures into observable states instead of a generic agent error.

Conformance tests should cross organizational boundaries. Test your merchant verifier against mandates created outside your SDK, and test your mandates against a separate verifier. Use fixed vectors for canonical hashes, disclosures, signatures, expiry boundaries, Unicode identifiers, currency precision, and reordered JSON fields. A system that validates only objects serialized by the same library can hide matching bugs on both sides. Interoperability begins when two independent implementations agree on valid and invalid evidence.

Use a contract like this at the boundary between your agent-facing checkout service and the deterministic authorization gate. The field names are an internal example, not an AP2 schema, and that separation is intentional.

```json
{
  "checkout_session_id": "chk_7f31",
  "checkout_version": 4,
  "merchant_checkout_jwt": "<signed-jwt>",
  "checkout_mandate": "<sd-jwt-presentation>",
  "payment_mandate": "<sd-jwt-presentation>",
  "payment_token": "<transaction-scoped-token>",
  "idempotency_key": "agent-order-0184"
}
```

The gate should return a stable decision shape such as `approved`, `user_required`, `declined`, or `invalid`, plus a machine-readable reason and evidence reference. Never return "try again" for a signature or constraint failure. Retries are safe for timeouts and explicit transient errors. A different checkout version requires new authorization, and a consumed one-time mandate requires a new mandate.

Before moving real money, involve payments, security, privacy, support, finance, and legal owners. Define who handles a claim that the agent chose the wrong item, who can inspect disclosed claims, how a user revokes open authority, how support identifies an agentic order, and what evidence reaches the processor or network. AP2 can make those conversations more precise. It cannot have them for you.

## A pilot should prove rejection before conversion

A safe AP2 pilot starts in a narrow product category with deterministic attributes, low fulfillment ambiguity, and a payment partner willing to inspect the evidence. Avoid regulated goods, complex substitutions, split shipments, marketplaces with unclear merchant-of-record boundaries, and irreversible purchases until the basic controls work.

1. Run the official sample with mock payment providers and capture every mandate, disclosure, verification decision, and receipt. Then replace one role at a time with your own deterministic service.
2. Build human-present checkout first. Freeze and sign a final checkout, render it on an independent trusted surface, and prove that any post-consent mutation forces reauthorization.
3. Add one autonomous case with exact merchant, item, quantity, currency, amount ceiling, expiry, and one-time use. Test simultaneous workers and user return when a constraint cannot resolve.
4. Put invalid and replayed cases in CI. Pin schemas and cryptographic test vectors, reject unknown versions, and alert on verification bypasses or unexplained user-required rates.
5. Move a limited internal cohort to a real processor only after support can trace an order from signed checkout through payment and receipts without reading a chat transcript.

Measure authorization outcomes, constraint rejection reasons, time spent in user-required recovery, duplicate attempts, checkout mutations after consent, processor declines, refund causes, and support resolution time. Conversion matters later. Early success means the system refuses the wrong purchase reliably and explains why in structured data.

This is also where team design matters. An AP2 pilot spans agent code, checkout, payments, identity, infrastructure, and operational policy. Adding separate specialists before you have stable boundaries can create months of coordination around a changing spec. A Team & AI Audit from oleg.is can map the work to a smaller AI-augmented engineering team and identify which payment and identity duties must remain under explicit human ownership.

AP2 is worth piloting if delegated purchases are part of your product thesis or a major distribution partner requires interoperable authorization. It is premature if your catalog cannot produce stable checkout state, your payment provider cannot scope credentials, or your team has no owner for disputes and revocation. Fix those foundations first. The protocol will change, but a signed checkout, deterministic policy gate, isolated consent surface, and auditable state machine will survive the next version.