What Is an Agent Payment Mandate? AP2 Fields Explained

An agent payment mandate is verifiable authorization for an agent to pay on a user’s behalf. In AP2, it connects payment permission to a particular checkout. Use it to establish whether the agent has permission to pay for the checkout being presented.

This reference explains the mandate’s fields and the evidence around them. For choosing budgets, approved merchants, and recurring-purchase limits, use our guide to how AP2 limits agent spending.

For the wider reading path, the Agent Identity Learning Center links this field reference to agent identity and commerce guides.

Updated September 21, 2026.

Checkout approval and payment authority

AP2 gives the merchant a checkout mandate to verify purchase approval. The credential provider, network, and merchant payment processor verify payment authority. One company may handle several roles, but each responsibility still needs an owner.

The shopping agent assembles the mandate content. In a direct flow, a trusted surface obtains the user’s approval of the completed transaction. In an autonomous flow, the user approves an open mandate and the agent later presents a closed mandate under that delegated authority. The verifier receives the closed transaction in either case. See the AP2 specification for the roles and flows.

Watch the abbreviation: AP2 uses MPP for Merchant Payment Processor. That abbreviation also names the separate Machine Payments Protocol. Our x402, AP2, and MPP comparison covers the protocol choices.

Read the payment mandate’s fields

The AP2 payment mandate reference defines the following content. A decoded payload is only one part of the signed evidence.

Check the exact version your integration accepts. The current reference’s Type section specifies versioned values, while its schema table contains an inconsistent unversioned label. The specification’s versioning rule requires the exact suffix. Resolve that discrepancy against the implementation you are testing.

Read the example without mistaking it for a credential

This illustrative fragment makes the amount readable. It omits other required content, signatures, disclosures, and key binding; it cannot authorize a payment.

{
  "vct": "mandate.payment.1",
  "payment_amount": {
    "currency": "USD",
    "amount": 27999
  }
}

Keep application metadata separate from protocol fields. An agent’s public name or your internal receipt-storage URL may help your team find records, but adding those properties to JSON does not make them AP2 claims or prove who signed it.

The Agent Authorization Framework describes verification of the signed mandate chain. An open mandate identifies the endorsed agent key through cnf. Verification must also preserve inherited claims and evaluate the open mandate’s constraints against the closed transaction. An unknown constraint fails evaluation.

Trace the checkout binding before accepting the result

Consider a hypothetical review: two purchases have the same price and merchant, but different checkout JWTs. Matching the visible amount would not establish that a mandate authorizes the checkout in front of you. Your verifier needs to check the binding to that exact checkout.

Keep the serialized evidence used in verification. AP2’s implementation guidance explains that consistent representations are needed for hash calculations and recommends retaining compact mandate serializations with their disclosures for dispute review. A prettified JSON export is useful for reading, but should not replace the signed artifact.

Then inspect the returned payment receipt. Its reference binds it to the closed mandate. Check the issuer and reported status before relying on it. For reconciling payment with order fulfillment, continue to payment receipts and purchase evidence.

Perform verification in deterministic code. AP2 requires this even when the participating role uses an LLM. The model saying “the numbers look right” cannot replace that check.

What a valid signature leaves unresolved

A signature protects the signed record’s integrity. It does not establish that every product claim or tool response used to choose the purchase was reliable.

An AP2 security preprint submitted August 24, 2026 examines that boundary. Its authors show how manipulated context before authorization can affect a transaction despite valid mandate signatures. Their demonstrations use a research testbed, so they should not be presented as evidence of a breach at a deployed payment provider.

EMVCo’s September 1, 2026 draft framework addresses another practical problem: maintaining consumer-authorized intent across participants and over time. It proposes Intent Services for coordinating that information. This remains a draft for industry feedback, not a new AP2 mandate field or proof that every processor supports the same controls.

In your implementation review, identify the component that checks signed authority and the one that tracks previous uses. Record what each actually enforces.

Where HeadlessDomains.com fits

A persistent agent name helps people and compatible software find the public information its operator maintains. HeadlessDomains.com provides API-based identity discovery, with records pointing to manifests and service information. Agents can inspect those records through CLI and API workflows.

Use that public identity alongside your payment evidence when it helps identify the actor. The relying system still needs a verified relationship between the name, operator, and transaction key. AP2 does not require a Headless Domains name, and registering one does not issue payment authority.

Keep buyer approvals, payment credentials, and private receipts in access-controlled systems. Publish only the service information suitable for public discovery.

To give your agent a maintained public identity, start with the HeadlessDomains.com skill file. Ask your agent to explain the registration requirements and the records it would publish before taking action.

If you are setting up a public identity for your agent, read the HeadlessDomains.com Getting Started guide. Keep payment approvals and credentials in the systems that manage them.