Agentic Commerce Readiness: What Merchants Need Before AI Can Shop and Pay

Consider this illustrative scenario: a customer asks an AI assistant to find a product, stay within a budget, and have it delivered by Friday. The assistant finds your store. Your catalog says the item is available. Your checkout accepts the payment.

Then fulfillment discovers that the item is backordered.

The customer does not care which system misunderstood the inventory feed. They want the product they ordered, or their money back. Your support team needs an answer. Your payments team needs a transaction record. An impressive AI experience has become an ordinary merchant problem, with a more complicated trail of evidence.

Before a merchant lets AI complete a purchase, its team needs to know what was authorized, what was promised, and how to resolve what goes wrong.

That is where I would start the agentic commerce conversation: can the merchant support the promises being made on its behalf?

The opportunity is real. Better discovery and fewer manual steps can create new paths to a sale. But expanding the buying interface also expands the number of places where product information, customer instructions, checkout logic, and payment status can get out of sync.

What agentic commerce changes for merchants

Agentic commerce describes shopping activity that an AI agent performs on a customer’s behalf. That can include research and recommendations, cart preparation, or execution of a purchase within the customer’s instructions. For merchant planning, I would distinguish three operating models: AI-assisted discovery, agent-prepared checkout, and delegated purchase.

For a merchant, those stages carry different responsibilities.

Treat these as operating models, not interchangeable labels. Making a product discoverable does not establish that an agent is permitted to purchase it. Accepting a payment request does not establish that your warehouse can fulfill the order.

For referral partners, the first useful question is where the merchant intends to participate. A merchant looking for better AI discovery has a different project from a platform enabling delegated checkout.

What the emerging network frameworks mean for merchants

Network frameworks are useful evidence about how a flow is designed. They are not interchangeable operating agreements or proof that a merchant’s current checkout is enabled.

Visa’s Trusted Agent Protocol documents cryptographic recognition of Visa-approved agents and signed interaction data. Its public implementation illustrates request verification, time-bound signatures, and replay protections. Confirm the trust mechanism, supported agents, message handling, and applicable participation terms with your commerce and payment providers. Recognition alone does not establish every permission or merchant acceptance condition. [2][3]

Mastercard Agent Connect describes participant connectivity across catalog discovery, cart orchestration, and payment enablement. Its materials identify real-time catalog access through an agent API call and capabilities that evolve with availability. Ask which functions, credentials, markets, and merchant onboarding paths your providers actually support; a product description is not a production commitment. [1][4]

American Express’s ACE Developer Kit describes registered-agent enrollment, customer-defined intent limits, and credentials scoped to that intent. Treat it as a network-specific design to confirm with the relevant provider, including access requirements and which controls are implemented in your flow. [6]

Across all three, distinguish documented capabilities, participation requirements, pilot access, and generally available services. A pilot or an announced feature is not general availability for your merchant account. Obtain a written description of the supported configuration, operating responsibilities, exceptions, and launch eligibility before committing to an integration.

Make product data usable and keep the offer current

A clean product page helps a customer decide. A consistent, machine-readable catalog helps an agent interpret the same decision without guessing at a size, a bundle, or a fulfillment condition.

Our recommendation is to give each sellable variant a stable identifier and a clearly defined record: name, attributes, quantity rules, price, currency, availability, fulfillment options, and relevant restrictions. A description should distinguish the base product from accessories and optional services.

Separate slow-changing descriptive content from fast-changing commercial data. A product’s material may remain accurate for months. Its available quantity and delivery estimate may change between discovery and checkout.

Mastercard’s Agent Connect page describes dynamic merchant catalogs and notes that real-time access requires an agent API call. A static feed should therefore not be treated as proof of current availability. [4]

For implementation, define which system is authoritative for each field, how updates propagate, and what happens when that system is unavailable. Recheck the order against authoritative price and inventory before committing it. If a quote expires or the selected item becomes unavailable, return an explicit exception.

Do not let an agent improvise the replacement policy. Substitution, backorder acceptance, and a later delivery date need a supported decision path.

Separate agent identity from permission to buy

A merchant needs to distinguish the software making a request from the customer whose money may be spent.

Visa’s public documentation and sample implementation describe HTTP Message Signatures under RFC 9421, public-key retrieval, time-bound signature fields, and replay protections. These are implementation details for participating flows, not instructions to trust a bot because it supplies a recognizable name. [2][3]

RFC 9421 provides a mechanism for signatures over selected HTTP message components. Signature coverage and application enforcement matter; a valid signature does not independently validate every business statement in a request. [5]

Operationally, keep four questions separate:

• Can we authenticate the requesting agent through a supported trust mechanism?
• Is it allowed to perform this action at this point in the journey?
• Does the proposed order remain within the customer’s delegated permission?
• Does the merchant permit this order under its own business rules?

A signed browsing request should not silently become checkout authority. A customer identifier should not become permission to change a shipping address. A permitted purchase should not become permission to enroll the customer in recurring billing.

The merchant’s integration may receive some of these decisions from a network, platform, or payment provider. Document that division of responsibility and the evidence available to the merchant. Do not claim to have independently verified a permission that your system never receives.

Turn customer intent into enforceable checkout limits

“Buy the best option” is a useful instruction for a conversation. It is incomplete as an operating policy.

A delegated purchase needs boundaries that the implemented system can enforce: what may be purchased, from which merchants, within what spending limit, and when the customer must approve a change. The merchant’s job is to understand which controls its chosen flow enforces and which decisions remain its responsibility.

For merchant readiness, define how the supported checkout flow handles quantity, variant, destination, delivery promise, recurring commitments, substitutions, and expiration of permission. Evaluate material changes at the time of purchase rather than assuming an earlier recommendation still applies.

Illustrative example

A shopper permits a one-time purchase with a final total of no more than $150. The item is $129, shipping is $12, and tax is $11. The total is $152. If the permission caps the all-in amount, the integration needs renewed approval or a supported alternative. The earlier product price did not satisfy the final spending limit.

The same discipline applies when a coupon disappears, an annual plan replaces a monthly plan, or an item gains a subscription commitment. Define what triggers a new customer decision. A merchant should not have to explain later that the agent interpreted a material change differently.

Confirm the credential and payment path

An ordinary gateway token, a network payment token, and a credential scoped to an agentic purchase are not interchangeable integration assumptions. Confirm the supported credential type and how it reaches the merchant’s payment stack.

Ask the provider who provisions it, what restrictions apply, how authentication and any step-up flow work, and which identifiers will be returned for support and reconciliation. Confirm the paths for authorization, capture, reversal, partial refund, and cancellation before enabling live orders.

Do not expand a credential’s permitted use simply because your gateway supports storage. A one-time purchase does not establish permission for a subsequent recurring payment.

Tokenization is also not a blanket statement that the entire merchant environment is outside PCI DSS scope. PCI SSC distinguishes EMV payment tokens from acquiring tokens and explains that scope depends on the data and systems involved. [7]

Keep this practical: use supported payment components, minimize account-data exposure, and validate the actual integration with the provider. Keep full payment credentials and sensitive authentication data out of AI prompts, general logs, and support transcripts.

This is a checkout-readiness question. A broader assessment of AI systems and payment-data security deserves its own review.

Build checkout for retries and uncertain outcomes

AI-driven checkout still needs a disciplined order and payment lifecycle. The integration should be able to distinguish a prepared cart, a submitted payment, a confirmed authorization, capture, fulfillment, cancellation, and refund.

Our recommendation is to make those states explicit and recoverable. Give the order a durable identifier. Use the payment provider’s supported idempotency mechanism, understand its scope and retention window, and define how duplicate requests are reconciled.

A timeout deserves special attention. The merchant may not know whether the provider accepted the request before the connection failed. Retrying with a fresh identifier can create another payment attempt when the first outcome is still unresolved.

Query the existing attempt or route it to a controlled reconciliation process. Do not turn “no response received” into “payment failed” without supporting evidence.

Likewise, a signed request is not an issuer approval. A successful authorization is not the same event as capture or fulfillment. Preserve each result and define which confirmed state allows the next action.

Example failure checks before launch

• Repeat the same purchase request and confirm the intended duplicate handling.
• Interrupt the response after submission and recover the original outcome.
• Deliver the same payment event twice and confirm it does not create two orders.
• Let the cart change before payment and require the appropriate revalidation.
• Cancel an order after authorization and verify the correct provider-supported handling.

Use a sandbox or isolated test environment. A successful demo purchase tests the happy path; these cases test whether the merchant can operate the channel.

Update bot controls without surrendering merchant control

An agent-ready channel should preserve protections against scraping, credential abuse, excessive requests, and unsupported actions. Our recommendation is to define access by action and evidence, then apply the appropriate control.

A catalog lookup, an inventory reservation, and a purchase attempt should not inherit the same permission. Restrict quantity, request rate, reservation duration, and access to account information according to the business model.

Where supported agent verification is available, coordinate implementation across the merchant application, site-protection provider, and checkout stack. Make sure intermediaries preserve the data needed for validation.

Decide what happens to an unrecognized or unverifiable request: deny the sensitive action, use an ordinary customer checkout, or request additional verification through a supported flow. Document the decision rather than creating an informal exception that bypasses the normal controls.

For regulated or restricted products, keep existing eligibility, licensing, jurisdiction, and other applicable checks in the operating path. Discovery through an AI interface does not establish eligibility to buy.

Preserve the customer relationship and dispute evidence

A new buying interface can create uncertainty about who the customer bought from and who should fix a problem. Make the seller identity, contact route, delivery expectations, cancellation terms, and return process clear in the experience the customer actually receives.

Send a usable confirmation and preserve the order record. Support should be able to connect the customer’s inquiry to the relevant commerce and payment references without reconstructing the journey from disconnected dashboards.

Our recommended evidence set includes:

Store only the information needed, protect access, and apply appropriate retention. Evidence availability is not a reason to retain every prompt or credential.

Do not assume that agent involvement creates a blanket liability shift or guarantees a dispute outcome. Obtain the applicable program and processing terms. Confirm who can retrieve authorization evidence, what the merchant can use in a dispute response, and who handles a purchase outside the customer’s instructions.

A refund workflow also needs to distinguish an agent’s request from authority to receive account information or change where money is returned. Use the supported refund path and retain its connection to the original transaction.

Use a readiness checklist with accountable owners

The following is Mentom’s operational recommendation, not a published network certification or universal mandate. Assign owners and demonstrate each control in the intended integration.

Start with one supported purchase flow and a deliberately limited assortment. Confirm the available networks, agents, credentials, and geography with the relevant providers. Set a review cadence and define when to pause the channel.

Measure more than conversion: price and inventory mismatches, permission exceptions, duplicate attempts, unresolved payment states, time to resolve refunds, and support contacts per completed order. Keep agent traffic segmented from conventional checkout so you can identify where the new channel changes behavior.

Expansion should follow evidence that the process works through failure, support, and reconciliation—not just evidence that an agent can click through checkout.

Where Mentom fits and what to ask next

Merchants and referral partners need a payments conversation that connects the technology to the business behind it.

Mentom’s Online Payments offering includes gateway and shopping-cart connectivity, hosted payment experiences, tokenized customer profiles, and 3-D Secure support. Integrated Payments supports platform-oriented payment components, onboarding, and status-event workflows. These are foundations to assess against a proposed commerce journey, with the actual configuration determined by merchant and provider fit. [8][9]

Bring us the business model, the current commerce platform and gateway, and the experience you want to support. Include who is acting for the customer, how permission is recorded, what credential is used, and how exceptions reach your team.

That gives the conversation somewhere useful to go: the payment configuration, the underwriting and operating implications, the required provider connections, and the work needed before a launch.

An existing payment connection alone does not demonstrate compatibility with a particular agentic-commerce program. Confirm the supported path before presenting it to a merchant as ready.

Questions merchants and referral partners are asking

Does accepting cards mean we are ready for agentic commerce?

It establishes an existing payment relationship. Readiness for a specific flow also depends on commerce data, permissions, supported credentials, controls, and exception handling.

Is Visa’s Trusted Agent Protocol required for every merchant?

The public materials reviewed here do not establish a universal requirement for every merchant. Confirm the current requirements of the participation agreement and payment flow you intend to use with the relevant provider. A documented recognition mechanism is not evidence that your existing checkout supports it. [2][3]

Does a verified agent mean the customer approved the order?

Agent recognition and purchase authority answer different questions. Confirm the permission evidence supplied by the implemented flow and enforce the merchant’s own acceptance conditions.

Can we allow discovery while keeping purchase completion in our normal checkout?

That is a useful starting model to evaluate. Confirm how the chosen platform handles the handoff and test whether the customer receives accurate final terms before paying.

Does agent involvement change chargeback liability?

Do not assume a general change. Confirm the applicable network program, authentication treatment, provider agreement, and dispute procedures for the actual transaction flow.

About the author

Dave Wilson is Chief Operating Officer at Mentom Payments. His Payments, Unpacked. articles connect payment rules, business models, risk, and the work of operating a merchant account.

More from Dave Wilson →