While Google‘s AP2 Overview Video does a good job of covering the basics, I find it lacking when breaking down the flow into steps in it’s example. If you’re a payments nerd like me, I know you love a numbered, easy to digest payments value-chain flow/diagram with the different players. This video and breakdown is my understanding of how the AP2 works, bearing in mind that actual implementations will vary depending on the payment method, use-cases and players.
Human Present Flow
1. The User instructs the Shopping Agent to purchase an item. For example, a user asks Gemini to order a Pizza Peperoni from Dominos.
2. The Shopping Agent (Gemini) interacts with the Merchant (Dominos) via the merchant’s MCP endpoint or AI agent, to create a cart with the requested pizza. In this interaction, things like price, product availability, the user’s address, accepted payment methods and delivery options and are exchanged.
3. The Merchant prepares a Cart Mandate which it cryptographically signs, guaranteeing that it’ll fulfil the order at the indicated price. The Cart Mandate indicates the accepted payment methods and other sale conditions. The Merchant signed Cart Mandate is passed to the Shopping Agent.
4. The Shopping Agent then queries the User’s Credentials Provider for the available and compatible payment methods based on the details of the Cart Mandate. The Shopping agent doesn’t access the raw payment credentials, only aliases or tokens are accessed.
5. The Shopping Agent now presents the Cart Mandate and the compatible Payment methods for the user to select a payment method and approve the purchase. This can manifest as a final confirmation request showing the cart, delivery details as well as a selection of compatible payment methods
6. The User selects the payment method and authorizes the purchase. In practice, the authorization manifests as the user’s device signing the Cart Mandate and a Payment Mandate. This involves some form of authentication with the Credential Provider (like how an app invokes Google or Apple Wallet/Pay during an in-app-pruchase, triggering a biometric authentication). The Shopping Agent now has a Cart Mandate signed by the merchant and user, as well as a user-signed Payment Mandate.
7. The Shopping Agent passes the Cart & Payment Mandates to the Merchant for order fulfilment.
8. The Merchant validates the Mandates and processes the order, sending the Payment Mandate to the Merchant’s PSP for processing. Depending on the payment method, the Cart Mandate might be passed as well.
9. The PSP executes the payment instruction defined in the Payment Mandate according to the protocols of the selected payment method and its respective Payment Network and Issuers. This could involve submission of the mandates to the networks & issuers as well as interaction between the networks, issuers and the Credentials Provider to confirm the Payment Mandate’s user authorization before the payment is approved, allowing the Merchant to fulfil the order.
Thanks to the Verifiable Credentials (VCs), i.e. the Cart Mandate and Payment Mandate. There is a deterministic, non-repudiable proof of authorization from the user. In case of any disputes, VCs offer a clear audit trail that will bring about quick resolution.
Human Not Present Flow
This is my understanding of how the Human Not Present flow might work. Keep in mind that it might differ from the eventual protocol version release that defines the flow.
1. The User instructs the Shopping Agent to make a purchase when specific conditions are met. For example, the user might say “Buy me a 2 week return Economy class ticket for Amsterdam to Entebbe sometime in April or May 2026 that’s under 900 when its available.” This exchange includes answering clarifying questions from the Shopper agent such as, whether there’s any particular Airline(s) the user would want to book with.
2. The Shopping Agent validates the conditions by interacting with the potential Merchant Airlines via their MCP endpoints or Merchant AI agents. This could manifest as the Shopper Agent checking which Airlines operate in the requested route, confirming their accepted payment methods, fare ranges, schedules, baggage allowance and other ticket conditions.
3. With the scope of the applicable Merchants, their accepted payment methods; potential fares and other conditions defined … the Shopping Agent then requests for the user’s compatible payment methods from the Credential Provider, ensuring that they meet the user’s & the merchant’s requirements for the potential purchase.
4. The Shopping Agent presents an Intent Mandate to the user to review and approve. It that outlines the purchase conditions, potential merchants, validity period and compatible payment methods in/with which the Agent can make the purchase on the user’s behalf. Think of this as a sort of pre-signed Cart Mandate. This manifests in the form of a confirmation request with all the necessary information for the user approve.
5. The User selects a payment method and approves the Intent Mandate. Specifically, the user’s device signs the Intent Mandate, cryptographically capturing the conditions under which the Shopping Agent is authorized to make the purchase in the user’s absence. In this step, some form of user authentication is performed that involves the Credential Provider. A user signed Payment Mandate is also generated, capturing the user’s authorization to use the selected payment method per the conditions of the Intent Mandate.
6. The Shopping Agent continually checks with the Merchants whether the specific conditions outlined in the signed Intent Mandate have been met. Once met, the Shopping Agent interacts with the Merchant for the preparation of a Cart Mandate with the ticket purchase. The Merchant signs the Cart Mandate and passes it to the Shopping Agent.
7. Armed with the User-pre-signed Intent Mandate and the pre-signed Payment Mandate, the Shopping Agent links the Cart Mandate to the Intent Mandate, essentially embedding the user’s authorization onto the Cart Mandate making it a fully signed Mandate. The Shopping Agent then passes the Cart and Payment Mandates to the Merchant for order fulfilment.
8. The Merchant validates the Mandates and processes the order, sending the Payment Mandate to the Merchant PSP for processing. Depending on the payment method, the Cart and Intent Mandate might be passed as well.
9. The PSP executes the payment instruction defined in the payment mandate according to the protocols of the selected payment method and its network and issuers. This could involve submission of the mandates to the networks & issuers as well as interaction between the networks, issuers and the Credentials Provider to confirm the payment mandate’s user authorization before the payment is approved by the parties involved, after which the tickets can be issued by the merchant.
Like in the Human-Present flow, there is a cryptographic, non-repudiable audit trail across all the parties that verifies the user’s intent and authorization in case of disputes.
Thoughts on the Human-not-Present Flow
It will be interesting to see how this is manifested in the real world, and how granular the conditions can be encoded depending on the merchant’s industry. Would a user for example be able to specify the class of seating, meals, assistance available?
How will these conditions be stipulated in the Intent Mandate technically speaking, in a manner that can be clearly understood by the AI Shopping Agent with no room for hallucination or misinterpretation? In Text, Numbers, JSON? Whatever the means used, the Payment Networks & Issuers will certainly have a major say.
This isn’t so much a problem in the human-present flow since the user is around to give their final approval before the purchase is made. In the human-not-present flow however, there might be room for misinterpretation of qualifying conditions on the part of the AI Shopper. Perhaps it won’t matter since the Payment Networks/Issuers also get to check whether the conditions indeed match those on the Intent Mandate.
I imagine there will be implementations of this flow that include a requirement for the user to confirm the order within a couple of days once the purchase is made, otherwise it’s cancelled (with/without a fee).
There could even be a world where the user-signed Intent Mandate is shared with potential merchants so that a merchant prepares the Cart Mandate as soon as the conditions are met. This would be valuable information for Merchants. They would know how many purchases lie waiting in specific scenarios. It would make for an interesting black Friday & cyber-Monday.
Thank you for watching and reading. Drop a comment below and let me know how you think these flows might play out in different payment method use-cases. I look forward to geeking out on further releases and Agentic Payments Protocols.
