Settlement Evidence for Agentic Commerce: What AP2, ACP, and x402 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 concedes the sequencing; Stripe and Verifiable Intent simply do not document it. This post walks the four boundaries, quoting the specifications where they speak, and describes the layer that has to exist on the other side of them.

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 protocol claims that “this complete sequence — from intent, to cart, to payment — creates a non-repudiable audit trail.” For the authorization moment, that claim holds. Anyone building an agent-payments product should treat signed purchase intent as solved infrastructure, not white space.

Then the specification draws its own boundary. 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 record of what a user authorized,” so that “if a dispute occurs, all parties can rely on a clear audit trail.” It is protocol-agnostic, Apache-licensed, and on a FIDO standardization track; signed authorization is on its way to being shared infrastructure rather than anyone's product.

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: “An SPT is a scoped grant to use the customer's payment method… Set usage limits, including currency, maximum amount, and expiration window.” The trust artifact between the parties is acceptance of Stripe's terms of service.

To be precise about what that means: 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.

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 genuinely 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. Escrow appears in the spec repository as future work, and Cloudflare proposed a deferred scheme specifically because agentic transactions need “delayed settlement to account for disputes.” The direction of travel is toward exactly the primitive these rails currently lack: settlement that waits for evidence.

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. And this is not a gap only we see: at least one published analysis of the stack — authored, full disclosure, by a team building a competing verify-then-pay product — reaches the same conclusion. A competitor's existence is the strongest evidence that the layer is real, and that it will be contested.

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 declare out of scope.

The mechanism, end to end: an agent reports each unit of delegated work and the notary engine 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's automated re-adjudication overturns a prior hold — is delivered to the payment, ERP, or ticketing system you subscribe, signed by default with Ed25519 RFC 9421 HTTP Message Signatures so the receiving system can check it against the Server's published 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 value-moving system 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.

What we are not claiming

Three boundaries, for the record. 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 June 2026 snapshot. Third, x402's ecosystem is actively closing its own buyer-protection gap with escrow and deferred schemes; 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.