Agentic commerce readiness for AI-powered ecommerce

AI shopping agents are emerging as another ecommerce channel. They can search catalogs, compare variants, initiate checkout and monitor orders. Yet no single protocol guarantees this complete journey.

The Agentic Commerce Protocol, or ACP, focuses on agent-mediated checkout and payment interactions. Its documentation identifies OpenAI and Stripe as initial collaborators. The Universal Commerce Protocol, or UCP, is an open initiative with capabilities that can cover several commerce functions. Its contributors and supported extensions should be checked in the official UCP repository.

Discovery feeds, payment handoffs and post-purchase updates may still require separate services. Support also varies by platform, region, merchant eligibility and sales channel. Merchants should build for clear interfaces and interoperability rather than one provider.

Status checked: July 2026

Protocol publication does not mean that every feature is generally available. Check current specifications, platform release notes and commercial terms before planning production use.

Know which system is responsible

An AI agent interprets a customer's request. An agent platform connects that agent to external services. The merchant backend remains responsible for catalog, pricing, inventory and order rules. A payment provider handles payment credentials and authorization. The order management system coordinates fulfillment and returns.

A typical flow looks like this:

Customer → AI agent → agent platform or protocol adapter → merchant backend → payment provider

After payment, order events usually move between the merchant backend, order management system, fulfillment systems and customer support tools. The agent may receive updates through polling, callbacks or an intermediary platform.

This boundary matters. An LLM can propose an action, but deterministic commerce services should approve prices, stock, payments and order changes.

ACP and UCP do not provide identical capabilities

The two protocols should not be treated as interchangeable.

The safe design assumption is simple. Discovery data helps an agent find an item. Only the merchant's transactional systems can make an authoritative offer.

1. Make product data understandable

An agent needs structured data at product and variant level. Useful fields include:

• Stable product and variant identifiers
• GTIN, MPN and brand where applicable
• Title, description, taxonomy and canonical URL
• Variant relationships, options, size and color
• Condition, locale, currency and unit price
• Current price, promotions and eligibility rules
• Images, usage rights and alternative text
• Inventory status, fulfillment location and delivery promise
• Lead time, shipping restrictions and return constraints

Searchable feed data and transactional data serve different purposes. A feed may be cached for discovery. It should not be trusted as the final source for inventory, tax, shipping or payment totals.

Poor data has measurable effects. It can lower product-match accuracy, select an invalid variant or suppress listing eligibility. It can also increase abandoned and failed checkouts.

A single enterprise-wide canonical model can help, but it is not mandatory. Some organizations use domain-owned models with explicit mappings. Others use an anti-corruption layer between the PIM, ERP and storefront.

The essential controls are consistent:

• A governed source of truth for each field
• Stable identifiers across systems
• Named data owners
• Schema validation and required-field rules
• Versioned interfaces
• Defined handling for missing or conflicting values
• Monitoring for feed age, rejected records and mapping failures

Our articles on ecommerce data models and data contracts explain these foundations.

2. Make every transaction authoritative

Discovery information is informative. Checkout must return an authoritative state from the merchant backend.

ACP documents a checkout lifecycle with session-based operations. UCP has its own capability model and terminology. Similar concepts do not mean identical state transitions or extension points. Each integration should follow its relevant specification.

Before payment authorization, the backend should recalculate:

• Variant availability
• Inventory reservations
• Contract prices and promotions
• Shipping methods and delivery estimates
• Tax and duties
• Customer or market eligibility
• Currency and rounding
• Final payable total

For example, an agent may find shoes advertised at $99. The backend must still validate the size, destination, stock and final price. It should then return a quote or checkout state with an expiry time.

This separation is an architectural safeguard. Discovery feeds may be stale. A cached listing should not become a financial commitment without server-side validation.

The transaction model must also cover more than successful payment. Define explicit states for:

• Inventory holds and reservation expiry
• Quote or checkout-session expiry
• Payment authorization and capture
• Asynchronous or failed payments
• Partial capture and partial fulfillment
• Backorders and permitted substitutions
• Customer cancellation
• Returns and exchanges
• Partial or full refunds
• Chargebacks and disputes
• Lost, late or duplicated events
• Financial and inventory reconciliation

All state-changing requests need idempotency. Repeating the same request with the same key should not create another charge, reservation or order. Stores with fragile synchronization should first address their pricing architecture.

3. Design payments and fraud controls for delegated action

Agentic payments involve three separate control layers. They should not be treated as one mechanism.

Payment-token controls

A payment token can limit exposure of reusable card data. Stripe's Shared Payment Tokens support controlled credential sharing for agentic transactions. The exact restrictions depend on the payment scheme and token configuration. Where supported, bind the token or authorization to the merchant, amount, currency, checkout and expiry.

See the Stripe agentic commerce documentation for its supported flow and limitations.

Proof of user intent

AP2 mandates are cryptographically verifiable records of user intent or authorization. They are not payment credentials. They can help establish what the customer approved and under which conditions.

The integration must still verify the mandate, its signer, validity period and relationship to the requested action. See the official AP2 repository.

Merchant policy and fraud enforcement

The merchant remains responsible for enforcing its own transaction rules. An LLM should not decide whether a signature is valid or whether an amount exceeds an approved limit.

A production security baseline should include:

• Strong authentication for agents, platforms and merchants
• Least-privilege authorization scopes
• Signature and certificate verification
• Nonce or timestamp checks for replay resistance
• Idempotency for every state-changing operation
• Key rotation and secure secrets management
• Rate limits and bounded retry policies
• Verified webhook origins and payload signatures
• Step-up authentication for sensitive actions
• PCI scope analysis and tokenized payment references
• Ledger, payment and order reconciliation
• Security logs that exclude credentials and unnecessary personal data

Agent traffic should not be classified as suspicious by default. Fraud systems should distinguish a legitimate retry from a replay attack. They should also avoid vague identity rules that create hidden bias.

When a request cannot proceed, return an explicit outcome. Suitable responses include a decline reason category, safe retry guidance or a request for customer confirmation. Other options include step-up authentication and a short inventory reservation. Manual review is useful for selected cases, but it is not the only fallback.

4. Keep orders observable and attributable

Readiness continues after payment. Customers and agents need reliable access to order state. Delivery may use polling, merchant webhooks, platform callbacks or intermediary services.

For event-driven delivery, implement:

• Signed payload verification
• Delivery acknowledgments
• Retry with bounded backoff
• Event identifiers and deduplication
• Rules for out-of-order events
• State versioning
• Dead-letter handling
• Periodic reconciliation against the source system

Order events should cover confirmation, payment status, fulfillment, shipment, cancellation, returns, exchanges, refunds and disputes. Partial changes need their own amounts, quantities and timestamps.

Internally, preserve enough context to explain the transaction. Useful records include:

• Originating agent or platform identifier
• Campaign or channel identifier
• Checkout and order identifiers
• Authorization or mandate reference
• Tokenized payment reference
• Policy decisions and step-up results
• Event timestamps and state versions

This requires a reliable order management architecture, not another analytics tag.

Attribution and audit data also create privacy obligations. Define the purpose and lawful basis for each field. Consent is only one possible lawful basis and may not be appropriate in every case.

Apply data minimization, retention schedules and role-based access. Support valid access or deletion requests where the law requires them. Review cross-border transfers and avoid storing reusable payment credentials in analytics or order metadata.

Merchant-of-record status cannot be inferred from a protocol alone. Tax, support, refund, dispute and privacy duties depend on the contract, jurisdiction, payment model and sales channel. Review every integration with legal, tax, privacy and payments specialists.

A practical readiness test

Replace broad questions with repeatable acceptance tests. The thresholds below are examples. Adjust them to your products, risk level and service commitments.

Run these tests against normal purchases and difficult cases. Include low stock, concurrent checkouts, promotion expiry, partial capture, split shipment, cancellation and partial refund. Test webhook loss, duplicate callbacks, delayed payment confirmation and key rotation too.

Track checkout success rate, reservation failures, payment mismatches and event-reconciliation errors. An integration is not ready until failures are visible and recoverable.

Limitations

Protocol support alone does not establish discoverability, security, compliance or production readiness. Platform announcements may describe previews or restricted releases. Implemented capabilities can also differ between agents and markets.

Start by reviewing current specifications and platform eligibility. Then test the complete transaction lifecycle against your own systems.

If the results expose fragmented ownership or unreliable integrations, begin with a software architecture audit. Webalize's ecommerce development and consulting services can help assess Shopify, Shopware, ERP, PIM and payment integrations against these requirements.