Skip to content

Specification lab · AP2

AP2 Checkout and Payment Mandates explained

AP2 secures what an agent buys and how it pays through two linked mandates. They are related, but they have different audiences and proofs.

AP2 version 0.2 defines two mandate types. The Checkout Mandate proves that the Shopping Agent is authorized to purchase a merchant-defined checkout. The Payment Mandate proves authorization to pay for that checkout. A cryptographic reference binds the payment evidence to the merchant-signed checkout.

Key takeaways

  • The merchant verifies the Checkout Mandate.
  • Credential and payment parties verify the Payment Mandate.
  • Both mandates are linked to the merchant-signed checkout.
  • Signed receipts record acceptance or rejection for later evidence.

What does the Checkout Mandate authorize?

The Checkout Mandate authorizes completion of a checkout assembled by the Shopping Agent. The merchant first creates a signed checkout object. A closed Checkout Mandate carries that signed object and a hash that identifies it. The merchant verifies that the mandate refers to the checkout it issued.

The AP2 Checkout Mandate page defines versioned credential types. A closed mandate uses mandate.checkout.1, while an open mandate uses mandate.checkout.open.1. Implementations must match the exact versioned vct value required by the current schema.

What does the Payment Mandate authorize?

The Payment Mandate authorizes payment for a specific checkout. Its required data includes a transaction identifier derived from the checkout, the payee, the payment amount and the payment instrument. The specification represents the amount in currency minor units with an ISO 4217 currency code.

Verification involves the Credential Provider, any applicable Network and the Merchant Payment Processor. This is a different audience from the Checkout Mandate, even though both are part of the same purchase.

How are the two mandates linked?

AP2 links mandate evidence through a hash of the merchant-signed checkout. The Checkout Mandate identifies that checkout. The Payment Mandate binds payment authorization to the same transaction. This prevents a valid payment approval from being detached and reused for unrelated purchase terms.

The signing and hashing rules are security-sensitive. Implement them from the current AP2 schemas and algorithms. Do not copy placeholder keys or shortened hashes from an article into production.

Who creates and verifies each object?

Object Assembled by Signed or authorized through Primary verifier
Checkout object Merchant Merchant signing process Merchant compares it with the mandate
Checkout Mandate Shopping Agent User or authorized agent flow Merchant
Payment Mandate Shopping Agent User or authorized agent flow Credential and payment parties
Checkout Receipt Merchant Merchant Shopping Agent and later dispute review
Payment Receipt Payment side Relevant payment party Shopping Agent and later dispute review

One organization can play several roles, but it inherits every verification responsibility for those roles.

What do receipts contribute?

After accepting or rejecting a mandate, the relevant verifier returns a signed receipt. The checkout receipt records the checkout result. The payment receipt records the payment result. AP2 describes how mandates and receipts can later be combined to reconstruct what each party authorized and processed.

The specification does not define every retention or retrieval policy for disputes. Implementers must separate AP2 cryptographic verification from legal retention decisions in each jurisdiction.

Validation checklist

Use deterministic tests for:

  • Exact vct values and schema versions.
  • Signature validation for every issuer.
  • Checkout hash recomputation.
  • Equality between the merchant checkout and authorized checkout.
  • Payment amount in correct currency minor units.
  • Binding between payment and checkout evidence.
  • Receipt reference to the corresponding closed mandate.
  • Rejection when any required proof fails.

AP2 operates as a security feature within a commerce protocol. Catalog APIs, checkout update operations and communication endpoints remain outside AP2’s scope. UCP compatibility does not make AP2 the whole payment layer of UCP.

Primary sources and review date

Related implementation guides