Begin with the purchase the user actually authorizes
Suppose an analyst asks an AI agent to buy a financial report for a named supplier. The illustrative purchase costs $24, and the analyst permits a single matching report up to $30. The question is not simply whether the agent can access money. The merchant and payment participants need evidence that this purchase falls within the user's authority.
AP2 v0.2 distinguishes a checkout mandate from a payment mandate. The checkout mandate supports verification of the purchase, and the payment mandate supports verification of the associated payment. They are linked to the checkout rather than being independent approvals that can be freely attached to unrelated transactions. [1]
Use this separation when designing the user experience. Show the analyst which report is being purchased and the relevant payment terms. A vague confirmation such as go ahead can become ambiguous if the conversation includes several suppliers, report types or offers. A signed object is only useful if its contents correspond to an understandable decision.
This guide describes the published v0.2 model and a synthetic report purchase. It does not claim that every merchant supports AP2 or that a wallet advertising agent payments implements the same mandate revision. Check the actual integration participants and supported schemas before adopting the flow.
Map the participants and their checks
The specification identifies a shopping agent, credential provider, merchant, merchant payment processor and trusted surface. One organization can perform several roles. Responsibilities still need to be assigned explicitly so a rejected mandate can be traced to the verifier that evaluated it. [1]
In the report example, the shopping agent assembles the proposed purchase. The merchant owns the report checkout. The credential provider supplies a payment credential under the applicable authority, and the processor handles the payment role. The trusted surface presents consent in a setting intended for that purpose. Your architecture should name the actual component filling each role.
The specification requires validation and processing to occur in deterministic code. That boundary matters because a model can interpret a request or propose an action while still being treated as a possible source of untrusted behavior. Do not ask a language model to decide whether a cryptographic verification succeeded. [1]
When documenting the flow, write Merchant Payment Processor in full if MPP could be confused with the Machine Payments Protocol. AP2 uses that abbreviation for a participant role. The separate protocol bearing the same abbreviation is not automatically part of this purchase.
- Merchant: signs its checkout JWT, which is bound into the purchase authority.
- Trusted surface: obtains and signs the user-authorized closed mandate in direct mode, or open authority in autonomous mode.
- Shopping agent: in autonomous mode, signs the closed mandate using the key authorized by the open mandate.
- Merchant: verifies the checkout mandate before completing checkout.
- Credential provider and payment network: verify the relevant payment authority; the processor checks the credential for the checkout and returns the payment outcome. [1]
Bind purchase and payment to the same checkout
The merchant-signed checkout establishes the concrete object used in the mandate relationship. The checkout and payment evidence must point to that same purchase. In the synthetic report example, a payment permission for the $24 report should not be reusable for a different company's report or an unrelated service. [1]
A developer should trace the binding in the actual schema and verifier, rather than adding an arbitrary purchase ID and calling the result AP2. The protocol uses defined mandate types and cryptographic relationships. An application ID can help your own operations team, but it does not replace the specified verification.
The mandate schema revision is part of compatibility. The vct value includes an exact type and version suffix. Record that value and validate the implemented type rather than stripping the suffix to make two implementations appear compatible. The main specification's versioning section should be read alongside the detailed schema reference. [1]
Your acceptance record should identify the checkout, checkout mandate, payment mandate and corresponding receipts. It should be possible to show that each item belongs to this report purchase without exposing private keys or unrelated user intent.
The mandate relationship
- User authority
The trusted surface obtains approval for a specific purchase or bounded constraints.
- Merchant checkout
The merchant provides the signed checkout describing the actual report purchase.
- Checkout mandate
Purchase authority is bound to that checkout and evaluated by the merchant.
- Payment mandate
Payment authority is bound to the associated checkout and evaluated by payment participants.
- Receipts and result
Keep checkout and payment outcomes linked, then verify report delivery.
Compare direct approval with bounded autonomous authority
In the direct mode, the user sees and approves the specific closed checkout and payment. In the autonomous mode, the user approves constraints through open mandates, and the agent produces closed mandates for a purchase that satisfies those constraints. Verifying parties still receive the closed purchase evidence. [1]
For the report, direct approval means the analyst reviews the actual $24 offer. Autonomous authority means the analyst can leave after approving a bounded task, such as a permitted report within the relevant constraints. The integration must then establish that the concrete purchase fits the authority instead of treating the user's absence as unlimited consent.
An open mandate is not a conversational promise that the agent will behave. It creates authority with constraints and a cryptographic relationship to the agent and resulting purchase. Your user interface should explain the scope plainly before collecting the authorization. Avoid hiding a broad recurring permission behind a button that appears to approve one report.
The constraints matrix below is a conceptual review aid. It deliberately uses plain language instead of presenting an invented serialized AP2 payload. Implementations must use the current defined constraint types and evaluation rules where they claim AP2 compatibility.
Review the permitted purchase
Scroll the table to compare all columns.
| Term | Illustrative authority | Changed purchase | Recommended decision |
|---|---|---|---|
| Amount | One report up to $30 | $24 report | Proceed only if all other checks pass |
| Amount | One report up to $30 | $32 report | Request new authority or choose a permitted offer |
| Recipient | The approved report merchant | A different recipient | Do not treat the original permission as covering it |
| Purchase scope | The named supplier report | Another company or report type | Reevaluate scope before payment |
| Validity | Purchase within the approved window | Permission no longer valid | Obtain appropriate current authority |
| Verification | Valid signatures and checkout binding | Invalid signature or checkout hash mismatch | Reject verification; do not seek a model override |
| Result | Report matching the company | Empty or mismatched report | Record delivery failure separately from payment |
Evaluate changed terms before proceeding
Suppose the report offer changes from $24 to $32. Whether that change is permitted depends on the actual authority. Our illustrative $30 limit does not cover it. The agent needs a different permitted offer or a new user decision; it should not reinterpret the original request to erase the limit.
A price within the limit can still be a different purchase. A changed merchant, company identifier, report edition or payment instrument may violate another constraint. Evaluate the relevant combination. Checking only the amount is insufficient when the permission also concerns who is paid and what is received.
Expiry also needs a defined policy. A valid purchase yesterday does not establish authority today. Use the actual mandate and constraint rules for temporal checks, and make the rejection understandable to the application. An agent should know whether to retrieve a new offer, seek new permission or stop.
Include changed terms in your tests. Preserve the original authority and record the reason a modified checkout was rejected. This evidence is more useful than a happy-path screenshot when reviewing whether the integration respects the user's task.
Handle receipts and uncertain results
A checkout receipt and a payment receipt describe different aspects of the purchase. Keep their relationship to the mandate evidence intact. A payment result does not alone establish that the supplier report arrived, and a delivered report does not remove the need to understand the financial outcome. [1] [1] [2]
In the report workflow, the buyer should inspect the existing transaction when a response times out. A missing local response does not prove that the merchant rejected the purchase. Starting another overlapping attempt can create uncertainty about which authority or payment belongs to which result.
AP2's autonomous flow includes restrictions intended to prevent overlapping use of open mandates. Follow the exact specification and implementation rules rather than designing a retry loop from a simplified article diagram. Your application should make unresolved state visible to an operator and preserve the previous evidence. [1]
Define recovery ownership with the merchant and credential provider. The standard provides evidence structures, but your system still needs practical routes for status resolution, result retrieval and support. Do not advertise a universal refund or dispute outcome merely because mandates can be brought together as transaction evidence.
Minimize disclosures while preserving verification
A user's open authority may contain information irrelevant to one purchase. The specification's privacy model uses selective disclosure to share what the verifier needs. Treat that as part of the verification design, rather than sending every mandate and conversation transcript to every participant for convenience. [1]
For the supplier report, the merchant needs evidence relevant to its checkout. It should not receive unrelated procurement instructions merely because the agent knows them. Your logging policy should also distinguish a necessary purchase record from broad retention of user or supplier data.
Document which component stores which evidence and who can inspect it. An operations reviewer needs enough information to connect the purchase and payment, but does not need signing secrets or every hidden constraint. Keeping those boundaries explicit helps your integration remain understandable as more participants are added.
Build an implementation acceptance record
Begin with the direct purchase and name every role. Pin the mandate types, verify the checkout binding, confirm the actual payment path and inspect the two kinds of receipts. Add delivery validation for the report itself. This establishes a complete purchase scenario rather than only a signed-object demonstration.
Then exercise a changed recipient, an amount outside authority, an expired permission, invalid verification evidence and an unresolved response. A correct rejection is a useful result. Record the observed environment and exact outcome without turning it into a broad claim of security or universal interoperability.
If autonomous authority is required, add it after the direct path is understood. Explain the open permission to the user, enforce the closed purchase constraints and define recovery for overlapping or uncertain attempts. Agent-to-agent mandate delegation is described as outside the current specification's scope; do not invent a standardized delegation chain from the general idea of agents working together. [1]
The practical decision is whether AP2's authority model fits your participants and purchase. Keep commerce, payment processing and fulfillment responsibilities alongside it. The analyst should end with the right supplier report and an understandable evidence trail showing why the $24 purchase was permitted.