AI-Agent Commerce and the Chargeback Question: What Merchants Actually Need to Solve

Agentic commerce has moved from speculative to operational in the last twelve months. Visa's Intelligent Commerce Connect and Mastercard's Agent Pay both treat agent-initiated traffic as first-class — supporting MPP (Multi-Party Protocol), ACP (Agent Commerce Protocol), UCP (Universal Commerce Protocol), and the Trusted Agent framework as recognized authentication surfaces. The protocols solve a real problem: giving a network- blessed envelope to transactions that don't fit cleanly into card-not-present rules built for human cardholders.

What the protocols don't solve — and where merchants underestimate the work — is the dispute. The authentication question has answers. The liability question, the representment question, the consent-evidence question, the friendly-fraud question: these are still open, and they're the questions that actually affect a merchant's P&L when the volume starts mattering.

1. The protocol layer in plain terms

Each of the major agentic-commerce protocols is solving a slightly different problem:

• MPP (Multi-Party Protocol)standardizes how an agent, a cardholder, and a merchant exchange consent and authentication evidence inside a single transaction flow. It's the most widely-supported pattern across the major agent runtimes.
• ACP (Agent Commerce Protocol) focuses on the catalog and offer side — how merchants expose products and inventory to agents in a structured, machine-readable way that supports comparison and negotiation.
• UCP (Universal Commerce Protocol) is the cross-network superset attempting to unify these flows regardless of which card network sits behind them.
• Trusted Agentis Visa's framework for attesting that a given agent runtime meets the network's security and consent standards — effectively a network-level vetting layer for which agents can initiate Visa transactions.

For most merchants the practical question is which protocols their gateway or PSP will support, in what order, and with what evidence guarantees. The protocols themselves are converging rapidly enough that the long-term answer probably looks similar regardless of which surface you start with — but the short-term reality is messy.

2. Where authentication ends and the dispute starts

The protocols all do roughly the same thing on the authentication side: they capture cardholder consent before the agent initiates the purchase, they propagate that consent through the authorization request, and they let the issuer treat the transaction as one with a stronger consent signal than a typical card-not-present authorization.

Where the answers stop is when the cardholder later disputes the transaction. The dispute mechanics weren't designed for agent-initiated flows, and the existing reason-code catalog doesn't carve out clean handling for them. A cardholder who claims "I didn't authorize this" on an agent-initiated transaction is making a claim about the consent flow itself — and the existing dispute system doesn't have a great way to evaluate that claim.

3. The friendly-fraud vector merchants are missing

One under-discussed risk: agentic commerce makes friendly fraud easier, not harder. A cardholder can plausibly claim they didn't intend a purchase that an agent initiated on their behalf — even if they did, in fact, authorize the agent broadly. The mental model of "I told my agent to find me flights, but I didn't mean book *that* one" is a legitimate customer experience and an obvious dispute lever.

Existing friendly-fraud detection signals (device fingerprint, IP, behavioral history) all weaken when an agent runtime is the one transacting. The cardholder's device may not be involved at all. The IP belongs to the agent provider. The behavioral history is the agent's, not the cardholder's.

4. What good consent capture looks like

The protocols all require consent capture; the merchants who will fare best in disputes are the ones whose consent capture produces durable, replayable evidence. A defensible consent record probably includes:

• The cardholder identity at the agent layer (whatever the agent runtime uses to identify the user).
• The specific authorization scope — what the cardholder told the agent it could buy, with what limits, on what timeline.
• A timestamped record of the cardholder's confirmation of the specific purchase, where the protocol supports it, or of the broader scope authorization where it doesn't.
• The agent runtime's identity and Trusted Agent status at the moment of transaction.
• The transaction details as presented to and confirmed by the cardholder (where applicable).

Most of this data exists; the question is whether the merchant can retrieve it from the agent platform and reproduce it as evidence in a representment 90 days later. The contractual / data-portability layer here is where merchants should be pushing the agent platforms hard.

5. The representment problem

Existing representment evidence templates assume a human cardholder, a device they own, an IP they routinely use, and a card-not-present transaction with familiar fingerprints. Agent-initiated transactions match almost none of those assumptions, and a chargeback representment that simply substitutes the agent's data for the cardholder's is unlikely to land favorably with most issuers.

The path forward is probably purpose-built representment templates for agent-initiated traffic — citing the consent capture, the agent runtime's Trusted Agent attestation, and the specific protocol used. Whether issuers accept those templates is the open question, and the answer will play out over the next 12–18 months as the first wave of agentic chargebacks works through the dispute system.

6. What merchants should be doing now

• Inventory which agentic flows your gateway supports. You may already be receiving agent-initiated traffic without having explicitly opted into it.
• Review your agent-platform contractsfor consent-data portability. If you can't retrieve the consent record in a representment, you can't use it.
• Tag agent-initiated transactions in your data warehouse so you can monitor dispute and chargeback rates separately from human-initiated traffic. The economics are likely to diverge meaningfully.
• Engage with your fraud vendor on agent- aware signals. The category is too new for most vendor models to handle well off the shelf.
• Pilot before scaling. The merchants who win here will be the ones who built operational muscle in low-volume agent traffic before it became a meaningful share of the portfolio.

How Superior Payments helps

Superior tags agent-initiated transactions automatically in our gateway and routes them to a separate dispute-handling pipeline with representment templates built for the agent context. For merchants who haven't yet enabled agentic flows, our team can scope a controlled pilot that gives you the data to make the rollout decision without exposing the full portfolio to unknown dispute economics.