AP2 Protocol Implementation: Roles, Mandates, Flows, and What the Spec Leaves to You

Implementing AP2 starts with picking which of the six roles you are, because the protocol asks something completely different from each one. A merchant verifies mandates and checks that a signed checkout matches the cart it issued. A shopping agent assembles mandate content, gets it signed and carries it through the flow. A credential provider verifies a Payment Mandate and returns a token. Most teams that say they want to "implement AP2" turn out to need one narrow slice of it, and the fastest way to scope the work is to identify your role before reading another line of the specification.

The current specification lives at ap2-protocol.org, with reference code, a Python SDK and sample scenarios in Python, Go and Android in the google-agentic-commerce/AP2 repository on GitHub. It is Apache 2.0 licensed. Since April 2026 the core specification work has been stewarded by the FIDO Alliance rather than by Google alone. If you want the background on what AP2 is and why it exists, start with our guide to Google AP2; this piece is about what you actually have to build.

Step 1: pick your role

AP2 defines six participants. Your integration surface is entirely determined by which one you are.

Two of these deserve a warning. The Trusted Surface is the hardest role to implement honestly, because its entire job is to guarantee the human saw and understood what they signed. A rendering that summarizes a mandate inaccurately does not fail loudly; it produces a valid signature over something the user did not actually agree to. The Credential Provider is the one most teams should not build, since it means custody of payment credentials and the compliance surface that comes with it.

Step 2: understand the four credentials you will handle

AP2 mandates are verifiable digital credentials: signed, tamper-evident objects identified by a credential type claim. There are two mandate types and each has an open and a closed variant.

If you have read older AP2 material describing an Intent Mandate and a Cart Mandate, that was the September 2025 launch vocabulary and the field names differ from what you will find in the specification today. We walk through the change in agent payment mandates.

Step 3: implement the human-present flow first

It is the shorter path and everything in the delegated flow builds on it. In order:

1. The shopping agent assembles a cart with the merchant, and the merchant returns a signed checkout.
2. The agent retrieves instrument options from the credential provider and selects one.
3. The agent constructs the Payment Mandate and Checkout Mandate content and requests user approval through the trusted surface.
4. The trusted surface renders both mandates, authenticates the user, obtains consent, and signs both with the user key. A hash of the checkout JWT is embedded so the two mandates are permanently linked.
5. The agent sends the Payment Mandate to the credential provider, which verifies it and creates a payment token.
6. The agent sends the token and the Checkout Mandate to the merchant.
7. The merchant verifies the Checkout Mandate against the cart it issued, then initiates payment with the token and the checkout hash.
8. The merchant payment processor verifies the Payment Mandate and confirms the binding, and receipts go back to each party.

The detail worth pausing on is step 4. The link between the two mandates is a hash, not a convention, so a Payment Mandate cannot be paired with a different order after the fact. Getting that binding right is most of the security value of the whole exercise.

Step 4: add the delegated flow when you need it

The human-not-present flow arrived in version 0.2 and is the one businesses usually want, because it covers an agent buying while nobody is watching. The user signs open mandates up front describing what would be acceptable, and the agent's public key is recorded so only that agent can act on them. Later, when a matching checkout appears, the agent selects the open mandates whose constraints are satisfied, constructs the corresponding closed mandates, and signs them with its own key. A selective-disclosure hash binds each closed mandate to its open parent, so the merchant and processor can independently confirm both that the human authorized the boundaries and that the agent stayed inside them.

This is also where your implementation gets a hard requirement that is easy to miss. The specification states that to prevent double spending, the shopping agent must not create multiple overlapping mandates until it receives a receipt indicating an error. That obligation sits on the agent, which means it is your code, not the protocol, that stops the same open mandate being spent twice concurrently. Plan for idempotency keys and a lock around mandate selection before you ship.

What the specification deliberately leaves to you

AP2 is well scoped, and the flip side of good scoping is that several things you will need are simply out of frame.

• Key custody. The protocol assumes a user key and an agent key exist and are protected. Where those live, how they rotate and what happens when one is compromised is your design.
• Agent hardening. AP2's stated principle is verifiable intent rather than inferred action, precisely because a language model can be talked into things. That protects the payment record, not the agent. Before a shopping agent holds signing keys at all, it is worth blocking prompt injection and enforcing tool and data policy at the agent boundary, because a mandate signed by a manipulated agent is still a valid mandate.
• Cumulative budgets. Each mandate has its own ceiling. Nothing tracks what your agents have spent in total this month, across mandates, across agents, or over rails that never touch AP2.
• Approval workflows. There is no concept of routing a purchase above a threshold to a named approver and blocking until they respond.
• Revocation. Open mandates carry expiry, but operationally you will want to kill one agent's authority immediately without waiting for credentials to lapse.

None of these are gaps in the sense of oversights. They are the layer above the protocol, and if your agents are the ones spending company money, that layer is the part that determines whether AP2 compliance translates into spend you can actually defend at month end.

Should you build against AP2 now?

Build now if you are a merchant, processor or credential provider. Agent-initiated purchases are arriving over multiple protocols and you will need to verify authorization for them regardless, so the FIDO handover makes AP2 the safest of the available bets.

Wait, and watch, if you are a business deploying buying agents. The public tooling is still oriented toward samples and demos, SDKs and MCP servers are described as in development with payment service providers, and support will most likely reach you through your payment provider rather than through code you write. In the meantime your agents are already spending over ordinary card rails and metered APIs, which is a problem you have today rather than in a future release. Set per-agent limits, route the exceptions to a person, and record every decision in one place. When AP2 does arrive, a signed mandate becomes one more verifiable input to a policy you were already enforcing.