AI Growth Hub
← Tool Comparisons

AP2 v0.2 and Human Not Present Payments: How AI Agents Will Pay on Your Checkout

agentic-payments ap2 ai-checkout

For most of the last year, the interesting question about AI shopping agents was not whether they could find a product. They could. The hard part was the last step: how does anyone trust a payment that an agent made on a buyer’s behalf? If your store gets a charge initiated by some shopping assistant, who actually approved it? Did the user really want this exact cart, at this exact price? And if it goes wrong, who is on the hook?

The Agent Payments Protocol (AP2) is the open protocol that tries to answer that. Google first announced it in September 2025. The version worth paying attention to now is AP2 v0.2, released on GitHub on April 28, 2026. Around the same time, AP2 was donated to the FIDO Alliance, which means it is no longer a single vendor’s spec but moves toward open, multi-party governance. That governance shift matters more than any single feature, because merchants are not going to wire their checkout to something one company can change or abandon at will.

The Trust Problem AP2 Is Built To Solve

Think about what a normal card payment carries with it. There is an implicit chain: a human held the card, entered the details, clicked pay. The “intent” and the “action” happened in roughly the same moment, from the same person. Chargeback rules, fraud models, and your own dispute process all quietly assume that chain exists.

An agent payment breaks that assumption. The human might have said “find me running shoes under 120 dollars and buy the best one” on Monday, and the agent might actually buy on Thursday when a price drops. The intent and the action are now separated in time, and a piece of software did the action. Without something to bind those two events together, a merchant has no reliable way to know the charge was authorized, and the buyer has no clean way to prove what they did or did not approve.

AP2’s answer is to make the whole chain explicit and cryptographically signed, so that every link from “what the user wanted” to “what got charged” can be verified after the fact. Nobody has to take anybody’s word for it. That is the real product here: not faster checkout, but provable accountability for a payment a human did not personally click.

The Three Mandates

AP2 structures authorization as three signed “Mandates.” A Mandate is just a signed, tamper-evident record of one decision in the chain. Together they form an auditable trail from intent to settlement.

MandateWhat it capturesSigned byRoughly answers
Intent MandateThe user’s instruction and its limits (what to buy, budget, constraints)The user (their agent on their behalf)“What did the buyer actually authorize?”
Cart MandateThe specific cart: exact items, prices, merchant, totalsThe merchant side, confirmed against intent”Is this concrete cart inside what was authorized?”
Payment MandateThe final payment instruction tied to that cartThe party executing the payment”Was this exact charge the approved one?”

The point of splitting it into three is that each step is checkable against the one before it. The Cart Mandate can be tested against the Intent Mandate: did the agent stay under the budget, buy the right category, respect the constraints? The Payment Mandate ties the actual charge to that specific cart, so a processor or merchant can confirm the money movement matches the approved cart rather than some substituted one.

For a merchant, this is the part that changes your dispute posture. Today, “the agent did it” is a scary, ungrounded claim. Under AP2, you can point to a signed chain. If a buyer disputes a charge, the Mandates show what they authorized, what cart that produced, and that the payment matched. It does not make disputes disappear, but it moves them from “your word against ours” to “here is the signed evidence.”

What “Human Not Present” Unlocks, and What It Risks

The headline addition in v0.2 is the Human Not Present (HNP) flow. Earlier agent-payment thinking assumed the human was there to confirm at the moment of purchase, basically a fancier checkout button. HNP covers the other, more powerful case: pre-authorized or delegated payments that the agent can execute later, on its own, without the human in the loop at transaction time.

Human PresentHuman Not Present
When intent is givenAt purchase timeEarlier, in advance
Who confirms the chargeThe human, liveThe agent, within the pre-signed Intent Mandate
Typical useAssisted checkout, agent fills the cartSubscriptions, auto-restocks, price-triggered buys
Main riskLower, human catches errorsHigher, no live human check at execution

This is what makes agent commerce genuinely useful instead of a novelty. “Reorder my dog food when it runs low,” “buy these concert tickets the moment they drop under face value,” “keep my subscription topped up” are all HNP behaviors. The buyer sets the rules once, and the agent acts inside them.

The flip side is obvious and worth saying plainly. When no human is present at execution, the Intent Mandate’s limits are the only thing standing between a useful purchase and a bad one. If those limits are loose, sloppy, or compromised, the agent will faithfully execute something the buyer did not really want. The signed chain still tells you what happened, but it cannot tell you the buyer’s intent was wise. Merchants should expect new failure modes here: stale price triggers, duplicate restocks, agents acting on outdated intent. The accountability is better; the need for sensible guardrails is greater, not smaller.

What A Merchant Should Do Now

First, set expectations internally. This is early, evolving infrastructure. v0.2 is a real release with real governance behind it now, but the ecosystem of agents, wallets, and processors that speak AP2 is still forming. The right posture is “build understanding and run a small pilot,” not “re-platform checkout this quarter.”

To actually accept agent-initiated payments under AP2, the practical path has two pieces. You pick a merchant-of-record or checkout layer that supports agent commerce, such as UCP or ACP, and you pair it with a payment processor that is AP2-capable. You are not implementing the cryptographic Mandate plumbing yourself; you are choosing partners who handle that and expose it through your checkout. Treat it like adopting any new payment rail: the protocol is the standard, your processor and checkout layer are how you touch it.

A concrete starting sequence:

  1. Confirm whether your current payment processor has an AP2 roadmap, and ask where Human Not Present support sits on it.
  2. Look at your checkout or merchant-of-record layer and check for agent-commerce support (UCP, ACP, or equivalent). This is where Mandates get validated against carts.
  3. Decide which HNP use cases even apply to you. Subscription and consumable-restock sellers have an obvious case; one-time high-consideration purchases, much less so.
  4. Tighten the data the Mandates depend on: accurate, current pricing and availability in your feed, because a Cart Mandate built on stale data is a dispute waiting to happen.
  5. Pilot narrow. One product line, clear limits, watch how disputes and refunds behave with a signed chain attached before you widen it.

AP2 v0.2 is the first version where the trust story for agent payments feels coherent, and the FIDO Alliance donation gives it a credible path to becoming shared infrastructure rather than one company’s project. Human Not Present is what makes it commercially interesting and operationally riskier at the same time. Merchants do not need to rush, but they should understand the model now, because the question is shifting from “will agents pay?” to “are you set up to accept it safely when they do?”

阅读本文中文版: AP2 v0.2 与「人不在场」支付：AI 代理怎么在你的收银台付钱

Related Articles