Protocol

AP2

Agent Payments Protocol

The merchant-signed checkout carries the ATR hash, and the buyer’s Checkout Mandate commits to that checkout. Source: lcp docs: agentic checkouts⁠ (opens in a new tab)

AP2, the Agent Payments Protocol, was originated by Google and is now governed by the FIDO Alliance. Source: LCP §C.5⁠ (opens in a new tab) Integra is not affiliated; we read their published interfaces.

Sources (1)

lcp docs: agentic checkouts⁠ (opens in a new tab)

The protocol’s own site⁠The standard’s illustration of this protocol (LCP §C.5)⁠

What it is

AP2 is an open protocol for agent-driven payments, built on mandates: verifiable digital credentials that capture what a user authorized. Source: LCP §C.5⁠ (opens in a new tab)

AP2 defines no transport: the protocol that carries the mandate does. Source: LCP §C.5⁠ (opens in a new tab)

Sources (1)

LCP §C.5⁠ (opens in a new tab)

Where the ATR hash rides

The checkout the merchant signs carries the ATR hash, and the buyer’s mandate commits to that checkout.

The standard

The merchant signs a checkout_jwt whose payload carries the ATR hash as its legalContext member; the buyer’s closed Checkout Mandate commits to that JWT through checkout_hash, the SHA-256 of the JWT. Source: lcp docs: agentic checkouts⁠ (opens in a new tab)

The seller reads the ATR hash from inside the mandate. AP2 has the credential provider verify the Payment Mandate before a payment credential issues; the pairing’s record states which signatures the seller did and did not check. Source: lcp docs: pairings reference⁠ (opens in a new tab)

A reference written into an open mandate’s constraints would fail validation: that array is a closed set, and a new constraint type is registered through the FIDO Alliance working groups that govern AP2. Source: LCP §C.5⁠ (opens in a new tab)

What a payment through it proves

Each pairing’s record states what a payment through it shows, and what it does not, in the package’s own words. These are read from the package when the site is built. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Of these 1 pairings, 1 have the buyer’s signature cover the ATR hash, 0 leave a public proof of it, and 0 let anyone read it back from the chain alone. Source: lcp docs: pairings reference⁠ (opens in a new tab)

Switch to Technical to see each pairing, and the sentence its record states about what a payment through it proves.

Sources (1)

lcp docs: pairings reference⁠ (opens in a new tab)

The standard

ap2/checkout-mandateOpaque ChallengeBuyer signs H: yesH on chain: noPublic proof: noRecoverable from chain: no
Pattern: Opaque Challenge (LCP §8.3.4)⁠ (opens in a new tab)
What a payment through it proves: Before this payment, the buyer signed and paid an agreement transaction carrying this ATR's hash on <network>, recorded in <transaction>. The buyer's closed AP2 Checkout Mandate carries checkout_hash, the SHA-256 of the checkout JWT the seller last sent, and that JWT's payload carries this ATR's hash as its legalContext member. The seller read both from inside the mandate. The mandate's signer is the user's trusted surface, or the agent under the user's open mandate. The seller did not verify that signature: AP2 has the Credential Provider verify the Payment Mandate, whose transaction_id is the same hash, before a payment credential issues. The seller reported the payment. This does not show that amount, payee or timing match the ATR's content.
LCP profile: ap2/checkout-mandate⁠ (opens in a new tab)

Where a sentence names <network> and <transaction>, the pairing’s record fills them in: they name the agreement payment the buyer made first. Source: lcp docs: pairings reference⁠ (opens in a new tab) · Source: lcp docs: the agreement URL⁠ (opens in a new tab)

The rails it settles on

A checkout through this protocol is paid by the provider the checkout names, so it lists no rail of its own.

The live demonstrations are not running on this site at the moment.