Agentic Payments and Chargebacks: A Merchant Guide

Agentic payments create chargebacks under existing reason codes, while the still-unsolved merchant need is evidence of the customer's mandate to the agent.

Agentic payments are purchases an AI agent initiates, authorizes, or completes on a person's behalf. Manual approval at checkout is reduced or gone. A disputed agent purchase files under the same reason codes you already fight today, usually fraud or "I didn't authorize this."

I've spent time digging through merchants' processor setups in a support role. Every new payment method follows the same pattern.

The dispute arrives well before the industry agrees on a framework. So the work is work you already know how to do.

Key takeaways

  1. 01Agentic payments are transactions an AI agent completes for a person.
  2. 02Disputed agent purchases file under the reason codes you already fight.
  3. 03Expect Visa 10.4 fraud first, then 13.1 and 13.3.
  4. 04Fraud/card-absent is 11.1% of coded alerts in our dataset.
  5. 05Alerts match on the transaction and reason code, reaching 95% of Mastercard volume.
  6. 06Mandate evidence is the real gap, and no tool captures it yet.

Not sure your current coverage reaches these disputes? See which alerts you're missing.

What are agentic payments?

Agentic payments are transactions an AI agent initiates, authorizes, or completes on a person's or business's behalf, with reduced or no manual approval at checkout. The person sets the goal, and software does the buying.

The transaction runs the same path every card payment uses. Your processor gets an authorization request, the issuer approves or declines, and the money settles on schedule. The agent decides and clicks buy, acting on what the person asked for.

The order can look completely ordinary to you. A real card and a real billing address, so your fraud rules read a normal card-not-present sale.

Some agents pay through a temporary virtual card number instead. That changes the number you see and leaves the dispute process the same.

Run these orders through the card-not-present checks you already have. That means your AVS match, your CVV requirement, and your velocity rules. An agent order carries the same signals as any other card-not-present sale, so your thresholds can stay put.

People use the term loosely. That matters when you're working out how much of it applies to you.

The line is whether the agent itself submits or approves the charge. An agent that only recommends a product stays on the far side of that line, because it hands the customer to a normal checkout.

Agentic payments vs. agentic commerce

Agentic commerce covers an AI agent handling any part of the shopping journey, while agentic payments is the narrower case where the agent pays. Search, comparison, and negotiation are agentic commerce. Paying is an agentic payment.

Your exposure starts the moment an agent approves a charge. A dispute can only follow from the payment step. Each stage of the journey sits on one side of that line:

What the agent doesWhich term appliesYour dispute exposure
Searches, compares, negotiatesAgentic commerceUnchanged
Fills a cart, hands off to a human checkoutAgentic commerceUnchanged
Submits or approves the chargeAgentic paymentA dispute becomes possible

Accenture found that 78% of financial payments leaders expect fraud to rise sharply as agentic payments spread. Their concern is the authorization step, which is the only step that can produce a dispute.

Expect the looser usage everywhere else you read. Check whether a vendor page says which of the two it means. Plenty promise agentic payments and only cover agent-assisted shopping.

So when you read a vendor claim about agentic risk, ask whether the product touches the authorization step. Only that step changes your disputes.

The tools that already work there are the alert networks, and how the three mechanisms differ is the comparison worth your time.

How does an agentic payment actually work?

A person sets the limits up front, then the agent buys and authorizes inside them with no human at checkout. Four steps, in order:

  1. The person sets a mandate: They state what they want and the limits that bind the agent.
  2. The agent decides: It picks what to buy and when, within those limits.
  3. The agent authorizes: It submits the transaction without a human at checkout.
  4. The transaction settles: Money moves through the usual authorization and settlement process.

The mandate is the control that matters to you. It records approved merchants, spending limits, and when the agent can transact. ACI Worldwide's guide describes a mandate as setting the rules, intent, and constraints the agent works within.

The open question is how the agent proves it held one.

Protocols and standards behind agent authorization

Google's Agent Payments Protocol (AP2) and Mastercard's Agent Pay are competing to become the standard for proving an agent was authorized. Agent-payment support is live in selected integrations. Availability and the authorization evidence you receive depend on your provider.

They are solving the same problem, which is proof. An issuer or a merchant has to answer two questions about every agent purchase.

Did the agent hold real permission, and did the purchase stay inside its limits?

Most designs sign the mandate so it travels with the transaction. Treat the protocol names as a sign that authorization standards are still being written.

A signed mandate would arrive as an extra field on the authorization request. Your processor would pass it to you the way it passes any other field. Your order record would keep a copy, and a dispute response could point to that copy later.

You get somewhere to keep it once the networks publish the field and your processor supports it. So ask your account manager what agent-authorization data they plan to expose. Ask whether it will appear in your existing order payload.

A standard only changes your work once your own provider supports it.

Watch your processor's release notes and API changelog. That support shows up there months before any protocol announcement affects you.

What happens when a cardholder disputes an agentic payment?

A disputed agent purchase files under a reason code you already work with, most often Visa 10.4, 13.1, or 13.3. Nothing in the dispute system labels a transaction as agent-made.

Which code applies depends on what the cardholder says went wrong. "I never authorized my agent to buy this" reads as unauthorized use, so it gets the fraud code. An agent purchase that never showed up is a not-received claim. An agent that bought the wrong thing is a not-as-described claim.

Each claim maps to one code:

Reason codeWhat the cardholder claimsWhen it applies to an agent purchase
10.4 Other fraud, card-absentUnauthorized transactions in online or phone purchasesThe cardholder says they never authorized the agent to make this purchase, or the agent itself was compromised
13.1 Merchandise or services not receivedCustomers say they didn't get what they boughtThe agent completed a purchase that never arrived or was never fulfilled
13.3 Not as described or defectiveGoods or services don't match description or are faultyThe agent bought the wrong item, or one whose listing didn't match what shipped

Plan around the fraud code first. In our dataset, fraud/card-absent (10.4) leads every other specific code at 11.1% of coded alerts. Cancelled-recurring (13.2) is 8.5% and cancelled-merchandise (13.7) is 8.2%.

 
Share of alerts with a recorded reason code
 
10.4 Fraud, card-absent
11.1%
 
13.2 Cancelled recurring
8.5%
 
13.7 Cancelled merchandise
8.2%
 
Fraud, card-absent is the largest specific code in our own alert data. An agent-initiated fraud dispute would carry the same code.

An agent fraud dispute gets the same code. So you can look up a reason code and build the packet you'd build for any 10.4.

An agent may end up managing your renewals, and cancelling them. If you bill on a subscription, start from our subscription chargeback prevention guide.

One thing does change, which is what the cardholder can honestly say. They can truthfully tell their bank they don't recognize the charge while their own agent placed the order. Both halves hold.

A card network could add an agent-specific code as adoption grows.

Summary: An agent-initiated dispute lands on an existing reason code, most often Visa's card-absent fraud code.

Can today's chargeback alerts catch an agentic dispute?

Ethoca and Verifi's alerts reach an agent dispute the same way they reach any other, provided you're enrolled and your descriptor is readable. The alert matches on the transaction and its reason code. None of these networks ask who clicked buy.

An agent purchase runs the same alert flow. Our guide to how chargeback alerts work covers that flow end to end, and the two resolution modes split the same way for agent traffic as for anyone else.

RDR's automated resolution fires against rules you set in advance, so no agent dispute waits on you to act.

Ethoca and CDRN's manual review window hand you the alert instead, so you make the call yourself.

Your descriptor is where merchants lose alerts they paid for. Pull yours up in your processor's settings and read it as a customer would, then set it to your trading name plus a support number. If the customer can't tell who charged them, the alert won't match cleanly.

Coverage depends on card brand and enrollment, so check what each product actually reaches:

ProductCompanyCovers
RDR and Order InsightVerifi (Visa)Visa transactions only
CDRNVerifi (Visa)US transactions only
Ethoca alertsMastercardAbout 95% of Mastercard transactions

American Express, Discover, and JCB get far less, whoever made the purchase.

So pull your last 90 days of transactions by card brand from your processor's reporting. Then list which of those brands your enrollment covers. Any brand with real volume and no enrollment is an uncovered gap. We sell alerts on both Ethoca and Verifi if yours turns out to be one-sided.

Summary: Alerts already reach agent-initiated disputes, as long as you're enrolled on the right network and your descriptor matches.

What can't today's tools catch yet?

Today's tools can't capture the mandate that proves an agent stayed inside the customer's limits. That mandate is what an agent dispute comes down to.

ACI Worldwide's guide is direct about the gap. It calls mandate-based authorization "currently untested in courts and before regulators".

The same guide names three things you need to fight an agent chargeback. Who holds each one decides whether you can get it:

Evidence you needWho holds itDo you get it today
The mandate that authorized the agentThe customer's agent platformNo
The identity of the agent that ran the transactionThe agent platformNo
A tamper-resistant record tying the twoNobody yetNo

An alert match flags the dispute and lets you refund before the issuer files a chargeback. It captures none of those three items, so whether the customer approved the purchase stays an open question.

A normal 10.4 packet leans on transaction history and a matching address. An agent 10.4 comes down to permission the customer gave software. Your shipping proof says nothing about that.

So refund every agent-related alert you can't match to a fulfilled order. Do it inside the alert's response window. A refund costs you the sale, and a chargeback costs the sale plus the fee.

Record a non-secret integration or key identifier, the agent identifier, and relevant authorization evidence. Never store the secret API key in an order record.

Once the networks publish the mandate field, your order record will have somewhere to keep it.

How we sourced our data

The reason-code figures here come from anonymized, pooled alert data across merchants on the Chargeback.io platform. We count total alerts in each category, then report them as shares of the coded alerts. The population is the alerts our own platform processed. So these numbers are a read on our merchant base rather than the payments industry.

FAQ

Is an AI agent buying on my store fraud?

No, an agent purchase a customer authorized is a legitimate sale. It turns into a fraud claim only if the cardholder later says they never allowed it.

What are the 4 major payment processors?

Stripe, PayPal, Square, and Adyen are the four most commonly named. Merchants also process through Shopify Payments, Braintree, and Worldpay depending on platform and region.

Do I need to change my refund policy for agentic purchases?

Software has to be able to read the refund terms you already have. Publish them in plain text on a stable URL, so an agent can find your window before it buys.

What does agentic mean?

Agentic describes software that acts on its own toward a goal you set, once you set it. In payments the agent decides and transacts within limits you defined up front.

Verlaag vandaag nog uw geschillenpercentage

Sluit je aan bij meer dan 800 bedrijven die Chargeback gebruiken om terugboekingen automatisch te voorkomen — de installatie duurt minder dan 2 minuten.