Agents That Pay

A declined card is a person. I wrote that earlier this year about a payment that failed at a till, and I still think it holds. The mirror image has just become a real engineering problem: an approved card may not be a person at all.

Card networks and AI companies spent the last year building ways for software to spend money on your behalf. The plumbing is clever, and most of it is sensible. But read the announcements closely and you find the same silence in all of them, in the one place a payments engineer looks first. Not how the agent pays. Who pays when it was wrong.

What the Plumbing Gets Right

In June 2026 Visa announced a partnership with OpenAI. Visa's release says agent transactions "will use tokenized Visa credentials and real-time authorization and fraud monitoring", inside "clearly defined user permissions, policies and controls" such as "spending limits, merchant categories or required approvals." Mastercard had said the same shape in April 2025 with its Agent Pay: Agentic Tokens, and "complete control over what the agent is allowed to purchase on their behalf."

OpenAI's own delegated payment specification shows how small and exact the grant is. The agent does not receive a card number. It receives a token tied to an allowance, and the allowance has a reason (one purchase), a maximum amount, a currency, the checkout session it belongs to, the merchant, and an expiry time. The spec says the token "cannot be used outside the defined limits of the user-approved purchase."

I like this design. It is the principle of least privilege, applied to money. Every field narrows the damage an agent can do if it is wrong, manipulated or simply misreads what you wanted. Read the list again: amount, merchant, time, one use. Each is a limit on authority.

What a Token Cannot Carry

Now ask the question a payments engineer asks about any authorisation: what does it prove?

An approval has only ever proved that a credential was valid and funded. It never proved that the person meant it. For years that gap was small, because a human was usually the one pressing the button, and when a human was not, the dispute system existed to sort it out. A cardholder says "I did not authorise this", and the evidence decides.

Put an agent in the middle and that sentence splits in two. "I did not authorise it" can mean what it always meant: someone else used my card. Or it can mean: my agent did, and it did not do what I intended. The first is fraud. The second is a misunderstanding between a person and software, and no existing dispute reason was written for it.

Google's agent payments protocol, AP2, names the problem more plainly than anyone. It lists three questions that current systems cannot answer: whether the user gave the agent authority for this specific purchase, whether the agent's request reflects the user's real intent without errors or hallucinations, and who is accountable for a fraudulent or incorrect transaction. Then it does something honest. It raises the third question and does not answer it.

Who Pays Is Still Open

I went looking for the rule. Visa's release does not mention disputes, chargebacks or liability, and gives no launch date. Mastercard's mentions "supporting consumer disputes" and says nothing on liability. OpenAI's delegated payment spec says only that "settlement, refunds, chargebacks, and compliance remain with the merchant and their PSP", and that OpenAI is not the merchant of record.

I did not find a card network publishing an agent-specific chargeback rule. What I found instead was commentary from the dispute industry, and it disagrees with itself: one analysis puts the loss on the merchant, another on the issuer, another on the cardholder. None of it comes from a rulebook. Treat that as the honest state of things: the technology to pay shipped before the rule about paying wrongly.

That does not mean the old rules vanish. It means the burden falls on whoever can show what was intended. That is you, if you are the one building.

The Intent Record

The way to be ready is not a cleverer token. It is a record, written at the moment the agent acts, of what it was asked and what it understood.

I would keep five things for every agent purchase:

• the instruction the person gave, in their words, with the time;
• the agent's reading of it: what it decided to buy and why;
• the allowance it was given: amount, merchant, expiry, the single use;
• the cart as the merchant received it, and the total it was charged;
• anything the person was shown and confirmed before the money moved.

Three design choices follow from the same logic.

Scope the credential to the action, not to the agent. A standing permission to spend is an invitation. A one-purchase allowance with its own expiry is the same lesson that Securing Systems When the Attacker Has Agents Too draws about least privilege.

Set the cap below the amount that would hurt. An agent that can be wrong should be allowed to be wrong cheaply. Raise the threshold for approval as the risk rises, and keep a human in the loop where the purchase cannot be undone. The autonomy dial in The Loop Around the Model applies to money exactly as it does to files.

And design the refund path before the happy path. OpenAI's spec is plain that refunds and chargebacks stay with the merchant and their payment provider. A product that lets an agent buy without a plan for taking the purchase back has built half a checkout.

The Inversion

When I wrote about declined cards, the lesson was that a payments system is judged by what it does to a person at the worst moment. A Declined Card Is a Person was about the system saying no to someone who was right.

The agent case is the inverse. The system says yes, correctly, to a credential that was valid, and the person at the other end says: that is not what I meant. Both are failures of the same kind. Both come from a machine that answered the question it was asked instead of the question that mattered.