Table of Contents
The decision is no longer hypothetical. Agents are placing orders, calling paid APIs, and reaching checkout pages today, and a merchant who has not decided anything has still made a decision by default.
The instinct is to treat this as a payments question. It mostly is not, because the money arrives the same way it always did, through a card network or a stablecoin transfer that your processor already understands.
What changes sits either side of the payment. You no longer know whether the buyer is a person, you cannot assume anyone reviewed the purchase, and the rules for what happens when the agent gets it wrong have not been written.
Accepting an agent payment is not a new rail. It is accepting a buyer who cannot be phoned, cannot be reasoned with, and whose owner may dispute the purchase afterwards.
Key Takeaways
- The rail is not the issue. Identity and authorisation are what change.
- No liability shift exists yet. Non-fraud agent disputes remain unallocated.
- Agents can now be verified cryptographically. Signed requests replace user-agent guessing.
- Blocking bots may block customers. Fraud tools cannot tell them apart.
- Start where disputes are rare. Digital goods and paid APIs first.
What Actually Changes for a Seller
Three assumptions break when the buyer is software, and each one maps to a control you probably do not have.
The first is identity. Your fraud stack was built to decide whether a human is who they claim to be, and it has no category for a legitimate program buying on someone's behalf.
The second is authorisation. A card on file implies a person who typed the details once, while an agent purchase implies an instruction somebody gave at some earlier point, in words you will never see.
The third is recourse. On stablecoin rails the payment is final and there is no chargeback, which is a genuine benefit until the day an agent's owner insists the purchase was never approved, and our guide to who bears the loss sets out how that allocation tends to fall.
What to note: write down which of those three you can answer today, because the weakest one is your actual exposure.
Telling a Real Agent From a Bot
This was the strongest argument against accepting agent traffic until recently, and it now has a technical answer.
Classification used to rest on the user-agent string and the IP address, both of which can be spoofed, so a merchant choosing to admit agents was effectively choosing to trust a header. The replacement is cryptographic. Agents sign their requests using HTTP Message Signatures under RFC 9421, which gives each one a stable, verifiable identity rather than a claimed one.
The commercial piece is who publishes the keys. Visa and Mastercard each maintain a directory of agents registered with them, referenced by the key identifier in the signature header, so a merchant can check an Ed25519 signature against the network's own record of that agent.
The useful detail for a seller is that the signature can distinguish what the agent is doing. The protocols add a tag separating an agent that is browsing from one that is paying, plus a nonce against replay, so you can allow research traffic and treat a payment attempt differently.
What to note: this is the control that makes agent acceptance a policy choice rather than a gamble, so check whether your CDN or WAF already validates signed agents.
The Dispute Question Nobody Has Settled
Here is the part that deserves more caution than most coverage gives it.
Outright fraud is reasonably well handled. Where an agent authenticates properly and a token is issued correctly, liability follows existing tokenised transaction rules, the issuer carries the fraud risk, and the cardholder keeps their chargeback rights.
Everything short of fraud is open. An agent that misreads an instruction, buys the wrong variant, or purchases something the shopper says they never sanctioned produces a loss that is currently being negotiated between issuers, acquirers, agent platforms and merchants, with no liability shift in place.
The regulatory frame has the same hole. Consumer rules in the US assume a transaction was either authorised or not, which leaves no category for an instruction that was misinterpreted, while strong customer authentication rules in Europe can stop an agentic transaction completing at all.
What to note: without a signed record of what the shopper authorised, a disputed agent purchase tends to resolve in the cardholder's favour.
Two Rails, Two Different Risks
The rail you accept on changes the shape of the risk rather than its size.
Card acceptance keeps you inside the framework you already operate, and the networks have built entry points for it, with Visa piloting its agentic commerce programme since April 2026 and Mastercard publishing an acceptance framework that works under existing merchant agreements. You keep dispute exposure and friendly fraud, including the new variety where a shopper blames an agent for a purchase they wanted at the time.
Stablecoin acceptance inverts that. Settlement is final, there are no chargebacks, and per-request pricing becomes possible, which is why agent-to-service payments concentrate there, as our coverage of USDC agent payments documents. The trade is that a mistaken or contested payment has no formal reversal process at all.
Most merchants will end up accepting both, which makes the receiving side an operational question. A multi-currency business account with cards, limits, and approval rules is the usual home for it, and Airwallex pairs that with cashback on eligible transactions at 2%, which returns something on the tooling and infrastructure spend that testing agent acceptance creates anyway.
What to note: decide the rail per product rather than per company, because a returnable physical good and a metered API call carry opposite dispute profiles.
Where Agent Acceptance Makes Sense
| What you sell | Accept from agents | Why |
|---|---|---|
| Paid APIs, data, compute | Yes, and prioritise it | Agents are the natural buyer and disputes are rare |
| Digital goods and credits | Yes, with spend caps | No shipping risk and delivery is instantly verifiable |
| Standardised consumables | Cautiously, on cards | Repeat purchases suit agents, returns stay manageable |
| High-value or bespoke goods | Not yet | Dispute exposure is large and liability is unallocated |
| Regulated or age-restricted items | No | Verification obligations assume a human buyer |
The pattern down the table is dispute probability rather than order value. Anything a human might later regret in words is the category to leave until the rules exist.
What to note: the first row is the one most businesses overlook, and it is where agent revenue is actually arriving today.
What to Put in Place First
1. Decide your policy before your traffic does
Choose explicitly whether agents may browse, may buy, and up to what value. An undocumented policy means your bot rules are making commercial decisions nobody reviewed.
2. Verify agents rather than block automation
Blanket bot blocking now turns away paying customers, so admit signed, network-registered agents and keep blocking the rest. That distinction is the whole point of the signature directories.
3. Keep the proof, whatever the rail
Store what the agent presented, what it was authorised to buy, and what you delivered. A signed mandate or a verifiable receipt is the difference between a defensible transaction and a concession.
4. Set acceptance limits per agent and per period
Cap value per transaction and per day for agent-initiated orders, and require human step-up above the line. Limits are cheaper than disputes and easier to explain to a customer.
5. Turn it on narrowly and watch one metric
Enable one product or endpoint, and track dispute and refund rate for agent orders against human ones. The stablecoin side is straightforward to pilot, and our guide to accepting stablecoins covers the setup.
What to note: review after one full billing cycle, because agent traffic patterns change faster than your fraud rules do.
Risks and Limitations
- Liability is genuinely undecided: network rules set a baseline and contracts fill the rest, so your exposure depends on agreements rather than on settled rules.
- Friendly fraud has a new script: a shopper can claim an agent acted alone, and without a signed record that claim is hard to rebut.
- Programmes are early: several network offerings remain in pilot or limited rollout, so capabilities differ by acquirer and region.
- Finality cuts both ways: no chargebacks removes a cost and removes your customer's formal remedy, which some buyers will decline.
- Compliance assumes humans: age checks, suitability rules, and consumer disclosures were written for a person at the keyboard.
Conclusion
Should your business accept payments from AI agents? For paid APIs, data, and digital goods the answer is yes, and the main cost of waiting is revenue going to a competitor whose endpoint accepts a signed request.
For physical, high-value, or regulated goods the honest answer is not yet. Fraud liability is roughly settled, but the loss from an agent that simply buys the wrong thing has no owner, and merchants without a signed record of authorisation are the party most likely to absorb it.
The work in the meantime is small and worth doing. Verify agents instead of blocking automation, keep the proof of what was authorised, cap what an agent may spend, and start with the products where a disappointed buyer has nothing to dispute.
Read Next:
FAQs:
1. Can a merchant tell whether an AI agent is legitimate?
Yes, increasingly. Agents can sign requests using HTTP Message Signatures under RFC 9421, and the card networks publish directories of agents registered with them, so a merchant or its CDN can verify the signature against the network's record rather than trusting a user-agent string.
2. Who is liable when an agent buys the wrong thing?
That is unresolved. Where an agent authenticates correctly, fraud liability follows existing tokenised transaction rules with the issuer carrying fraud risk, but losses from an agent misreading an instruction are still being negotiated between issuers, acquirers, agent platforms and merchants, and no liability shift exists.
3. Do agent payments have chargebacks?
On card rails the cardholder's chargeback rights remain intact. On stablecoin rails there is no chargeback at all, which removes dispute cost for the merchant and removes the buyer's formal remedy at the same time.
4. Should I just block all automated traffic instead?
That is now a commercial decision rather than a security one, because blanket blocking turns away buyers as well as scrapers. The better approach is to admit signed, network-registered agents while continuing to block unidentified automation.
5. What should a business accept from agents first?
Paid APIs, data, compute, and digital goods or credits, because delivery is verifiable and there is little to dispute. Physical, high-value, bespoke, and age-restricted items are the categories to hold back until liability rules are written.
Disclaimer:
This content is provided for informational and educational purposes only and does not constitute financial, investment, legal, or tax advice; no material herein should be interpreted as a recommendation, endorsement, or solicitation to buy or sell any financial instrument, and readers should conduct their own independent research or consult a qualified professional. Card network programmes, agent verification standards, and liability rules for agentic transactions are changing quickly and vary by acquirer and jurisdiction; confirm your own obligations and protections with your acquirer and with qualified counsel before enabling agent acceptance.
