DEV Community

Cover image for Google AP2: The Mandate Is Not the Payment
AI x Crypto Systems
AI x Crypto Systems

Posted on

Google AP2: The Mandate Is Not the Payment

Google AP2: The Mandate Is Not the Payment

Google AP2 is most useful when a merchant system asks the awkward question before payment: what proof says the agent was allowed to assemble this checkout? A later settlement event can be clean and still arrive too late to answer that question. For crypto payment flows, that matters because A2A x402 can move the payment conversation forward while Google AP2 keeps the authority evidence in mandates.

The tempting shortcut is to debug from the bottom of the stack. A developer sees a signed payment payload, a payment-completed status, and receipt metadata, then treats the purchase as explained. Google AP2 pushes the investigation upward: first identify the signed user instruction, the checkout authority, and the payment authority that made the later payment meaningful.

Merchant console pausing payment until checkout authority payment authority and task correlation preconditions are checked

Google AP2 Begins Before the Cart Closes

Google AP2 frames agent-led commerce around authorization, authenticity, and accountability. The AP2 specification names roles such as Shopping Agent, Credential Provider, Merchant, Merchant Payment Processor, and Trusted Surface, but the important engineering move is earlier than settlement. Before a merchant accepts an agent checkout, Google AP2 asks whether the right mandate evidence exists for that checkout.

In a human-present flow, Google AP2 can attach consent to a closed checkout and payment the user sees directly. In an autonomous flow, the user approves constraints first, and later mandates must stay inside those constraints. That difference is not cosmetic. It tells the verifier whether the purchase was directly approved at checkout time or bounded by prior authority.

The Trusted Surface has special weight in Google AP2 because user consent cannot be treated as another generated agent message. A language model can propose a cart, summarize a merchant response, or explain a payment request. Google AP2 still needs the non-agentic consent surface and mandate evidence that a verifier can check without trusting the model's narrative.

Trusted Surface approval shown as consent evidence beside a generated agent story that is not consent evidence

The Merchant Sees A Precondition, Not A Story

Google AP2 changes the merchant-side failure mode from "the agent asked for it" to "the mandate verified for this checkout." A polished request, plausible cart, and later payment receipt do not prove the Shopping Agent was authorized to buy those items. The merchant-side question is narrower: did the Checkout Mandate secure what is being purchased?

Merchant terminal blocking order completion before payment because Checkout Mandate authority is missing

Payment authority is a separate question in Google AP2. The Payment Mandate secures payment for the checkout, while the Checkout Mandate secures the purchase itself. That split matters because a valid payment path does not automatically prove the cart matched the user's instruction, and a valid checkout mandate does not prove funds settled.

AP2 receipts help reconstruct the transaction evidence picture, but Google AP2 does not turn receipts into legal outcomes or fraud guarantees. The specification's dispute evidence surface brings mandates and receipts together while leaving dispute procedures outside the protocol. Read it conservatively: Google AP2 improves the evidence available for a dispute question, but it does not settle the dispute by itself.

Payment precheck circuit breaker holding payment until mandate verification opens the path

A2A x402 Starts After The Precondition

A2A x402 belongs downstream of the Google AP2 authority check. The A2A x402 specification defines an Agent-to-Agent payment extension with data structures, message flows, and a state machine for requesting, authorizing, and settling payments inside A2A. That makes A2A x402 relevant to an AP2-backed commerce flow, but it does not make A2A x402 the AP2 mandate layer.

For developers, A2A x402 exposes concrete payment states. A Merchant Agent can return payment-required metadata, a Client Agent can submit a signed PaymentPayload, and the Merchant Agent can verify and settle before returning payment-completed or receipt metadata. Those states track payment progress. What they do not show is whether the payment pursuit had the right mandate context, which stays with Google AP2.

Task correlation is where A2A x402 gives the payment lane a useful handle. The specification says the client-side message includes the original taskId so the Merchant Agent can correlate a signed payment payload with earlier payment requirements. That taskId keeps the payment payload attached to the task, while Google AP2 keeps the task attached to user authority.

A2A x402 taskId thread marker connecting payment required signed PaymentPayload and payment completed events

A Merchant-Side Gate Keeps The Layers Apart

The clean implementation pattern is a precondition gate, not a post-payment apology. The following sketch is an article-side merchant model, not protocol-native AP2 or A2A x402 conformance code:

if not verified_checkout_mandate(checkout):
    hold("checkout authority missing")

if not verified_payment_mandate(checkout, payment_request):
    hold("payment authority missing")

if not correlated_task(payment_payload.taskId, payment_required.taskId):
    hold("payment task correlation missing")

continue_to_settlement()
Enter fullscreen mode Exit fullscreen mode

Google AP2 owns the first two holds in that sketch: checkout authority and payment authority. A2A x402 owns the third hold: payment task correlation inside the payment conversation. Settlement begins only after those questions are no longer being confused with one another.

That separation is why a payment hash or receipt metadata should not be the first line of the incident report. If the mandate evidence is missing, the developer can still describe payment outcome, but Google AP2 leaves the authority question unresolved. If the taskId correlation is missing, A2A x402 leaves the payment lane harder to connect back to the original requirement.

Incident log correcting the first line from payment completed to authority evidence checked before payment

Correlation Is The Debugging Handle

Google AP2 and A2A x402 answer different debugging questions. Google AP2 asks whether the agent had authority to pursue the checkout and payment under signed mandate evidence. The A2A x402 question is narrower and sits in the payment lane: did a signed payment payload answer the payment requirement for the same task, and did it then reach a settlement result?

The most dangerous record is therefore not an obviously failed payment. The dangerous record is a successful payment that starts in the middle: payment completed, service delivered, receipt stored, mandate chain absent. Google AP2 makes that record visibly incomplete because the successful settlement does not show the authorized checkout, the user constraints, or the verifier decisions.

A second incomplete record goes the other direction. Google AP2 mandate evidence can exist, but if the A2A x402 signed payload cannot be correlated to the original payment-required task, the payment lane has lost its own thread. The two protocols are stronger together only when mandate evidence and payment correlation remain separate and both are present.

The Final Question Comes Before Payment

Google AP2 is not a promise that agent commerce has no fraud, no chargebacks, or no liability ambiguity. It is a cleaner evidence boundary for authorization in agent-led payments. A2A x402 can still provide the payment and settlement path, but that path should not be asked to prove original user intent by itself.

The debugging question for a developer is not "did the agent pay?" Google AP2 changes the question to "what made this payment an authorized payment for this checkout?" If the answer starts with settlement, the system is already reading the evidence in the wrong order.

Command prompt asking what made this payment authorized for this checkout before settlement

Sources

AI assistance was used for source collection, structure, and editorial review. The article was reviewed by a human author before publication. This is a technical systems article, not investment, trading, yield, token-buy, or financial advice.

Top comments (0)