Agentic Payments: What Visa's Rules Say About AI Buyers

Agentic payments are card transactions an AI agent completes for a customer. Visa wrote them into its rulebook effective 18 April 2026, and the framework is already live, not proposed.

If you sell online, an agent may already be buying from you. The Visa Core Rules and Visa Product and Service Rules (18 April 2026) now devote section 4.1.24 to it, with defined roles, consent requirements, and one liability rule that matters more to merchants than all the rest combined.

The One Rule Merchants Should Read First#

Section 4.1.24.10 is a single sentence:

"A Cardholder is responsible for any actions taken by an Agentic Payment Provider as part of an Agentic Transaction as if the Cardholder initiated the Transaction." (ID# 0031176)

That's the whole liability position. When someone's agent buys from you, the rules treat it as if the person bought it themselves. "My AI did it without asking me" is not, on its face, a defence that shifts the loss to you.

That's a better starting position than most merchants assume. It doesn't make you immune to disputes, and it doesn't override the normal fraud conditions, but the baseline is cardholder responsibility rather than merchant exposure.

Who's Who in an Agentic Transaction#

Visa defines two new roles, and neither is what you'd guess from the names.

An Agentic Payment Provider is the consumer-facing application. It's the agent the customer actually uses, and Visa defines it as an app that can "search, discover, and purchase products and services" after receiving both a payment instruction and cardholder verification.

An Agentic Payment Enabler is the plumbing behind it. It connects the provider to Visa's network, and the rules are explicit that it "does not engage Cardholders directly nor submit Transactions on their behalf."

One detail worth noting: for the purposes of the Visa Rules, neither role is classified as an Agent in the third-party-agent sense (ID# 0025920). They sit in their own category with their own registration path, the Visa Intelligent Commerce program.

What the Agent Must Send You#

This is the part that affects your fraud screening directly.

When processing an agentic transaction, the provider must pass the cardholder's details through to the merchant, including the cardholder name, the billing and shipping address where goods are shipped, and the email address (section 4.1.24.4, ID# 0031170).

So an agentic order should not arrive looking anonymous. If you're receiving orders with missing or obviously synthetic customer details, that's not how a compliant agentic transaction is supposed to look, and your usual fraud screening judgement applies.

Consent Has to Happen Before Anything Is Bought#

The pre-transaction requirements are strict, and they sit on the provider rather than on you.

Before undertaking an agentic transaction, the provider must obtain cardholder consent both to provision a token from the payment credential and to use the customer's payment instruction for searching and purchasing. It must clearly state when that payment instruction expires. It must obtain the cardholder's acknowledgement that they are responsible for the actions the provider takes. And it must verify the cardholder's identity before storing a credential and again before acting on a purchase instruction (section 4.1.24.3, ID# 0031169).

Where a credential gets stored for future use, the same disclosure list from the stored credential rules applies: last four digits, how the credential will be used, how changes are notified, expiry, and the length of any trial or promotional period.

Your Refund and Cancellation Policy Now Gets Read by a Machine#

Section 4.1.24.6 is the one most merchants haven't considered.

Before completing a transaction, the provider must obtain cardholder consent or acknowledgement covering a limited cancellation, exchange, or refund policy, including the date cancellation privileges expire on an advance payment, and the cancellation deadline on a guaranteed reservation. The same applies to delayed charges, amended amounts, and estimated authorizations where the final amount isn't known yet.

It also covers upsells. If you offer goods from an unaffiliated third party during checkout, or anything requiring the customer to expressly decline participation in future transactions, the provider has to surface that and get consent.

The practical consequence: your policy text is now an input to an automated purchasing decision. Ambiguous or buried cancellation terms don't just annoy customers, they can stop an agent completing the sale, or produce a purchase the customer later says they didn't agree to.

Worth reading your own refund and cancellation copy with that in mind.

Where Agents Are Not Allowed#

Several hard prohibitions sit on providers:

• No agentic transactions in a card-present environment. This is a card-absent framework only.
• No aggregating multiple agentic transactions into a single transaction.
• No agentic transaction at a Visa-accepting merchant unless the cardholder has selected a Visa payment credential to complete it.
• No steering customers to an alternative payment method in a way that denies consumer choice.
• Services must be offered and rendered uniformly to all cardholders.

Providers must also be PCI DSS compliant, and Visa reserves the right to disqualify a provider from the program at its sole discretion.

Repeat Purchases Need Their Own Consent#

If an agent is going to buy again on a schedule, section 4.1.24.9 requires separate consent to repeated transactions and an acknowledgement that the provider will keep initiating them until the customer changes or cancels the payment instruction, or the instruction expires.

That's the agentic equivalent of subscription consent, and it means a recurring agentic arrangement should have a defined end rather than running indefinitely by default.

One Small Change to Dispute Evidence#

Visa's compelling evidence requirements now explicitly recognise agent logins. The list of identifiers you can match between disputed and undisputed transactions includes the "customer account or login ID used to authenticate the Cardholder at the time of the Transaction," and the rules now add that this "includes login IDs for an Agentic Payment Provider and Merchant's e-commerce site or application."

The same constraint as always applies: it must be in clear text and not hashed, and it must be a value the cardholder recognises. If you hash account identifiers before storing them, they're useless as dispute evidence, agentic or otherwise.