x402, AP2 and ACP All Stop at Authorization: What the Agentic Payment Rails Leave Out of Scope

In the nine months between September 2025 and June 2026, the payment industry shipped its answer to agentic commerce. Google announced the Agent Payments Protocol (AP2) with more than 60 partners - Mastercard, American Express, PayPal, Adyen, Coinbase, Worldpay among them - and donated it to the FIDO Alliance in April 2026. Stripe and OpenAI shipped the Agentic Commerce Protocol (ACP) behind Instant Checkout in ChatGPT. Mastercard and Google open-sourced Verifiable Intent in March 2026 and moved it onto a FIDO standardization track by May. Coinbase's x402 turned HTTP 402 into a live machine-payment rail.

Every one of these systems anchors the same moment: the authorization. AP2 and Verifiable Intent sign it, ACP scopes a credential to it, and x402's client signs the transfer it triggers. What none of them carries is signed evidence of what the agent then did with that authorization, a verdict on whether the delivered work was acceptable, or a settlement instruction bound to either. AP2 declares that layer out of scope in writing; x402's own FAQ states the sequencing; Stripe and Verifiable Intent simply do not document it. x402 comes closest and still misses: its batch-settlement scheme does defer settlement, but on metered consumption rather than on any verdict about the work. That layer is the record the rails assume someone else is keeping.

What each rail signs, and what it scopes out

AP2: a non-repudiable trail that ends at checkout

AP2 is the most complete trust design of the four. Its Mandates are, in Google's words, “tamper-proof, cryptographically-signed digital contracts,” and the launch post says that “this complete sequence—from intent, to cart, to payment - creates a non-repudiable audit trail.” For the authorization moment, that claim holds.

On what happens to that evidence when something goes wrong:

On getting the evidence back out: “Providing an automated method to retrieve the Checkout Mandate… would provide substantial utility to the ecosystem. The exact details are outside the scope of the current version.” And architecturally, AP2 describes itself as a security feature that operates withina commerce protocol - catalog, checkout, and settlement APIs are someone else's problem. There is no settlement-conditioning signal anywhere in it, and no mechanism that ties funds capture to evidence the work was performed. Google's launch post is explicit that the protocol “establishes the core building blocks” and creates “clear opportunities for the industry… to innovate on adjacent areas.”

Verifiable Intent: the authorization record, standardized

Mastercard and Google's Verifiable Intent, open-sourced in March 2026 at verifiableintent.dev, “creates a tamper-resistant, cryptographic record of what a user authorized when an AI agent acts on their behalf,” so that “in the event of a dispute, all parties can reference a clear audit trail rather than relying on contested or incomplete records.” It is protocol-agnostic, Apache-licensed, and on a FIDO standardization track.

Note what the record contains: what the user authorized. Not what the agent did, not whether the counterparty accepted the result, not whether the payment that followed matched a verdict anyone rendered. Verifiable Intent is the opening bracket of the transaction. The closing bracket is unspecified.

Stripe's ACP: scoped credentials, contractual trust

Stripe's Shared Payment Token is the credential that lets an AI platform spend a customer's payment method with a seller. Its documented trust controls are scoping. Stripe's seller documentation calls it “a scoped grant to use the customer's payment method”; the agent-side documentation says to “set usage limits, including currency, maximum amount, and expiration window.” The trust artifact between the parties is acceptance of Stripe's terms of service.

The merchant remains merchant of record, so card-network dispute machinery still applies, and Stripe's SPT lifecycle visibility is designed to reduce the likelihood of disputes. What the agentic-commerce documentation does not describe is an evidence model - no dispute-handling, liability-allocation, or settlement-verification layer between the agent platform and the seller. When an agent-initiated purchase is contested, the parties fall back on the same chargeback process designed for human cardholders, minus any signed record of what the agent was asked to do and did.

ACP and the Shared Payment Token are one Stripe surface rather than the whole picture. Stripe's agentic-commerce documentation now leads with the Universal Commerce Protocol, whose Order building block covers shipping, delivery and returns with webhook-driven lifecycle updates. That is post-purchase status: unsigned state transitions reported by the seller, not evidence bound to a verdict that a third party could verify offline. A delivery webhook says a parcel moved. It does not say the work was acceptable, and nothing conditions money on it.

x402: pay first, by design

x402 is the leanest of the rails: an HTTP 402 challenge, a client-signed transfer, a facilitator that - per the spec - “cannot modify the amount or destination” and “serve[s] only as the transaction broadcaster.” The integrity of the payment instruction is strong. The exposure is sequencing: the official FAQ describes the current exact scheme as “a push payment - irreversible once executed.” Funds move before the service is delivered, so a principal whose agent paid for work that never arrived, or arrived wrong, holds an excellent receipt that the payment happened - and no record at all of whether the paid-for work did.

The x402 ecosystem knows this, and has already shipped part of the answer. A batch-settlement scheme, including Cloudflare's deferred variant, merged into the spec repository on 2026-04-15, written because agentic transactions need “delayed settlement to account for disputes.” What it defers on matters: settlement waits formetered consumption, not for a verdict on whether the delivered work was acceptable. The primitive these rails still lack is settlement that waits on evidence of the work rather than on a usage counter.

The layer between authorization and money movement

Put the four scope boundaries side by side and the missing layer resolves into three specific artifacts. It is not an audit trail of authorization - the rails have that, signed and headed for FIDO. It is the account of the delegated work itself:

AP2 scopes out the dispute-side use of even its own evidence; execution evidence and verdicts never enter the document. Stripe documents none of the three. x402 is building toward the third from the crypto side. An independent analysis of the stack (arXiv 2602.00213) reaches the same conclusion.

Where a cryptographic notary fits

AGLedger is a self-hosted cryptographic notary for automated work. It does not move money, does not issue payment credentials, and does not replace any rail above - it produces the signed record those rails leave out.

The mechanism, end to end: an agent reports each unit of delegated work and the service signs what was reported - intent before action, evidence on completion - into a hash-chained, tamper-evident record naming the accountable principal. When the work is gated, the principal's accept-or-reject verdict is captured as a signed entry on the same chain; AGLedger holds the verdict, it never renders one. And when a gated record reaches its terminal state, a Settlement Signal™ - SETTLE on acceptance, HOLD on rejection, RELEASE when a dispute is re-opened and reverses a prior hold - is delivered to the payment, ERP, or ticketing system you register as the endpoint, signed by default with Ed25519 RFC 9421 HTTP Message Signatures so the receiving system can check it against the notary's published public keys before acting. The end-to-end mechanism - a delegated, signed, hash-chained work record carried through review to a settlement instruction bound to the verdict and chain position that produced it, provable across an organizational boundary - is the subject of US patent application 19/565,072.

Read against the rails: an AP2 Mandate or Verifiable Intent record establishes that the purchase was authorized. An AGLedger chain establishes what was done with that authorization and whether the principal accepted it. The Settlement Signal is the closing bracket - the instruction that tells the payment rail the verdict it is settling against, in a form it can check. The two halves compose: signed authorization in, signed settlement evidence out, with the rails carrying the money in between.

The rails scoped this layer out deliberately, and they were right to - it does not belong inside a payment protocol. It belongs beside one, held by a party whose only job is the record.

Scope of this comparison

First, the rails did not fail to build this layer; they scoped it out, explicitly, and AP2 in particular invites the industry to build on it. Second, this space is moving at standardization speed - AP2 went from announcement to FIDO donation in seven months, and the unspecified retention-and-retrieval layer could become a formal work item; treat any “out of scope” quoted here as a snapshot. Checked against the published specifications on 2026-08-13: AP2 and Verifiable Intent are unchanged since April, and no rail has added execution evidence, a verdict, or settlement conditioning. Third, x402's batch-settlement scheme shows the ecosystem closing its own buyer-protection gap. The durable gap is not reversibility mechanics but the independent, offline-verifiable record of work and verdict that any of those mechanics would still need to consult.

Fourth, and the closest thing to a counter-example: ERC-8183 does have all three artifacts structurally. A provider submits a deliverable, a designated evaluator alone calls complete() or reject(), and the contract releases or refunds on that call. Settlement conditioned on a verdict, on-chain. It is Draft status, EVM-only, and the deliverable is a bytes32commitment rather than a signed evidence record, and its own text says “no dispute resolution or arbitration; reject/expire is final.” So it binds money to a verdict without carrying the evidence the verdict was rendered on, and it does so only for parties who share a chain.

Worth watching for the same reason: draft-mih-scitt-agent-action-capsule, an individual IETF submission published 2026-06-13 that covers execution evidence and verdict disposition (accept, reject, needs input, deferred) and explicitly excludes settlement. It is not working-group adopted. If the layer described here gets standardized rather than built, SCITT is a likely venue.