When the Agent Reaches for the Card
· 9 min read

When the Agent Reaches for the Card

By Orestes Garcia


The card networks spent forty years optimizing a system around a single human gesture: the pause before you pay. Agentic commerce deletes the pause. Nobody rebuilt the control that was hiding inside it.

That is the whole problem, and it is bigger than fraud. The pause was never just friction. It was the moment a present human, looking at a specific price on a specific page, converted intent into authorization with one click. Every downstream system, the issuer’s risk model, the chargeback flow, the merchant’s liability posture, was calibrated to that click. Take the human out of the loop and you have a payment system that still moves money perfectly and can no longer tell you whether the money should have moved.

The click was load-bearing infrastructure

Reconstruct the old checkout and notice how much agreement was compressed into it. A human was present. A page displayed the price. A credential was used. A button was clicked. Everyone in the chain, issuer, acquirer, merchant, network, agreed on the shape of that evidence, so disputes had a common language. The click was the point where intent, identity, and consent collapsed into one signed artifact.

Agentic commerce does not just change who clicks. It destroys the shared evidentiary structure that made the whole system resolvable. When an agent buys on your behalf, authorization gets stretched across time, systems, and intent. The moment you told the agent your goal is separated from the moment it chose a product, which is separated from the moment it paid, which may be separated again when a downstream agent it hired pays a third one. Each seam is a place where liability can fall through, and none of the seams existed in the click model.

Take the canonical failure. You tell an agent to book a hotel room under 300 dollars. It books a non-refundable room that technically fits the budget and violates what you actually meant. The payment succeeded. The authorization is the thing in dispute. No card network primitive was built to adjudicate that, because in the human model the two were never separable. This is the same class of problem I traced from the pricing side in The 48-Hour Repricing: the system executes flawlessly against a mandate nobody pinned down precisely enough.

Payment is not authorization, and the protocols finally admit it

The single clarifying idea in this whole space is that a payment system can move money without proving the money should have moved. Payment and authorization are different layers. The human click fused them. Agents pull them apart, and once they are apart you need a separate, verifiable answer to a question checkout never had to ask: was this agent permitted to act, and did it stay inside the limits it was given?

That question is where the competing proposals actually diverge. It is tempting to read the current landscape as a format war over checkout UX. It is not. It is a disagreement about where the authorization boundary sits and whether the proof of authority travels with the transaction. Map the camps on that one axis and the picture gets sharp.

Six camps, one axis

Six serious efforts are converging on agentic payments, and each one plants the authorization boundary in a different place.

ACP, the Agentic Commerce Protocol from OpenAI and Stripe. The bet is a clean checkout that happens inside the conversation. The agent surface owns the buying moment; the merchant keeps liability but loses the discovery surface, because the assistant now controls ranking and bundling. Authorization boundary: at the agent surface. It is a good answer if you are rebuilding commerce from scratch and a hard sell to merchants who do not want to hand ranking to the assistant.

UCP, the Universal Commerce Protocol backed by Shopify, Google, and a broad merchant coalition. The opposite bet: preserve the full complexity of real merchant systems, keep control on the merchant side. Right when you are wrestling with production merchant infrastructure at scale, wrong if you thought you could rebuild it clean. Authorization boundary: on the merchant.

Here is the catch that unites the first two. Neither ACP nor UCP answers whether the agent was allowed to pay in the first place. They standardize the checkout. The permission question sits one layer deeper, and that layer is a different camp.

AP2, the Agent Payments Protocol from Google. This is the one built for the boundary itself. AP2 is essentially a mandate: the scope of the task, the constraints, and cryptographic proof the user approved it, established before the merchant is even known. Authorization begins upstream of the purchase, not at the register. When something goes wrong, the dispute system can show what the user asked for, what the agent was permitted to do, and whether it stayed inside those limits. A receipt cannot do that. A mandate can. Authorization boundary: with the user’s delegation, traveling ahead of the agent.

The card networks: Visa, Mastercard, PayPal. Their play is the trusted transaction layer they already run: tokenized credentials scoped to an agent, agent registration and identity, and the dispute and chargeback infrastructure that took decades to build. They are not trying to own intent. They are extending the credential so it knows an agent is holding it. Authorization boundary: baked into the credential.

Coinbase and Stripe on stablecoin rails. Different problem entirely. Consumer cards keep working for consumer purchases because they carry refunds, fraud monitoring, and consumer protection. But an agent paying a few cents for a model call, or buying a single API request, or paying per task instead of per month, is too small, too frequent, and too software-native for card-fee checkout. The mechanism here is HTTP 402, the “Payment Required” status code that has sat unused in the web’s design since the beginning. x402, which Coinbase introduced and has since moved under a neutral foundation, embeds the payment in the web request itself: software requests a resource, receives payment instructions, pays, gets access. Stripe’s MPP, its Machine Payments Protocol, targets the same machine-to-machine surface, agents paying for services, tools, data, and compute, not consumer carts. Authorization boundary: in the wallet and the request, machine to machine.

AWS, at the runtime. Amazon Bedrock AgentCore governs the agent’s identity, access, and policy at the layer where it executes, and the tell is that AWS does not need to own the payment protocol at all. It owns the runtime the agent runs in. The runtime sees the task, the tools, the policy, the budget, and the full action history. A payment provider only sees the payment. Authorization boundary: at the execution environment, as a governance layer wrapped around whatever rail the money uses.

Same money movement in every case. Six different answers to where the permission lives.

Six agentic-payment approaches plotted on a single authorization-boundary axis, from user delegation at the upstream end to the execution runtime at the downstream end: AP2, ACP, UCP, the card networks, x402 and MPP, and AWS AgentCore

Authorization unbundling is the real design fork

The old purchase flow hid responsibility inside one human action. Unbundle it and every hidden question becomes a line item someone has to own:

  • When the agent finds the product, who owns the recommendation?
  • When it requests permission, who records the approval?
  • When it pays, who owns the credential and the risk?
  • When the buyer wants a refund, who handles the return?

Call this authorization unbundling. It is the agentic-payments analog of the liability unbundling the card networks quietly perform every day, and it is the fork the whole space is standing at. One branch keeps authorization fused to payment and hopes the credential carries enough context. The other branch treats authorization as a first-class object, a signed mandate that exists before the payment and can be checked after it. AP2 and the AWS runtime model are both betting on the second branch from different altitudes, one at the delegation layer, one at the execution layer. The card networks and the checkout protocols are, mostly, betting the first branch is good enough.

An enterprise architect should read that split the way you read any identity decision, because that is what it is. Deciding who is allowed to spend is an authorization problem wearing a payments costume, and authorization problems are won or lost on identity resolution. I made the general version of this case in Data Identity Resolution: you cannot govern an actor you cannot uniquely and durably identify. An agent with a scoped credential but no verifiable mandate is exactly the actor you cannot govern, because you can prove it paid and never prove it was allowed to.

The seam nobody has closed: the agent-to-agent handoff

Here is where the maturity claims fall apart, and where the honest architect has to slow down.

Every one of these proposals handles a single agent buying from a single merchant reasonably well. Almost none of them handle the handoff. When your procurement agent hires a research agent that hires a data-broker agent, the mandate has to travel across two boundaries it was never signed for. Does the original user delegation propagate? Does each hop attenuate the scope, the way a good capability system narrows authority as it is passed down? Or does authority silently amplify because nobody built the attenuation, and the third agent ends up spending against a budget it was never granted?

That is the same unsolved seam I wrote about in Foundry and Fabric, transplanted from orchestration into payments. In that piece the gap was context and trust crossing the agent-to-agent boundary. Here it is authority and money crossing it. AP2’s mandate model is the only camp even structurally positioned to carry delegated authority across a handoff, and even there the multi-hop attenuation story is a proposal, not a shipped, examined standard. x402 moves value across the seam beautifully and says nothing about permission. The card credential does not travel at all; it terminates at the merchant. So the most consequential case in the whole agentic economy, agents transacting with agents, is the case the current specs are weakest on. Do not let anyone sell you interoperability here as a solved thing. It is a whiteboard.

What a regulated shop should actually demand

Strip the protocol politics and the requirement is boring and old. If you run anything under supervision, you already know the standard, because your examiner has asked for it about every other consequential decision in the building: reconstruct the intent, the authority, and the boundary, months later, from a record.

So the question to put to any agentic-payment vendor is not “can your agent pay.” Of course it can pay. The question is whether the company can define, as separable and provable artifacts, all six of identity, permission, payment, settlement, refund, and liability. If it cannot, it is not ready to let agents transact under governance, whatever the demo shows. A payment receipt is not evidence of authorization. It never was. The human click made it look like one for forty years by fusing the two, and now that the fusion is gone the receipt is just proof that money moved, which was never the thing your control framework actually needed to know.

The standards are being written this quarter. AP2, ACP, UCP, x402, MPP, the network agent programs, the runtime governance layers, all of it is draft, all of it is contested, and the authorization boundary is the axis every one of them is really arguing about. Pick your seat at that table by asking one thing of each proposal: when this agent hands the task to another agent, does the permission travel with it, and can you prove where it stopped? Everything else is checkout UX.


The pause was the control. We are shipping the payment system that removes it faster than the authorization model that would replace it, and the gap is measured in trillions of dollars of unassigned liability. Build the record before you build the agent.

I write about AI-assisted development, enterprise architecture, and the regulated-industry constraints that shape both. Find me on X @orestesgarcia or LinkedIn /in/setsero.