Agentic Payments: What the Card Rules Now Say About AI Buyers

Visa’s card rules now name the AI shopping agent directly, call it an Agentic Payment Provider, and put the cardholder on the hook for what it buys, almost without exception. That is not a prediction about where card network rules are heading. It is Section 4.1.24 of the current Visa Core Rules and Visa Product and Service Rules, effective language already on the books.

An Agentic Transaction, in Visa’s own definition, is an electronic commerce transaction an Agentic Payment Provider undertakes on a cardholder’s behalf, using a payment credential, based on the cardholder’s own payment instruction, completed without direct interaction between the cardholder and the merchant at the moment of purchase. An Agentic Payment Provider itself is defined just as specifically: an application that can search, discover, and purchase products after receiving both a cardholder’s payment instruction and cardholder verification, that can operate across more than one merchant, that stores and transmits a token rather than raw card data, and that is explicitly not treated as a merchant for purposes of Visa’s own rules.

Registration comes before a single transaction

An Agentic Payment Provider cannot simply start initiating card transactions on a cardholder’s behalf. Section 4.1.24.2 requires it to enroll in and comply with the Visa Intelligent Commerce program and register with Visa, either directly or through an Agentic Payment Enabler, before it can process anything. A separate role, the Agentic Payment Enabler, connects an Agentic Payment Provider to Visa’s network without engaging cardholders directly or submitting transactions on their behalf itself. An enabler has to contract with every provider it works with, requiring the provider to comply with Visa’s rules and applicable law, and reserving the enabler’s right to terminate that provider immediately for fraud or good cause.

This two-tier structure matters for anyone building or buying into an agentic checkout flow. A platform that wants to let an AI agent complete purchases on its site is not dealing with an informal integration. It is dealing with a registered role in Visa’s network, carrying its own compliance obligations and its own disqualification risk if those obligations slip.

What has to happen before the agent buys anything

Section 4.1.24.3 sets out pre-transaction requirements that read like informed consent for a human proxy, not a software feature flag. Before undertaking an agentic transaction, the provider has to obtain the cardholder’s consent to both store the payment credential as a token and act on the cardholder-defined payment instruction, clearly state when that instruction expires, and obtain the cardholder’s acknowledgement that they are responsible for the provider’s actions. Identity verification has to happen before the credential is stored and again before the provider acts on the instruction to search and purchase.

If the provider stores the credential for future use, the disclosure requirements go further still: the cardholder has to see the last four digits of the account that will be charged, how they will be notified of changes to the arrangement, how the stored credential will actually be used, when the agreement expires if it does, and the length of any trial or promotional period. None of this is boilerplate buried in a terms-of-service link. Visa requires it displayed separately from general purchase terms, at the moment the cardholder actually gives consent.

The specificity is the point. “The cardholder authorized the agent to shop for them” is not what the rule requires. “The cardholder authorized this agent to act on this defined instruction, understanding these specific terms” is. That distinction is exactly where liability gets decided later.

The cardholder is responsible, almost without exception

Section 4.1.24.10 states the allocation of responsibility in one 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.” Read on its own, that looks like Visa simply assigning all the risk to the consumer the moment they turn on an AI shopping agent.

It is more precise than that, and the precision matters for anyone building these flows. The rule is not creating a new liability standard out of nothing. It is consistent with how federal law already treats an authorized agent. Regulation E’s own definition of an unauthorized electronic fund transfer specifically excludes a transfer initiated by a person the consumer furnished an access device to, unless that person later exceeds the authority actually given, and the official interpretation makes this explicit: a consumer who grants transfer authority to another person, such as a family member or coworker, is fully liable for that person’s transfers unless the consumer has notified the financial institution that the authority is revoked. Visa’s agentic transaction rule applies the same logic to a non-human agent. The cardholder authorized this provider to act on this instruction, so a transaction executed within that instruction is the cardholder’s transaction.

The boundary is the entire question. Regulation E’s liability allocation holds only while the agent stays within the authority actually granted. A transaction outside the cardholder-defined instruction, if it ever occurred, would not automatically inherit that same protection, which is exactly why Visa’s rule puts so much emphasis on the instruction being specific, time-bound, and disclosed before the provider acts, rather than a general “handle my shopping” grant with no real boundary to test a transaction against later.

What the provider has to produce after the purchase

Visa does not stop at the moment of purchase. Section 4.1.24.8 requires an Agentic Payment Provider to make an order confirmation available to the cardholder for at least 120 days after the transaction, covering the goods or services ordered, the merchant’s contact details, the total price, the currency, and any applicable cancellation or refund terms. For a recurring arrangement, Section 4.1.24.9 adds a separate requirement: the provider has to obtain the cardholder’s acknowledgement that it will keep initiating future transactions until the cardholder changes or cancels the instruction, and confirm that understanding again in the post-transaction order confirmation.

This 120-day window is not an arbitrary customer-service nicety. It is close to the kind of evidentiary record a dispute actually needs, and it puts the burden of producing it on the provider by rule, not on the merchant or the card network reconstructing it after a chargeback lands. A provider that cannot produce that record on demand is already out of compliance with the rule that lets it operate in the first place.

Settlement treats these transactions as ordinary ones, with one exception

Clearing and settlement rules confirm that an agentic transaction is processed like any other once it reaches the network: an acquirer enters the original presentment in the exact transaction currency authorized by the cardholder or an agentic payment provider on the cardholder’s behalf, and an issuer must pay the acquirer the amount due for a transaction that an agentic payment provider processed in accordance with the cardholder’s payment instructions. The one meaningful constraint sits earlier in the chain. An agentic payment provider is barred from aggregating multiple agentic transactions into a single transaction, from operating in a card-present environment, and from steering a cardholder away from their chosen payment method in a way that denies consumer choice.

Where a digital wallet sits in the chain, and what Visa can do to a provider that breaks the rules

An agentic transaction rarely runs through an Agentic Payment Provider in isolation. Section 4.1.24.5 gives a separate set of requirements to a Digital Wallet Operator or a Pass-Through Digital Wallet operator that facilitates one: it has to verify the cardholder through a Visa-approved consumer device cardholder verification method at the moment the cardholder is shown the agent’s proposed payment instructions, confirm that instruction and all payment data is transmitted to Visa once the cardholder approves it, pass that confirmation to the Agentic Payment Provider, and submit the resulting token to the provider or merchant to actually complete the purchase. That is a fourth distinct role, alongside the Agentic Payment Enabler, the Agentic Payment Provider, and the merchant itself, each carrying its own obligations under the same transaction.

The practical effect is that a single agentic purchase can involve four separately regulated parties under Visa’s rules before the card network and issuer even see it: the wallet that captured the cardholder’s device-level approval, the enabler that connects the provider to Visa’s network, the provider that actually executed the purchase, and the merchant that fulfilled it. A platform evaluating where to sit in that chain needs to know which role it is actually taking on, because the registration, consent, and disclosure obligations differ by role, not by what the product is called in its own marketing.

Visa also reserves a blunt enforcement tool specific to this framework. Section 4.1.24.11 states plainly that Visa may, at its sole discretion, disqualify an Agentic Payment Provider from participating in the Visa program. There is no cure period built into the rule text itself, and no enumerated list of qualifying violations required before Visa can act. For a platform whose checkout flow depends on a third-party Agentic Payment Provider staying in good standing with Visa, that discretion is a counterparty risk worth underwriting explicitly, not an abstract compliance footnote. A provider disqualified from the Visa program stops being able to process Visa transactions at all, which for a platform built around that single provider is an operational outage, not a compliance fine.

What this actually means for a platform building or buying into this

A platform that wants an AI agent completing checkout on its behalf, or a payments business evaluating whether to become or integrate an Agentic Payment Enabler, is not looking at a feature decision. It is looking at a registration obligation, a consent and disclosure requirement that has to be built into the product itself rather than bolted on as a legal disclaimer, and a 120-day recordkeeping obligation that has real operational cost if nobody designs for it upfront.

The consent flow is the part most likely to get built wrong under time pressure. A product team’s instinct is to capture one broad authorization at signup and treat that as covering everything the agent does afterward. Visa’s rule does not support that reading, and neither does the Regulation E logic it mirrors. The instruction has to be specific enough that a transaction can be checked against it later, which means the product has to capture and retain the actual scope of what the cardholder authorized, not just the fact that they clicked agree once.

For a platform already thinking through how embedded payments fit into its product, agentic checkout is the newest version of a decision that recurs throughout that work: whether to build directly to the network’s own rules or integrate a partner who has already done so. Evaluating an Agentic Payment Enabler or Provider as a vendor belongs in the same diligence process as any other payments vendor and partner selection decision, with the registration status, the consent flow, and the 120-day record retention checked directly rather than taken on a vendor’s word. And because an agent acting outside its granted instruction is exactly the scenario a future dispute will turn on, the underlying fraud and chargeback prevention posture needs to treat agentic transaction records as a first-class category of evidence, not an afterthought bolted onto a fraud model built before agents existed. The data discipline this requires sits next to Compelling Evidence 3.0, which itself extends to agentic payment provider login IDs as a named element Visa’s own dispute rules now recognize directly.

Frequently Asked Questions

What is an Agentic Payment Provider under Visa’s rules?

Visa Core Rules defines an Agentic Payment Provider as a provider of an application a cardholder uses to search, discover, and purchase products on their behalf, after receiving the cardholder’s payment instruction and verifying the cardholder’s identity. It can be used at more than one merchant, stores and transmits a token rather than raw card data, and is explicitly not treated as a merchant under Visa’s rules.

Is the cardholder liable if an AI shopping agent makes a purchase they did not want?

Under Visa Core Rules Section 4.1.24.10, the cardholder is responsible for any action the Agentic Payment Provider takes as part of an agentic transaction, as if the cardholder initiated it directly. That tracks Regulation E’s existing rule that a consumer who furnishes an access device to someone and grants transfer authority is fully liable for that person’s transfers unless the authority is later revoked, which puts real weight on how precisely the cardholder’s payment instruction was captured and scoped in the first place.

How long does an agentic payment provider have to keep order records available to the cardholder?

Visa Core Rules Section 4.1.24.8 requires an Agentic Payment Provider to make an order confirmation available to the cardholder for at least 120 days from the processing date, including the merchant’s contact details, the total price, the transaction currency, and any cancellation or refund terms.

Sources: Visa Core Rules and Visa Product and Service Rules, Section 4.1.24, and CFPB Regulation E, Section 1005.2, Definitions and Section 1005.6, Liability of Consumer for Unauthorized Transfers.