Beyond the Mandate: The Hard Problems AP2 Still Has to Solve for Agentic Commerce

Let’s be clear up front: the Agent Payments Protocol is a serious, necessary piece of work. Somebody had to sit down and ask how a piece of software proves it’s allowed to spend your money, and AP2 is one of the most credible answers on the table. We want it — and every effort like it — to succeed, because a healthy agentic economy needs shared rails, not a hundred private ones. This isn’t a takedown. It’s a map of the terrain the protocol has to cross.

Because paying is the easy part. Moving money between two accounts has been a solved problem for decades. The hard part is everything wrapped around the payment: proving who asked, what they agreed to, whether they still agree, who answers when it goes wrong, and getting everyone to speak the same language at once. A protocol for agentic commerce has to clear all of those gates. We covered the first, subtlest one — the mismatch between subscription-era mandates and one-shot agent purchases — in an earlier piece. Here’s the rest of the gauntlet.

1. Identity: which agent, acting for whom, under whose authority?

A card transaction has one actor. An agent transaction has a chain: a human, the platform that runs their agent, the agent itself, and increasingly sub-agents the agent delegates to. AP2 has to make that chain provable — binding a specific payment to a specific authorised agent instance acting for a specific person under a specific grant.

That’s genuinely hard. Keys have to be issued, held, rotated and revoked for non-human actors. Delegation has to be expressible and, crucially, bounded — an agent handing a task to a sub-agent must not be able to hand over more authority than it was given. And when a dispute lands, the identity chain has to reconstruct cleanly months later. Get this wrong and “an authorised agent bought this” becomes unfalsifiable — which helps no one, least of all the merchant.

2. Intent: a signature at grant time is not proof at settlement time

This is the deep one, and it’s why we wrote a whole post about it. A mandate captures what you agreed to when you set the agent going. But the charge lands later, for an amount and from a merchant that didn’t exist at grant time. The protocol can cryptographically prove you signed a mandate; it’s much harder to prove that this specific purchase is what you meant.

The gap between “authorised in principle” and “this exact charge, recognised” is where every unrecognised-transaction dispute is born. A protocol can narrow it with tighter mandate scoping, but narrowing isn’t closing — and the party who lives in the gap is the merchant.

3. Revocation: the stale-authorisation window

Grants that persist are grants that can go stale. If a mandate lives for days or weeks, three things have to work perfectly: the cardholder must be able to kill it instantly, that revocation must propagate to every party before the next charge, and an expired or cancelled grant must be impossible to replay. Distributed revocation with low latency is one of the genuinely unsolved problems in credentials generally — and here it’s standing between a bot and your bank account. A revocation that takes even minutes to propagate is a window; at machine speed, a window is an eternity.

4. Liability: the rails move faster than the rulebook

Here’s the tension no protocol can specify its way out of: you can define a beautiful new authorisation object, but the dispute and liability rules that decide who eats a bad transaction are written by the card networks and issuers, and they evolve slowly. Until those rules explicitly recognise a mandate-backed agent purchase as carrying the cardholder’s liability, the transaction gets adjudicated under the framework it most resembles — card-not-present — and CNP liability defaults to the merchant. A protocol can produce perfect evidence and still lose the argument, because the argument is refereed by rules that haven’t been rewritten yet. Adoption stalls not on the tech but on the rulebook lag.

5. Interoperability: the cold-start problem

A payment protocol is only as useful as the number of counterparties who honour it. AP2 has to be adopted by agent platforms, card networks, issuers, acquirers and merchants — simultaneously — while sitting alongside other emerging standards from the networks and the model providers. Each participant waits for the others: merchants won’t integrate until agents send volume, agents won’t standardise until merchants accept it, issuers won’t rewrite liability until both exist at scale. That’s a classic multi-sided cold start, and it’s usually decided by incentives and market power, not by whose spec is most elegant.

6. Human trust: keys and recovery for people who aren’t cryptographers

Underneath the mandates sit signatures, and underneath signatures sit keys that ordinary people have to custody, use and recover. The subscription world hid all of this behind “card on file.” An agent-authorisation world that asks a normal customer to understand delegated credentials — and to not lose the one that authorises their spending — has a UX and recovery problem as large as any of its cryptographic ones. If losing a key means losing your agent, or if recovery means a backdoor, the trust model has a hole in it either way.

The meta-challenge: the party with veto power has to win on day one

Every item above is solvable in principle. The meta-problem is sequencing: a protocol that requires merchants, issuers and networks to change how liability works before it’s proven at scale is asking the parties with veto power to take the first risk. Merchants, in particular, will not run agent traffic that raises their chargeback ratio while the rules catch up — they’ll simply block it. Any path to agentic commerce that routes through “merchants absorb the ambiguity for a few years” doesn’t route anywhere.

Where Orchard28 stands

None of this makes us anti-AP2 — the opposite. We expect to interoperate with it as it matures, and we want the standards war to end in a good standard. But we couldn’t ask merchants and customers to wait for six hard problems and a cold start to resolve. So we solved them pragmatically, at the transaction layer, today:

• Identity and intent collapse into one act. The cardholder personally commits each run with their own card PIN through CPoI (paywithCPoI.com). That single act binds the purchase to the person and to this exact outcome, cap and window — no separate identity chain to reconstruct, no gap between grant and charge.
• It’s card-present, so liability is already settled. A PIN-committed, card-present transaction carries issuer liability under rules that already exist — no waiting for the rulebook to be rewritten.
• Revocation is trivial because grants are tiny. There’s no long-lived mandate to go stale: a single-use virtual card, capped and scoped, dead after settlement, with an instant kill switch on the run.
• Interop risk falls on us, not the merchant. As merchant of record, Orchard28 is the counterparty a seller transacts with, so they get a clean, funded, dispute-resistant payment regardless of how the upstream standards shake out.

AP2 is trying to standardise the whole gauntlet for everyone, and that’s important work we’re rooting for. In the meantime, the way to give people agentic commerce that actually holds up is to not depend on winning every gate first — but to build so that the transaction is safe even while the industry is still arguing about the rules.