Agentic Commerce: What Happens to Authorization, Disputes, and Liability When an AI Assistant Checks Out for a Customer

Traditional ecommerce assumes the customer is actively looking at the checkout page, selecting a payment method, reviewing the total, and pressing the final purchase button. Agentic commerce changes that assumption. 

An AI assistant may search products, compare merchants, choose an option, prepare checkout, and—where the technology, payment method, permissions, and merchant support allow it—complete a purchase within limits previously established by the customer.

That creates a deceptively simple question: If the customer did not personally press “Buy,” what proves that the transaction was actually authorized?

The answer cannot be reduced to a successful card authorization or a login session. In agentic commerce, merchants and payment providers need to separate several events that conventional checkout often bundles together:

Customer Intent → Agent Permission → Product/Price Constraints → Merchant Checkout → Payment Credential Selection → Authentication → Authorization → Order Confirmation → Fulfillment → Transaction Evidence → Possible Refund/Dispute → Liability Analysis

The most important distinction is this:

Customer Authorization of the AI Agent ≠ Issuer Authorization of the Card Transaction ≠ Authentication of the Customer

A bank can approve a payment without knowing whether an AI purchasing agent selected exactly what the customer wanted. A customer may successfully authenticate but still dispute that an agent exceeded its instructions. 

And a merchant may receive a technically valid payment credential while still deciding that an order violates fraud controls, inventory rules, shipping restrictions, or other merchant terms.

Agentic commerce is no longer purely theoretical. Visa has introduced Visa Intelligent Commerce and publishes a Trusted Agent Protocol, while Mastercard offers Agent Pay capabilities designed around verified agents, tokenized credentials, consent, and transaction intent. 

At the same time, significant parts of the ecosystem remain under development, deployment, pilot testing, standardization, or market-by-market rollout. Visa itself notes that some Intelligent Commerce functionality remains in the process of deployment.

There is therefore no universal legal or card-network framework called “agentic commerce liability.” Responsibility for an AI checkout dispute may depend on the payment rail, card type, credential, authentication method, consumer authorization, merchant agreement, network rules, platform terms, applicable consumer law, agent permissions, and facts of the individual purchase.

This guide explains how merchants can prepare without treating emerging protocols as settled law.

What Is Agentic Commerce?

Agentic commerce is a form of digital commerce in which software agents perform some or all shopping tasks on behalf of a person or organization. Instead of simply answering “Which laptop should I buy?”, an AI shopping agent may search available products, compare specifications, evaluate price and delivery constraints, create a cart, and potentially initiate or complete payment under permissions established by the user.

Visa describes agentic commerce and Visa Intelligent Commerce as commerce in which AI agents can help consumers or businesses discover products, make decisions, initiate checkout, and complete transactions with user permission and appropriate controls.

The degree of autonomy matters. “AI commerce” can describe everything from a recommendation tool to a highly autonomous AI purchasing agent, but those models carry very different payment and dispute implications.

A recommendation assistant may suggest three products while leaving the customer to visit the merchant and complete checkout. A cart-building assistant might select products and shipping but require the customer to approve the final order. 

A delegated purchase system may allow the agent to complete transactions under a spending limit. None of these models should be assumed to have identical customer authorization or AI payment authentication requirements.

Visa describes agentic commerce as experiences in which agents can help consumers discover products, make decisions, initiate checkout, or complete transactions with user permission. 

Mastercard similarly notes that fully autonomous consumer agents are still emerging even as AI-assisted shopping and AI-initiated payment capabilities move into real implementations.

For additional background on how machine learning is already used in payment decisioning, fraud analysis, and transaction operations, see this overview of AI and machine learning in payment processing.

AI-Assisted Shopping vs. Autonomous Checkout

The merchant should identify where the human leaves the transaction flow, because that point affects consent evidence, authentication, customer communications, and dispute risk.

Model	AI Role	Customer’s Final Action	Payment Risk
Recommendation	Finds and compares products	Customer chooses and checks out	Similar to conventional ecommerce
Cart preparation	Builds cart and may select delivery	Customer reviews final order	Moderate risk of product or pricing mismatch
Assisted checkout	Completes most checkout fields	Customer confirms payment	Authentication and evidence remain important
Delegated purchase	Buys within a defined mandate	Customer may not approve each purchase	Requires strong permission and evidence controls
Autonomous purchase within limits	Selects and purchases under standing rules	No real-time human action required	Higher mandate, account-takeover, retry, and dispute complexity

An AI assistant should therefore not be treated as “authorized” merely because it has technical access to a checkout API or payment credential. Technical capability answers what the software can do. Customer authority answers what the software is permitted to do.

What Does “Authorization” Mean in Agentic Commerce?

Authorization is one of the most overloaded words in payments. Agentic commerce makes precise terminology more important because different parties can authorize different actions at different times.

A useful implementation should distinguish customer intent, agent authority, payment authentication, payment authorization, transaction approval, merchant acceptance, credential delegation, tokenization, fulfillment authorization, and later dispute rights. Treating all of those as “the transaction was authorized” can produce weak controls and poor dispute evidence.

Customer-to-Agent Authorization

Customer-to-agent authorization asks whether the customer gave the AI assistant authority to act. That authority might be narrow—“Buy this exact replacement filter for no more than $35”—or broad—“Restock approved household supplies up to $150 per month.”

Evidence could include an explicit opt-in, authenticated account session, spending ceiling, product or merchant restrictions, expiry time, delivery-address restrictions, confirmation requirements, and the status of any later revocation.

No individual field automatically establishes legal authorization in every jurisdiction or dispute. The purpose is to build a reliable record showing what the customer intended and what authority the agent possessed at the relevant moment.

For U.S. credit cards, Regulation Z defines unauthorized use by reference to whether someone other than the cardholder lacked actual, implied, or apparent authority, with questions about the existence of authority potentially depending on applicable law. That illustrates why the facts surrounding delegated authority can matter substantially.

Payment Authentication and Issuer Authorization

Payment authentication asks whether the person or credential being used can be validated through the relevant payment-security mechanism. In ecommerce, that could involve account authentication, passkeys, issuer authentication, or EMV 3-D Secure.

Issuer authorization is different. An authorization request asks the issuer or other decisioning entity whether the payment transaction should be approved based on the account, credential, available credit or funds, risk controls, network information, and other factors.

An approval code therefore does not prove that the customer instructed an AI assistant to purchase those exact shoes, from that exact merchant, for that exact amount.

EMVCo describes EMV 3DS as a mechanism that enables merchants and issuers to exchange transaction, payment-method, and device information so issuers can authenticate consumers in card-not-present commerce. 

That authentication function should not be expanded into a universal statement that the shopper approved every commercial detail of an AI-generated order.

Merchant Acceptance

A merchant makes another independent decision. Even with valid agent credentials, successful authentication, and issuer authorization, the merchant may reject or review an order because of inventory, shipping restrictions, suspicious velocity, product eligibility, restricted goods, merchant terms, or fraud concerns.

A practical authorization model is:

Valid Agent Context + Valid Payment Credential + Risk Screening + Authentication Where Needed + Merchant Rules + Final Payment Authorization

Approval at one layer should never silently substitute for approval at the others.

Proving Customer Intent: Agent Mandates, Limits, and Revocation

The hardest evidence question in agentic commerce may not be “Was the account real?” but rather “What exactly did the customer ask the agent to do?”

An effective permission model should create an auditable relationship between the customer’s instruction and the resulting order without unnecessarily retaining full conversations, sensitive personal information, or raw payment credentials.

Potential proof of customer authorization may include:

• explicit enrollment in agent purchasing;
• authenticated account identity;
• permitted merchants or merchant categories;
• product or service constraints;
• per-transaction and aggregate spending limits;
• quantity limits;
• required delivery addresses;
• start and expiration times;
• transaction-specific confirmation rules;
• timestamps for instruction, confirmation, and purchase;
• revocation status;
• a secure reference to the resulting order.

These controls are especially useful because proof that an account was authenticated is not necessarily proof of customer intent regarding the specific purchase.

Standing Permission vs. Transaction-Specific Approval

A standing permission might say, “Buy household supplies from approved merchants when inventory is low, with no single order above $75.”

A transaction-specific approval might say, “Purchase this 48-pack of detergent from Merchant X for $41.99 and deliver it to my home address.”

The standing model reduces checkout friction but increases the importance of well-defined constraints. The transaction-specific model produces stronger evidence connecting the customer to the exact merchant, item, and amount, but it reduces the autonomy that makes agentic ecommerce attractive.

A merchant does not necessarily need to possess every detail of the customer’s mandate. The ecosystem may instead use signed, tokenized, or platform-verified assertions showing that the proposed order falls within established permissions. 

The architecture should preserve enough trustworthy evidence for fraud review, support, and disputes without exposing more personal data than necessary.

Agent Mandates and Emerging Standards

An agent mandate is a useful conceptual way to represent delegated purchasing authority. It could contain:

• who granted authority;
• the agent or platform receiving it;
• what can be purchased;
• the maximum amount;
• permitted merchants or categories;
• validity period;
• confirmation requirements;
• shipping constraints;
• revocation state.

This is no longer merely an abstract industry idea, but implementations are not universal.

One current example is Visa’s Trusted Agent Protocol, which provides specifications for trusted communication between AI agents and merchants. 

The framework uses agent-specific cryptographic signatures and can communicate information relating to agent intent, consumer recognition, and payment context. It should be treated as a current Visa framework rather than a universal agentic-commerce standard applicable to every network or merchant.

Google’s Agent Payments Protocol, or AP2, is an open protocol designed for agent-performed payment transactions and defines linked checkout and payment mandates that can support transaction evidence. 

Google later announced that AP2 was being donated to the FIDO Alliance for further standards development, and AP2 documentation describes the protocol as part of an evolving agent-commerce ecosystem rather than a mandatory payments rule.

Visa’s Trusted Agent Protocol likewise describes cryptographically signed information that can help merchants identify trusted agents, consumer context, and payment information. Visa explicitly states that parts of the product are in development and deployment and may not be available everywhere.

These technologies should therefore be described as current frameworks and emerging standards efforts, not as universal legal requirements.

Revoking Agent Authority

A customer should have a practical way to revoke purchasing permission, stored payment access, category authority, merchant access, or recurring purchasing rules.

Revocation also needs a defined cutoff. If the customer revokes an agent at 2:00 p.m., but an order was validly committed at 1:59 p.m. and has already entered fulfillment, cancellation rights may depend on the merchant’s terms and applicable law rather than treating the completed transaction as automatically unauthorized.

Systems should record the mandate version, purchase time, revocation time, and order state so those events can later be reconstructed accurately.

Authentication, Credential Delegation, and Tokenization

Agentic commerce introduces several identities into checkout. The customer, AI agent, agent platform, merchant, and payment credential may each need separate verification.

Authenticating the customer does not authenticate the AI agent. Authenticating the AI agent does not authenticate the cardholder. Recognizing a trusted agent also does not prove that the agent’s chosen product satisfies the customer’s mandate unless the permission context is validated separately.

NIST’s current Digital Identity Guidelines distinguish authentication of an account holder from broader authorization decisions and emphasize phishing-resistant methods where appropriate for higher-assurance environments. 

Merchants do not need to impose one authentication technology on every AI purchase, but strong account protection becomes especially important when an account can delegate spending authority.

Customer, Agent, and Payment Authentication

Customer authentication may involve passwords, MFA, passkeys, device binding, biometrics implemented appropriately, or another approved identity mechanism.

Agent authentication asks whether the merchant or commerce platform can establish that the software agent is legitimate and recognized. Visa’s Trusted Agent Protocol, for example, uses signed agent information so participating merchants can distinguish an approved commerce agent from anonymous automated traffic. 

Mastercard Agent Pay similarly describes registered agents, tokenized credentials, and verified intent as elements of its agentic-payment model.

Payment authentication then operates through the payment rail. For card-not-present transactions, EMV 3DS may still be relevant, including frictionless or challenge flows depending on the issuer, transaction, geography, and implementation.

If issuer step-up authentication requires the customer to interact, autonomous checkout may temporarily become human-assisted. That is not a design failure; it can be an appropriate control when risk or policy requires additional assurance.

Tokenized and Scoped Payment Credentials

The safer architectural goal is generally:

Primary Credential → Token or Limited Credential → Agent → Merchant → Payment Network

Rather than handing an AI agent an unrestricted reusable card number, an issuer, wallet, network, or payment platform may provide a tokenized or constrained credential.

Mastercard is also developing this model through Mastercard Agent Pay, its infrastructure for agentic transactions. Mastercard describes the system around elements such as tokenized payment credentials, agent recognition, consumer control, and payment security. 

Availability and implementation details can differ across products, partners, and markets, so merchants should verify which capabilities are actually supported by their payment provider.

Potential controls can include:

• maximum transaction amount;
• permitted merchant or merchant category;
• expiration time;
• permitted transaction count;
• approved purchasing context;
• device or agent binding;
• one-time or limited-use behavior.

Visa Intelligent Commerce describes tokenized credentials that can be bound to agents and user-defined permissions, while Mastercard’s Agent Pay program uses its tokenization infrastructure as a foundation for agentic payments. The exact capabilities, enforcement points, and availability differ by provider and implementation.

Network tokens, merchant tokens, vault tokens, and purpose-built agent credentials should not be treated as interchangeable. 

A merchant token may simply reference a credential in a processor vault, while a network token can be managed within a payment network’s tokenization framework. An agent-specific credential may add context or restrictions relating to delegated use.

Tokenization improves credential security. It does not prove that the customer wanted a specific product.

Should an AI Agent Receive a Raw Card Number?

As a general security architecture, avoid exposing reusable raw card credentials to AI applications when tokenized or provider-hosted alternatives are available.

Giving a broadly capable model access to reusable payment credentials increases the consequences of account compromise, logging errors, prompt manipulation, excessive tool permissions, or third-party integration failures.

Merchants should also examine whether their AI checkout design expands PCI DSS scope. AI involvement does not remove PCI DSS obligations when cardholder data is stored, processed, or transmitted within systems subject to the standard.

For a merchant-focused overview, see these PCI compliance practices for payment environments.

The PCI Security Standards Council explicitly states that card verification codes such as CVV2, CVC2, CID, and similar values are Sensitive Authentication Data and must not be stored after authorization, even when encrypted.

How an AI Shopping Agent Should Move Through Checkout

A merchant does not need to redesign every payment primitive simply because an AI agent initiated the shopping journey. The safer strategy is to preserve familiar payment states while adding trustworthy context around the agent’s identity, mandate, and customer intent.

A conceptual workflow looks like this:

1. The customer establishes agent permissions.
2. The agent identifies products that satisfy those permissions.
3. The agent selects an eligible merchant.
4. The merchant receives the cart or order request.
5. Agent and customer context are validated where supported.
6. A tokenized or otherwise protected payment credential is supplied.
7. Customer/payment authentication occurs if required.
8. The merchant submits the authorization request.
9. The issuer or payment provider returns approval or decline.
10. The merchant generates an order confirmation.
11. Relevant transaction evidence is retained.
12. Fulfillment begins only after the merchant’s payment state is authoritative.

The customer remains the holder of the underlying payment account. An AI agent is not the cardholder simply because software initiated the purchase.

Card-Not-Present Risk, AVS, CVV, and 3-D Secure

Most ecommerce AI-agent transactions using ordinary online card rails will generally resemble card-not-present commerce unless a different payment architecture expressly applies.

Traditional signals may therefore remain relevant. Depending on the checkout implementation, a merchant might use address information, network-token signals, account history, behavioral data, shipping details, authorization results, agent credentials, and EMV 3DS.

However:

AVS/CVV success does not prove customer intent.

A correct billing address can indicate that payment information matches issuer records. A correct verification code may be useful during authorization where applicable. Neither necessarily proves that the customer instructed the agent to buy the exact item.

Similarly, 3-D Secure can authenticate the consumer or support issuer risk analysis, but it should not be described as universal proof that the customer approved every product, merchant, optional add-on, or final price.

Merchant Fraud Screening and Step-Up Confirmation

Agentic commerce should add useful trust signals without replacing merchant fraud screening.

Merchants may still evaluate:

• customer account history;
• transaction amount;
• shipping destination;
• order velocity;
• unusual product combinations;
• device or session information where lawful and available;
• agent identity signals;
• discrepancies between the proposed order and mandate;
• account-takeover indicators.

A higher-risk or out-of-policy transaction can trigger customer confirmation instead of immediate rejection. Examples might include a substantially higher amount than usual, a changed shipping address, subscription enrollment, a new merchant, or a purchase outside the agent’s normal permissions.

Do not publish or hard-code easily exploitable fraud thresholds merely to support AI automation.

For complementary defensive strategies, see this overview of AI-driven merchant fraud detection.

Merchant Terms, Price Changes, Subscriptions, and Marketplace Purchases

Delegated payment authority does not override the merchant’s legal obligations or business rules. An AI assistant can only purchase what a merchant is legitimately willing and permitted to sell under the applicable transaction terms.

The merchant must still apply pricing, inventory, shipping, returns, customer eligibility, sanctions controls where applicable, restricted-goods rules, and any legally required identity or age verification. A customer’s instruction to an AI agent cannot substitute for legally required verification for an age-gated or otherwise regulated product.

Dynamic Prices, Shipping, Upsells, and Substitutions

Suppose an agent finds a product at $72 but the checkout price changes to $86 before purchase. Whether it can proceed should depend on the customer’s mandate.

A strong mandate might allow a specific percentage or dollar variation. If the new price exceeds the customer’s permitted range, the workflow should request confirmation rather than interpreting a general instruction to “buy the best option” as unlimited pricing authority.

The same principle applies to:

• expedited shipping;
• substitute products;
• alternative sellers;
• insurance;
• warranties;
• optional service packages;
• tips;
• membership enrollment.

Agents should not silently add optional charges unless they clearly fall inside the customer’s permission.

The final order confirmation should show the merchant, items, quantity, amount, delivery details, payment reference, timestamp, and agent involvement where that information is appropriate and useful. Avoid storing unnecessary sensitive payment information merely to create a more detailed receipt.

Subscriptions and Stored Credentials

Subscription enrollment deserves additional care because one AI decision can create future payment obligations.

A customer authorizing an agent to make a one-time purchase should not automatically be treated as granting unlimited consent to future recurring billing. Merchants should obtain and document the consent required for the recurring arrangement itself and follow applicable stored-credential, card-network, consumer-protection, cancellation, and disclosure rules.

In the United States, the FTC continues to enforce the Restore Online Shoppers’ Confidence Act in connection with online negative-option programs. Recent FTC enforcement describes ROSCA as requiring clear material disclosures, express informed consent before recurring charges, and a simple mechanism to stop recurring billing.

An agent that renews an existing subscription also presents a different authorization question from an agent that creates a brand-new recurring obligation.

Marketplace and Merchant-of-Record Complexity

A marketplace transaction may look like:

Customer → AI Agent → Marketplace → Third-Party Seller → Payment Provider

The merchant of record, seller of record, marketplace operator, payment facilitator, and underlying seller may not be the same entity.

Do not assume the AI platform automatically becomes merchant of record simply because the customer interacted with it first. Refund duties, descriptors, taxes, disputes, consumer disclosures, and fulfillment responsibility depend on the actual commercial and payment structure.

AI Checkout Disputes: Unauthorized Purchase or Bad Agent Decision?

Disputes are likely to become one of the defining operational challenges of agentic commerce because “the AI did it” can describe very different problems.

Consider these customer complaints:

• “I never authorized the assistant to buy anything.”
• “The agent had permission, but it exceeded my $100 limit.”
• “I asked for black shoes and it bought brown shoes.”
• “It bought from the wrong merchant.”
• “The agent submitted the order twice.”
• “I revoked access before the purchase.”
• “Someone took over my AI account.”
• “I approved the item but not the subscription.”

Those scenarios should not automatically enter the same dispute workflow.

Unauthorized Transaction vs. Authorized but Incorrect Purchase

An unauthorized transaction allegation says valid authority to use the payment account did not exist for the transaction.

An authorized but incorrect purchase can mean that the customer validly delegated purchasing authority but the software chose an unwanted product, used poor judgment, selected an undesirable merchant, or otherwise performed the task incorrectly.

That difference can determine whether the problem is primarily a payment dispute, refund request, platform-service issue, merchant-fulfillment problem, contractual claim, or some combination.

U.S. Regulation Z is particularly instructive for credit cards: unauthorized use is defined around use by someone other than the cardholder without actual, implied, or apparent authority and from which the cardholder receives no benefit. The official commentary also explains that authority questions can depend on applicable law.

Debit-card and bank-account transactions can involve different protections under Regulation E. CFPB rules define conditions and consumer-liability limits for unauthorized electronic fund transfers, illustrating why merchants should never treat all payment rails as having identical dispute law.

Buyer’s Remorse Is Not Automatically Unauthorized Use

A customer may dislike what the AI selected even when the agent operated within a valid mandate.

For example, a customer tells an agent, “Buy any well-reviewed coffee maker under $150 from an approved merchant.” The agent buys one for $129. The customer later decides the design is unattractive.

That may be a valid return request under the merchant’s policy. It does not automatically follow that the card transaction was unauthorized.

Conversely, if the agent was limited to $150 but buys a $900 machine after a compromised account changed the mandate, the authorization issue becomes much more significant.

Merchants should therefore give support teams categories that distinguish authorization complaints from fulfillment problems, product dissatisfaction, duplicate transactions, non-delivery, cancellation requests, and true account compromise.

Refunds Before Chargebacks

Normal customer service remains important.

Customers should have accessible processes for:

• cancellation;
• wrong product;
• duplicate purchase;
• non-delivery;
• damaged goods;
• partial refund;
• full refund.

Current card disputes are generally handled through existing network dispute structures rather than a single universal “AI-agent chargeback” reason code.

A merchant should not invent new reason codes or assume an AI label changes the governing network rules.

What Evidence Matters When an AI Purchase Is Disputed?

Strong AI transaction evidence should answer three related but separate questions:

1. Who controlled the relevant customer account?
2. What authority did the customer grant?
3. What transaction actually resulted from that authority?

A merchant does not need to retain an entire AI conversation to answer those questions. In fact, indiscriminate retention may create privacy, security, and compliance problems.

Useful evidence can include:

• customer account authentication;
• agent identity or platform verification;
• mandate version;
• spending and merchant limits;
• transaction-specific confirmation;
• order contents;
• final price;
• authorization timestamp;
• token or credential reference;
• relevant device/account history;
• shipping and delivery evidence;
• confirmation notifications;
• customer communications;
• cancellation and refund records.

Which evidence matters will depend on the dispute type and network rules.

Proof of Authentication Is Not Proof of Exact Purchase Intent

This distinction deserves repetition because it can prevent major design mistakes.

Imagine the customer successfully authenticates using a passkey at 10:00 a.m. and tells an agent to “find a good desk chair.” At 2:00 p.m., the agent buys a $1,200 designer chair even though the customer expected something below $250.

The successful morning authentication helps establish account access. It does not, by itself, answer whether the afternoon purchase satisfied the customer’s authorization.

Evidence should connect the authenticated customer to a mandate and the mandate to the resulting transaction.

Emerging frameworks are attempting to improve this connection. AP2, for example, defines linked checkout and payment mandates and describes their potential use as evidence in disputes. 

Mastercard describes “Verifiable Intent” as an approach for creating tamper-evident records of user-authorized agent activity. These are evolving frameworks, not universal dispute rules.

Agent Decision Logs and Data Minimization

Decision logs can be useful when they record:

• the purchase instruction;
• constraints;
• selected product;
• selected merchant;
• final amount;
• confirmation event;
• resulting order reference.

But the evidence system should not become a warehouse of private customer conversations.

Retain only information legitimately necessary for fulfillment, fraud control, support, payment disputes, security investigations, and applicable legal or regulatory requirements. Sensitive personal preferences, unrelated prompt history, authentication secrets, and full payment credentials should not be copied into general-purpose AI logs.

Agentic commerce can create new data flows involving purchase intent, delivery information, account identity, personal preferences, and payment metadata. Privacy and security reviews should map those flows before launch rather than after the first incident.

Fraud, Account Takeover, Prompt Manipulation, and Duplicate Payments

Agentic commerce does not remove familiar ecommerce fraud. It creates additional ways that legitimate credentials and legitimate software can be misused.

An attacker might compromise a customer account, AI-platform session, connected email account, stored payment relationship, or device. If that compromised account also has broad autonomous purchasing authority, the impact can extend beyond account access into immediate financial transactions.

Controls should therefore combine strong login security, mandate limits, anomaly detection, tokenized credentials, customer notifications, and step-up authentication where appropriate.

Instruction Manipulation and Merchant Content

AI agents can also be exposed to malicious or misleading content that attempts to influence their actions.

Merchants and platforms should defensively design agents so external product descriptions, webpage content, messages, or tool results cannot silently override customer spending rules or system-level commerce policies.

Merchants themselves should avoid deceptive content intended to manipulate agents into adding products, increasing quantities, selecting more expensive options, hiding material terms, or bypassing consumer restrictions.

The medium may change from a human screen to an agent-readable interface, but consumer-protection concerns around material representations, consent, and deceptive conduct do not disappear simply because software is making the intermediate decision.

Idempotency and AI Retry Loops

Autonomous checkout increases duplicate-payment risk because software often retries operations after errors and timeouts.

A safe payment API should protect against:

• network timeout followed by retry;
• agent tool-call duplication;
• browser automation resubmission;
• webhook retry;
• user and agent submitting at nearly the same time;
• repeated authorization attempts after a decline.

Where supported, use an idempotency key tied to the intended business operation and maintain server-side order state so repeated identical requests cannot create multiple purchases.

An AI agent also should not repeatedly resubmit a declined payment without controlled retry rules. Excessive retries can create duplicate transactions, fraud alerts, customer confusion, and poor issuer outcomes.

A useful state model is:

Created → Customer/Agent Authorized → Authentication Required → Authorized → Captured → Fulfilled → Refunded/Disputed

Actual provider terminology will vary.

Webhooks, Reconciliation, and the Source of Truth

An agent saying, “Your payment succeeded,” is not authoritative evidence that the transaction actually succeeded.

The merchant should confirm final payment status with the processor, gateway, acquirer, or other relevant payment provider and reconcile API responses, asynchronous webhooks, and order state.

This rule is critical:

The processor/acquirer payment state—not the AI assistant’s conversational response—should determine whether an order is financially authorized and ready for fulfillment.

Similarly, refunds should follow the merchant’s verified transaction records. An AI assistant should not be able to instruct the merchant to send a refund to an unrelated card, wallet, or bank account merely because it claims to represent the customer.

Who Bears Liability When Something Goes Wrong?

There is no responsible answer to AI commerce liability that begins with “the AI company always pays” or “the merchant always loses.”

Liability may be divided among the consumer, merchant, issuer, acquirer, card network, AI platform, agent provider, marketplace, payment provider, or another intermediary depending on the applicable rules and facts.

Potential factors include:

• payment rail;
• consumer or commercial card;
• contractual relationships;
• actual or apparent authority;
• credential type;
• authentication;
• tokenization;
• fraud controls;
• merchant performance;
• fulfillment;
• disclosures;
• recurring-payment consent;
• network dispute rules;
• applicable state and federal law;
• platform terms;
• transaction evidence.

The AI assistant itself should not be treated as a legal cardholder or independent bearer of ordinary consumer payment rights merely because it performed the technical action.

Liability Scenario Table

Scenario	Main Question	Potentially Relevant Parties
Stolen customer account	Who actually authorized the transaction?	Consumer, issuer, platform, merchant, payment provider
Agent exceeded mandate	Was delegated authority exceeded?	Consumer, agent provider, platform, merchant, issuer
Merchant shipped wrong item	Was fulfillment incorrect?	Merchant, marketplace, seller, consumer
Agent chose wrong product	Was the purchase still within customer authority?	Consumer, agent provider, platform, merchant
Duplicate checkout	Where did the duplicate originate?	Merchant, platform, payment provider, agent
Card fraud	Was the credential compromised or used without authority?	Consumer, issuer, merchant, network, payment provider
Recurring charge created unexpectedly	Was valid recurring consent obtained?	Merchant, platform, consumer, issuer
Price changed beyond mandate	Did the customer permit the increased price?	Merchant, platform, agent provider, consumer

“Potentially relevant” is intentional. A scenario table cannot determine legal liability.

Consumer Protection and Electronic Consent

Consumer-protection rules continue to apply when AI becomes the interface.

In the United States, credit-card unauthorized-use protections under Regulation Z and electronic-fund-transfer protections under Regulation E can apply differently depending on the payment instrument and circumstances. Merchants should therefore avoid promising one universal dispute result for “AI transactions.”

Electronic consent can also matter, but an AI instruction should not automatically be labeled a legally binding electronic signature in every context. Whether an electronic action satisfies a particular signature, consent, record-retention, or contract requirement depends on applicable law and the transaction.

For recurring charges, merchants should pay particular attention to material disclosures and affirmative consent rather than assuming that a broad AI-shopping permission authorizes future billing indefinitely.

Authentication and Tokenization Do Not Settle Every Liability Question

Authentication can materially affect fraud analysis and, under certain card-network programs and transaction types, can influence dispute or liability outcomes.

That does not mean authentication transfers all possible liability for product selection, non-delivery, misrepresentation, recurring billing, agent error, or other disputes.

The same is true of tokenization. A network token can reduce credential exposure and help bind payment use to a particular context. It does not decide whether the customer wanted the product or whether the merchant fulfilled the order correctly.

Emerging Agentic-Commerce Protocols and Merchant Architecture

Merchants should monitor agent-payment frameworks, but they should avoid rebuilding payment systems around the assumption that one protocol has already won.

Visa currently publishes Trusted Agent Protocol specifications for merchant recognition of approved agents using signed messages and related consumer and payment context. 

The documentation supports web and API interaction and describes mechanisms for preventing replay and validating trusted-agent messages, while Visa also cautions that associated capabilities are still being developed and deployed in some cases.

Mastercard Agent Pay is a launched program that builds on network tokenization and describes registered agents, consumer consent, and verifiable intent as elements of its agentic-commerce strategy. 

Mastercard has also announced authenticated agentic transactions and market deployments, while some capabilities and ecosystem integrations continue to expand.

AP2 is an open agent-payments protocol with published specifications and sample implementations. Its ongoing standardization work means merchants should treat it as an important emerging framework—not a mandatory replacement for existing payment-network rules.

Browser Automation vs. Structured Agent APIs

Agents can interact with merchants by driving conventional web checkout or by using structured commerce interfaces.

Area	Browser Automation	Structured Agent API
Merchant visibility	May resemble automated browser traffic	Can explicitly identify agent context
Reliability	Sensitive to page and UI changes	More deterministic when well designed
Authorization context	Often difficult to transmit cleanly	Can carry structured permission context
Security	Depends heavily on browser/session controls	Can use signed messages and scoped credentials
Auditability	May require reconstructing browser activity	Easier to attach structured transaction records
Checkout compatibility	Can work with existing sites	Requires merchant/platform integration

Browser automation is not inherently illegitimate, and APIs are not automatically safe. Security depends on the actual implementation.

A structured agent-to-merchant request might eventually contain product identifiers, quantity, shipping details, customer-authority context, payment tokens, and confirmation requirements.

Agent Identity and Whitelisting

A merchant may choose to recognize trusted agent platforms or cryptographically signed agent identities.

Visa’s Trusted Agent Protocol is a current example of a network-backed mechanism intended to help merchants distinguish trusted commerce agents from unknown automation. However, there is no universal global AI-agent whitelist that merchants are required to adopt.

Any recognition program should sit alongside—not replace—payment credential validation, merchant fraud controls, customer authentication where needed, and order-policy checks.

Merchant Agentic-Commerce Readiness Checklist

Merchants do not need to predict the final form of AI shopping to prepare. Most of the necessary controls are recognizable payment-engineering, fraud, identity, security, and customer-service disciplines adapted to delegated software behavior.

The objective is to know who or what initiated the order, what authority applied, how the payment was authenticated and authorized, what the merchant agreed to sell, and what evidence survives afterward.

Area	Verify
Customer-agent consent	Customer intentionally enabled purchasing authority
Agent permissions	Merchant, product, amount, category, and time limits are clear
Spending limits	Per-order and aggregate controls exist where appropriate
Credential tokenization	Reusable raw credentials are minimized
Payment authentication	Issuer/customer authentication is supported where required
Merchant fraud screening	Agent context supplements conventional risk controls
Transaction confirmation	Customer can see merchant, items, amount, and delivery
Idempotency	Retries cannot silently create duplicate orders
Payment-state reconciliation	Processor/provider state is authoritative
Refund controls	Refunds return through approved transaction channels
Dispute evidence	Authorization, order, and fulfillment evidence is retained
Privacy/data minimization	Only necessary agent/customer evidence is stored
PCI DSS	Card-data exposure and service-provider responsibilities are reviewed
Incident response	Integration can be restricted or disabled quickly

Merchant teams should also monitor agent-related customer complaints separately from conventional ecommerce issues. Useful measures can include the proportion of agent-initiated orders, customer confirmations, declines, duplicate attempts, refunds, unauthorized-payment claims, other disputes, and account-takeover indicators.

Do not invent benchmark targets before you have your own operational data.

Agentic Commerce Risk Dashboard

Metric	Why It Matters
Agent-initiated orders	Measures adoption and exposure
Customer confirmations	Shows how often autonomy becomes human-assisted
Payment declines	Identifies authorization or risk friction
Duplicate attempts	Reveals retry or idempotency problems
Refund rate	Highlights fulfillment or agent-selection dissatisfaction
Unauthorized-payment claims	Tracks consent and account-compromise risk
Other disputes	Separates fraud from service/product issues
ATO indicators	Detects compromised accounts with purchasing authority

Incident Response for an AI Integration

If one AI integration begins producing suspicious purchases, duplicates, or unusual payment failures:

1. Preserve transaction and authorization evidence.
2. Limit or disable the affected integration if necessary.
3. Verify payment state directly with the payment provider.
4. Protect affected customer accounts and credentials.
5. Investigate agent permissions, authentication, and authorization.
6. Notify relevant payment, platform, security, or network partners as appropriate.
7. Correct the weakness before returning the integration to normal operation.

A controlled shutdown mechanism matters because agent automation can amplify errors rapidly.

Questions Merchants Should Ask Their Providers

Agentic-commerce sales material can blur “available now” with “on the roadmap.” Merchants should force those categories apart before integration.

Questions for a payment provider should include:

• Can agent-driven transactions use tokenized or restricted credentials?
• How is customer authentication handled?
• How are stored credentials classified and processed?
• Can transaction-level spending or merchant restrictions be applied?
• Are agent-initiated transactions identifiable in reporting?
• What intent or mandate evidence can reach dispute systems?
• How do applicable liability-shift rules work for the exact transaction type?
• Are idempotency keys supported?
• How should agent retries after declines be controlled?
• How are network tokens provisioned and restricted?
• How should AI-requested refunds be authenticated?
• Which agentic capabilities are live, limited-release, pilot, or experimental?
• What PCI DSS responsibilities remain for the merchant and platform?

Questions for an AI commerce platform should include:

• How does the customer grant purchasing authority?
• Can permission be limited by price, merchant, product, category, and time?
• How is authority revoked?
• Is transaction-specific confirmation available?
• What payment credential does the agent receive?
• Is a reusable PAN ever exposed to the model or agent?
• What evidence of customer intent is retained?
• How are duplicate tool calls and checkout retries prevented?
• What happens when price or availability changes?
• Who handles refunds and customer support?
• How is account takeover detected?
• What information is shared with merchants?
• Which payment-network or open agent protocols are actually supported today?

Answers should be documented in architecture decisions, merchant contracts, operational procedures, and dispute playbooks instead of existing only in vendor demonstrations.

Common Agentic Commerce Mistakes

Several mistakes repeatedly stem from treating AI checkout as a simple automation layer rather than a delegation and payment-control problem.

Avoid:

• assuming an agent is authorized because it possesses a payment credential;
• confusing issuer approval with customer intent;
• confusing customer authentication with approval of the exact order;
• giving an agent unrestricted reusable card credentials;
• placing card details or sensitive authentication data into AI logs;
• storing CVV after authorization;
• failing to define spending, product, merchant, or time constraints;
• overwriting historical mandate evidence after settings change;
• assuming a token proves customer consent;
• allowing uncontrolled payment retries;
• ignoring duplicate orders;
• fulfilling based on an AI message instead of processor payment state;
• treating a wrong product and an unauthorized payment as the same problem;
• assuming agent purchases have entirely new chargeback categories;
• assuming an AI platform automatically becomes merchant of record;
• assuming authentication shifts every type of liability;
• treating emerging protocols as settled law.

The better design principle is separation of concerns: intent evidence proves what the customer wanted; identity controls help prove who acted; payment authentication helps validate the payer; authorization establishes whether the payment was approved; merchant systems determine whether the order should be accepted; and fulfillment evidence shows what happened afterward.

Frequently Asked Questions

What is agentic commerce?

Agentic commerce is digital commerce in which an AI agent performs shopping tasks on behalf of a person or business. Those tasks can range from product research and recommendation to cart creation, merchant selection, checkout, and payment initiation.

Not every AI shopping tool has autonomous purchasing authority. Some agents stop before checkout, while others may act within predefined permissions such as a spending limit, approved merchant list, or product category.

The key payment difference is delegation: software may initiate a purchase without the customer personally interacting with the merchant’s final checkout screen. That makes customer intent, agent authority, credential security, authentication, transaction evidence, and dispute handling especially important.

Can an AI assistant legally make a purchase for a customer?

Software can technically initiate purchases in supported environments, and current payment initiatives are being built specifically for delegated agent transactions. Whether a particular purchase creates enforceable obligations or qualifies as authorized depends on the customer relationship, agent authority, transaction structure, payment rules, applicable contracts, and law.

There is no single rule that declares every AI-initiated purchase valid merely because the customer enabled an assistant.

Merchants should therefore document how purchasing authority was granted, what limits applied, and how the resulting transaction matched those instructions. For regulated goods, recurring billing, or transactions requiring specific forms of consent or verification, agent authority cannot be assumed to override those additional requirements.

What counts as customer authorization for an AI purchase?

There is no universal checklist that automatically proves authorization across every payment rail and jurisdiction. Useful evidence can include explicit enrollment, authenticated account access, spending limits, approved merchants, product constraints, delivery restrictions, timestamps, transaction-specific confirmation, and securely retained mandate records.

The strongest evidence usually connects three things: the customer, the permission, and the specific transaction.

For example, “the customer logged in yesterday” is weaker evidence of exact purchase intent than a record showing that the authenticated customer granted the agent permission to buy Product X for up to $100 and the resulting order cost $89.

Applicable payment and consumer laws still determine the legal significance of that evidence.

Is AI payment authorization the same as card authorization?

No. AI payment authorization can refer to a customer’s permission for an AI assistant to use a payment method or initiate a purchase. Card authorization normally refers to an issuer’s approval or decline of a card transaction.

Those decisions occur at different layers.

A customer might properly authorize an agent, yet the issuer can still decline the card. Conversely, an issuer may approve a technically valid card transaction even though the customer later claims the agent exceeded its instructions.

Merchants should separately track customer-to-agent authority, payment authentication, issuer authorization, and merchant order acceptance. Combining all of them into one “authorized” flag makes later fraud investigations and disputes much harder to interpret.

How can merchants verify that an AI agent is acting for a real customer?

Merchants can combine familiar customer-account signals with agent-specific trust mechanisms where supported. Those controls might include authenticated merchant accounts, signed agent identities, customer-recognition tokens, transaction mandates, device context, payment-token information, and transaction-specific confirmations.

Visa’s Trusted Agent Protocol is one current example of a framework designed to let participating merchants verify signed requests from approved commerce agents and receive related customer and payment context. It is not a universal requirement, and capabilities may vary by market and deployment.

Merchants should still apply ordinary fraud screening and should not equate a recognized agent identity with proof that every proposed order falls within the customer’s authority.

Can an AI shopping agent use a customer’s saved card?

It can in supported implementations if the payment arrangement, platform permissions, merchant setup, network rules, and customer consent allow that use. However, “saved card” should not automatically mean the AI model receives the underlying card number.

A safer architecture uses a wallet, vault, network token, merchant token, or another restricted credential so the agent can request payment without receiving unrestricted reusable card data.

Stored-credential rules remain relevant, particularly for recurring or merchant-initiated transactions. A customer’s broad instruction to “use my saved card when shopping” also should not automatically be interpreted as consent to unrelated subscriptions or indefinite recurring charges.

Credential access and purchasing authority are separate permissions.

Are tokenized credentials safer for AI agents?

Tokenization can reduce the exposure of reusable payment credentials because a token substitutes for sensitive account information within a defined payment architecture.

Agentic systems may gain additional protection when tokens or credentials are limited by merchant, amount, transaction count, expiry, or agent context. Current network initiatives from Visa and Mastercard are building agentic-payment capabilities on established tokenization infrastructure.

However, tokenization does not solve every risk. A valid token can still be used for an unwanted transaction if permissions are too broad or an account is compromised.

Tokenization primarily helps protect credentials. Mandates and consent records help address authority. Fraud controls assess risk. Those functions complement rather than replace one another.

Who is liable if an AI agent buys the wrong product?

There is no universal answer. First determine whether the customer authorized the agent to make the purchase and whether the agent stayed within the mandate.

If the customer said, “Buy any qualifying printer below $250,” and the agent selected an undesirable but qualifying printer, the issue may be primarily between the customer and agent platform or handled through the merchant’s return policy.

If the agent exceeded a hard spending limit or bought outside an approved category, authorization and platform responsibility become more important.

If the merchant shipped a different item than the one ordered, fulfillment is the central issue.

Payment rules, platform agreements, merchant terms, consumer law, and the evidence surrounding the transaction can all affect responsibility.

What happens if an AI assistant exceeds the customer’s spending limit?

The first question is whether the limit was actually part of the enforceable agent mandate and where it was supposed to be enforced.

A well-designed system should reject or step up a transaction that exceeds a hard spending ceiling rather than allow the agent to reinterpret the limit.

If the purchase nevertheless completes, merchants and providers may need to examine the mandate, authorization records, agent platform behavior, payment authentication, and whether the merchant had visibility into the limit.

A spending-limit violation does not automatically determine the outcome of a card dispute, because network rules and applicable law still govern the payment claim. It does, however, create important evidence that the agent may have acted outside delegated authority.

Can a customer dispute an AI-agent purchase as unauthorized?

A customer can raise an unauthorized-payment claim when they believe a transaction was made without valid authority, but the governing rights and outcome depend on the payment instrument and circumstances.

For U.S. credit cards, Regulation Z addresses unauthorized use and specifically considers whether the person using the credit card possessed actual, implied, or apparent authority. Debit and other electronic transfers can instead fall under Regulation E’s separate framework.

An AI label does not automatically make the transaction authorized or unauthorized.

The dispute investigation may therefore examine whether the customer enabled the agent, what limits applied, whether those limits were revoked, how the customer authenticated, and what transaction the agent actually executed.

What evidence can a merchant use in an AI checkout dispute?

Potential evidence includes account authentication records, agent identity information, the customer mandate, transaction-specific confirmation, item and pricing details, timestamps, payment-token references, authorization records, delivery evidence, prior transaction history where relevant, customer communications, and refund or cancellation records.

The evidence required to answer “unauthorized payment” may differ from evidence needed to answer “merchandise not received” or “wrong product.”

Merchants should therefore preserve structured transaction evidence instead of simply exporting an entire AI conversation.

Emerging protocols such as AP2 are exploring signed mandate and receipt structures that can make intent more auditable, but merchants should not assume those records automatically satisfy every network dispute requirement or legal standard.

Do card networks have special chargeback rules for agentic commerce?

Merchants should not assume there is a universal new “AI agent chargeback” category.

Networks are actively introducing agentic-commerce technologies, tokenization mechanisms, verified-agent capabilities, and intent frameworks, but ordinary dispute rules still remain relevant to transactions using existing card rails.

The correct dispute category will depend on what allegedly went wrong: unauthorized use, duplicate processing, non-delivery, wrong merchandise, recurring billing, refund issues, or another recognized dispute type.

Merchants should confirm current requirements with their acquirer or payment provider for the specific card network and transaction.

Avoid inventing reason codes or treating a marketing phrase such as “agentic transaction” as a replacement for established dispute classifications.

Does 3-D Secure prove the customer wanted the exact purchase?

No. EMV 3-D Secure is an ecommerce authentication framework designed to help issuers and merchants authenticate consumers and manage card-not-present fraud. It can exchange transaction, device, and payment information and may involve a frictionless or challenge experience.

Successful authentication can be valuable evidence that the legitimate account holder participated in an authentication event.

It does not necessarily prove the customer’s commercial intent regarding every element of an AI-generated order.

For example, a customer could authenticate while enabling an agent but later claim that the agent exceeded a $200 limit. Resolving that issue requires evidence about the mandate and actual purchase, not only the authentication result.

How can merchants prevent duplicate AI-agent transactions?

Use server-side transaction state and idempotency protections wherever the payment API supports them.

A single intended order should have a stable business identifier or idempotency key so a network timeout, agent retry, repeated tool call, or browser resubmission does not silently create a second charge.

The system should also check whether an authorization or completed order already exists before submitting another payment.

After ambiguous responses, query the payment provider or reconcile webhook/API state rather than telling the AI to “try again” automatically.

Declined transactions should follow controlled retry policies. An autonomous agent should never repeatedly submit payments simply because it assumes another attempt may work.

What should merchants prepare before accepting agentic-commerce orders?

Start with architecture and evidence rather than an “AI checkout” marketing layer.

Define how customer authority is granted, limited, revoked, and preserved. Determine how the merchant recognizes supported agents, receives payment credentials, triggers authentication, prevents duplicate transactions, verifies final processor status, and stores dispute evidence.

Review PCI DSS scope, tokenization, sensitive logging, account-takeover controls, refunds, subscription consent, privacy, incident response, and customer notifications.

Also require providers to separate live capabilities from pilots or planned features.

A merchant that can answer who authorized the agent, what the agent was allowed to buy, what payment was approved, and what was actually fulfilled will be far better prepared for agentic commerce than one that merely automates the checkout button.

Conclusion

Agentic commerce does not make the fundamentals of payments disappear. It introduces another decision-maker—the software agent—between customer intent and merchant checkout.

That makes precision essential:

Customer authorization of the AI agent is not the same as issuer authorization of the transaction. Authentication is not the same as approval of the exact purchase. Tokenization protects credentials but does not prove consent. A processor approval does not guarantee that the agent followed the customer’s mandate.

The strongest agentic-commerce architecture therefore connects customer intent to a limited agent mandate, protects payment credentials through tokenization or other scoped mechanisms, authenticates the appropriate parties, preserves merchant fraud controls, prevents duplicate retries, verifies payment state with the processor, and retains only the transaction evidence legitimately needed for support, fraud, security, compliance, and disputes.

Current initiatives from Visa, Mastercard, Google/FIDO, and other ecosystem participants show that agent authentication, verifiable intent, tokenized credentials, and structured mandate evidence are moving from concepts into real payment technology. 

But availability is still uneven, standards continue to evolve, and no single protocol has replaced existing card-network rules, consumer-protection law, merchant agreements, or payment-rail-specific dispute requirements.

For merchants, the goal should not be to predict which agent protocol ultimately dominates. It should be to build a checkout system that can reliably answer four questions:

Who was the agent acting for? What was it allowed to do? Was the actual payment properly authenticated and authorized? What happened after the order was placed?

Those answers will matter far more than whether the customer personally pressed the final button.

This article is for general informational purposes and does not constitute legal, regulatory, payment-network, cybersecurity, or compliance advice. Agentic-commerce technologies, network programs, laws, and dispute requirements continue to evolve. 

Merchants should confirm current requirements with qualified counsel, their acquirer or payment provider, relevant card networks, and applicable regulators before implementing autonomous or delegated payment functionality.