Who carries the loss when an agent buys the wrong thing

A payment agent is easy to authorise and hard to unwind.

The specifications published this year answer the first half well. Google's AP2 signs the customer's intent as a verifiable credential. Visa carries a verified agent identity into the authorisation message. Mastercard's Agent Pay steps up to a passkey. All three answer the same question: was this agent allowed to pay.

Then the purchase turns out to be wrong. The mandate was valid, the agent was exactly who it claimed to be, and the customer wants their money back. That question lands on a bank's dispute desk, and the documents that were so precise about authorisation go quiet.

What a dispute desk actually looks at

When a customer says they don't recognise a transaction, the bank's disputes team works through a short list. Where the transaction happened. Which merchant took it. How the payment was confirmed. The strongest single item on that list is whether the customer authenticated themselves, and 3-D Secure is the usual proof of it. Where the bank cannot see that, and cannot see any sign that the customer passed their card details to somebody else, the money goes back to the customer and the argument starts between the banks.

In Europe "goes back" understates it. Article 73(1) of PSD2 requires the payer's provider to refund an unauthorised transaction immediately, and no later than the end of the following business day, with one narrow exception where the provider has reasonable grounds to suspect fraud and reports them in writing to the national authority. Visa's own rulebook puts the steps in the same order: rule 1.10.1.1 requires the issuer to credit the cardholder before it initiates a dispute at all. The refund comes first. Who ends up paying for it is worked out afterwards, when the issuer returns the transaction to the acquirer and the scheme rules on liability between the two of them.

Where 3-D Secure stops

A successful authentication closes the fraud route between the banks. Under Visa's dispute rules a fraud dispute is invalid where the transaction ran with electronic commerce indicator 5, the issuer answered the authentication request with a confirmation, and the authentication value was present in the authorisation. The issuer cannot recover from the acquirer at all.

The bank's obligation to its own customer runs on different rules, and in Europe the law is explicit about it. Article 72(2) of PSD2 says that the recorded use of a payment instrument is in itself not necessarily sufficient to prove that the payer authorised the transaction. Article 74(2) goes further: where the payer's provider did not require strong customer authentication, the payer bears no loss at all unless they acted fraudulently.

Read those together and a bank can be barred from recovering the money and still be obliged to hand it back, which is the position an agent walks into.

The rules already know what an agent is

This is the part most of the commentary has missed. The Visa Core Rules of 18 April 2026 added a section on agentic platforms. It defines an agentic transaction as an electronic commerce transaction undertaken on behalf of a cardholder, completed without direct interaction between the cardholder and the merchant, and it states that the initiators of those transactions are not merchants. The agent sits on the customer's side of the transaction.

The obligations follow from that. Before it acts, the provider has to obtain the cardholder's acknowledgement that they are responsible for what the agent does, and it has to verify the cardholder's identity before it stores a credential and again before it acts on an instruction. At the moment the payment instructions are presented, the wallet has to verify the cardholder through an approved device method.

That is a reasonable answer to the authorisation question, and it is the answer I would have argued for. Agentic payments should not get their own rail. The existing processes are tuned, and a second route means a second copy of everything that has to be secured and reconciled. What genuinely changes is that not every credential can be checked by a person inside the bank any more, so the verification has to sit in the platform and the escalation to a human has to be strict.

And then they stop

Open the dispute chapter of the same rulebook and the agent almost disappears. The word occurs twice in the entire chapter, both times only as a login identifier that a merchant may submit as evidence. There is no dispute condition for an agent-initiated purchase, no entry making such a dispute invalid, and no clause allocating the loss.

The European side is emptier. The technical standards on strong customer authentication, Delegated Regulation 2018/389, contain no reference to an agent, to autonomy, or to a merchant-initiated transaction. The EBA opinions on strong customer authentication carry none either. The closest thing to a test is an EBA question and answer from 2019, which holds that card transactions imply an action of the payer and are therefore treated as initiated by the payer through the payee. It was written about recurring mandates, six years before anyone was buying through an agent. These are counts taken from the documents themselves rather than from anybody's summary of them, and the absence is the finding.

So the schemes have put a contract term where a liability rule would normally go. A cardholder acknowledges responsibility for what their agent does. In Europe that acknowledgement runs straight into Article 74(2), which is mandatory law and doesn't care what the parties agreed: no strong customer authentication, no loss for the customer.

No published document answers which of the two wins. Put that question to your own legal and risk people before an agentic API goes anywhere near production, because the answer decides whose balance sheet absorbs the first wave of bad purchases.

None of this is an argument for waiting

Agentic payments are coming whether or not any particular bank is ready, and they move more than the payment itself. Transaction flow changes. Volumes change. The risk models, the fraud monitoring and the onboarding models all have to be re-fitted to a payer who is sometimes a piece of software. A bank that opens an agentic API early, even for small amounts, also buys something that is hard to buy any other way, which is customers seeing their own bank on the front edge instead of two years behind it.

What I would build first is the harness rather than the feature. Strong guardrails on the bank's side. A strict path that escalates to a human the moment something looks wrong or cannot be verified. And a dispute process that already knows what an agent-initiated transaction looks like before the first one arrives, because the alternative is learning that on live money.

The part that decides whether any of it holds

One more thing, from having shipped new confirmation methods inside banks. Integration is rarely what fails. Adoption is what fails. Moving a prompt from the middle of the screen to the top is already friction for a customer. A method that switches screens on a phone costs more than that. A method the customer has to go and enable costs more again, and some customers simply don't have the hardware for it. Every one of those comes out of transaction volume, and volume is the thing the whole exercise exists to protect. Without a good experience you don't keep the volume, and the method the customer never completes is the one the bank paid to build.

Mastercard's chargeback guide sits behind a login, so everything above is Visa's public rulebook and EU law as it stands in September 2026. PSD3 and the payment services regulation are still proposals, so these article numbers are the current ones and will move.

Agentic commerce will be argued about on the authorisation side for another year, because that is the half with specifications behind it. The dispute path has no specification yet, and it is where the cost of getting this wrong actually shows up.