Payments and AI
Two very different conversations are taking place under the same heading, and they have almost nothing to do with each other. Boards often discuss one and fund neither.
Two conversations, not one
The first is about using AI within the payment operation you already have: fraud decisioning, authorization, disputes, and onboarding. The returns are measurable, the technology is usually bought rather than built, and the decision can be treated like any other investment case.
The second is about a buyer arriving at your checkout who is not a person. That conversation is moving quickly, the technology remains unsettled, and nobody has fully answered the liability question.
Boards often discuss the second conversation and fund neither. The first useful step is to separate them.
Where AI already earns its place
Fraud and authorization are the obvious starting points. Model-driven decisioning has been standard among larger processors for years, and the commercial case increasingly rests on approval rates rather than fraud losses.
At meaningful transaction volumes, a one-percentage-point improvement in approvals can be worth more than most fraud savings. The important question for your provider is therefore not only what its models block, but what they do to acceptance.
Disputes are another clear use case. Preparing evidence for representment is repetitive, document-heavy work that lends itself well to automation.
Chargeback guarantee products go further by moving the fraud loss onto the provider’s balance sheet. But merchants often miss an important distinction: a reimbursed loss is still a recorded dispute. The guarantee changes who absorbs the financial loss, but it does not improve your ratio under scheme monitoring. An account can be fully indemnified and still end up in a monitoring program.
The third area is underwriting, and it works in both directions. Acquirers increasingly use models to score applications before a person reviews them. That changes what a strong application looks like. Consistent information, structured data, and machine-readable documents now influence outcomes in ways a persuasive cover letter cannot.
The buyer who is not a person
Over the past eighteen months, agentic commerce has moved from demonstrations towards infrastructure. Card networks moved early to ensure this activity would take place on their rails.
Mastercard launched Agent Pay in April 2025, using tokens issued to a delegated agent, and has since extended the concept to machine-initiated transactions. Visa announced Intelligent Commerce a day later. In October 2025, it followed with the Trusted Agent Protocol, which lets an agent identify itself to a merchant through signed request data rather than a new class of token. Google published the Agent Payments Protocol in September 2025 with a large group of partners, including both card networks. OpenAI and Stripe introduced the Agentic Commerce Protocol around the same period. In June 2026, Visa announced that it would integrate Intelligent Commerce into OpenAI experiences, with tokenized credentials, real-time authorization, and consumer-defined controls covering spending limits, merchant categories, and human approval.
Alongside this is a second settlement camp. Stablecoin protocols designed for machine-to-machine payments have their own standards initiatives and backers. One plausible near-term outcome is that card rails serve consumer retail while stablecoin rails support high-frequency machine payments.
None of this is settled. The protocol names describe current participants in a contest, not established standards for a long-term strategy.
The genuinely unresolved question
When an agent buys the wrong thing, who pays?
No regulator has provided a clear answer. The European AI Act deals with risk classification and transparency, not payment liability. A future revision of European payment-services rules may address the issue, while the United Kingdom has been consulting on authentication and agentic AI.
For now, the merchant remains the merchant of record under every major protocol. In practice, that leaves the merchant exposed.
The immediate problem is evidence. A representment file normally relies on device fingerprints, behavioral signals, and browsing history. In an agent-initiated transaction, those signals may not exist or may describe the agent rather than the customer.
The protocols are attempting to solve this by adding signed intent data and agent identity to the transaction record, but these capabilities are not yet fully deployed. Until they are, a dispute involving an agent purchase may arrive with much of the usual evidence missing.
One issuer has publicly committed to covering erroneous agent purchases on its network. Most have not. For now, assume that the default exposure remains with you.
What is worth doing now
Do not rebuild your payment stack. Agent-driven volume remains small for most merchants, and committing heavily during a protocol contest is an easy way to waste budget. Four actions are relatively inexpensive and sensible.
First, decide whether you want to accept agent traffic and state your position clearly. Your terms and conditions were written for a human buyer. If an agent can transact on your site, those terms should address it explicitly. This is primarily a legal review, not a technology project.
Second, make sure your fraud rules can distinguish agent traffic rather than automatically blocking it. Networks are developing registration and verification programs that let legitimate agents identify themselves. A merchant whose rules decline everything unfamiliar will also decline legitimate agent traffic.
Third, ask your PSP and acquirer which protocols they currently support, what is on their roadmap, and what evidence their platforms can provide when an agent-initiated transaction is disputed.
Finally, bring payments, fraud, and legal into the same conversation. Agentic commerce crosses all three functions, yet many organizations don’t share a common vocabulary.
Governing your own use of AI
If you use AI to make decisions about people, responsibility remains with you, not your vendor.
Under the European AI Act, systems used to assess an individual’s creditworthiness fall into the high-risk category. A carve-out generally covers systems used to detect financial fraud. Classification depends on the specific use case, so seek legal advice based on your own systems rather than relying on a general interpretation.
Two practical principles apply regardless of classification. You remain accountable for an automated decline, including one made by a model you have licensed, and you must be able to explain that decision when a customer or regulator asks. Model-driven decisions in onboarding or credit also require documented human oversight. “The system decided” is not a defense.
Questions to ask your provider
A provider that answers these precisely has probably done the work. A provider that responds with product language probably has not.
- What does your fraud model do to my approval rate when measured against my own traffic rather than a general benchmark?
- How are chargeback guarantees reflected in the dispute ratio my acquirer reports?
- Which agent protocols do you support today, and which are on your roadmap, with what expected dates?
- How can I evidence an agent-initiated transaction if it is disputed?
- What transaction data do you retain, and can I take that data with me?
How PPS approaches it
We separate the two conversations. The operational conversation gets a business case built around your numbers. Approval rates, dispute costs, and onboarding times are measurable, and you can discuss and negotiate all three with your provider.
The agentic conversation gets a readiness plan, not a major build. That means reviewing your terms, designing appropriate fraud rules, understanding your provider’s roadmap, preparing your API, and establishing an evidence approach before the protocols mature.
TrustBench applies the same principle to onboarding: structured, machine-readable documentation that can withstand automated underwriting, with human judgment retained where it belongs.
You work directly with our senior team, and we will tell you when the honest answer is to wait.