How Merchants Can Prepare for Agentic Commerce

What is agentic commerce readiness? Get your product data, policies, checkout and payments ready so AI agents can find, trust and buy from your store.

To prepare for agentic commerce, make your catalogue accurate, publish readable store policies and connect a supported checkout that respects the customer’s authorisation. Start with the information your store already owns. An agent that finds a product still needs the correct variant, delivered price and permission to pay.

For ecommerce managers and store owners, the practical goal is a purchase that reaches your order system with the agreed details. You’ll need access to your catalogue exports, website settings and payment provider’s test environment. Assign an ecommerce lead to coordinate the work before adding a new feed or checkout integration.

What Agentic Commerce Readiness Means

Agentic commerce readiness is the state where AI agents can read your products, trust your policies and complete an authorised purchase without errors. Readiness applies to the full purchase, from finding the item to receiving an order confirmation.

Classic search engine optimisation (SEO) helps people find your pages through search engines. AI website readiness also requires an agent to load those pages, read price and stock information and reach the policies. Search visibility alone doesn’t establish that the agent can buy the item.

Inspect a product page without JavaScript as a diagnostic check. If price or stock disappears, give agents a supported product feed or readable page output. Review bot protection separately: a blocked agent needs an approved access path, while unrelated security controls can stay in place.

If you need the broader explanation first, read how agentic commerce works. The preparation work here starts with your own catalogue and purchase flow.

Clean, Complete Product Data

Audit a sample of 50 products before expanding the catalogue to another channel. Include popular items, discounted products, variants and products that are out of stock. Count each failed check and give the catalogue owner a correction list.

Check the following information for every sampled item.

  • Match the Global Trade Item Number (GTIN) to the specific product where a manufacturer has assigned one. Keep unassigned identifiers empty instead of inventing them.
  • Record attributes shoppers use to choose, such as size, colour, material, dimensions and compatibility. Each purchasable variant needs its own identity and stock status.
  • Compare availability with the stock source and storefront. A parent product showing stock doesn’t prove the requested size is available.
  • Match prices across the feed, product page and checkout. For Australian offers, show Australian dollars and include goods and services tax (GST) where applicable.
  • State dispatch time and estimated delivery time separately. Check which destinations and delivery methods each estimate covers.

Google Merchant Centre’s product specification requires price and availability to match the landing page and checkout. Its price rules include GST for Australian offers. Use Google’s product data specification for the channel’s exact requirements.

For a hypothetical shoe store, a black size 10 and a black size 11 are separate purchasable variants. If size 10 sells out, the feed must update that selection even when size 11 remains available. Fix the source record first, then regenerate affected feeds.

Use the AI-ready product data guide for field-by-field preparation.

Clear Policies Agents Can Read

Publish shipping, returns and warranty terms as plain text on public pages, so agents and customers read the same rules. Keep a stable link to each policy from the storefront and supply those URLs wherever an integration requests them.

Shipping terms need delivery areas, charges, dispatch timing and exceptions for bulky or restricted goods. For returns, distinguish change-of-mind conditions from remedies for faulty products. Warranty copy must explain the coverage and claims process without treating a store warranty as the customer’s only protection.

Try a concrete question against each policy. For example, can a customer return an opened item because they changed their mind? If the answer requires staff to interpret an image or resolve conflicting paragraphs, rewrite the policy’s explanation.

The customer service lead must approve the same policy text used on the page and supplied to an agent. When a rule changes, update both places together. Check the answer again using a product affected by the change.

Feeds and Protocols to Support

Choose your first feed or protocol by the channel you can use and the job it performs. Product feeds support discovery. Checkout protocols carry a proposed purchase through to an order. One doesn’t replace the other.

Feed or protocolWhat to prepareWhen to choose it first
Google Merchant CentreValid product records, price and stock updates, shipping settings and policy informationYour store already uses Google Shopping or free listings and can correct an existing feed
ChatGPT product feedA supported feed format, stable item identities and publicly accessible product and image URLsYour store has a supported OpenAI feed integration and wants product discovery in ChatGPT
Universal Commerce Protocol (UCP)Supported checkout capabilities, delivery handling and compatible payment handlersYour commerce platform or selected channel provides a UCP integration
Agentic Commerce Protocol (ACP)Agent-facing checkout operations and a compatible payment providerYour selected agent channel and commerce integration support ACP

OpenAI’s stable feed specification separates discovery from checkout. Its basic discovery record requires an item ID, title, description, product URL, brand, seller name, image URL, availability and price. Checkout needs a separately enabled integration. Follow the ChatGPT product feed guide for setup rather than treating an accepted file as permission to transact.

The UCP checkout specification defines creating, updating and completing checkout sessions, among other operations. ACP’s official site describes checkout through compatible payment providers and says platform participation has its own process. Supporting a protocol doesn’t automatically list your products on every AI platform.

Begin with an existing feed you can maintain reliably. Add a checkout protocol when a supported channel requires it and someone owns failed orders, refunds and integration updates.

Checkout and Payments for Agents

An agent checkout proposal must show the selected items, quantities, delivery and final payable total before payment is authorised. The store must recalculate that proposal when stock, address or price changes. An expired or altered proposal needs fresh approval under the chosen checkout flow.

Agent payment flows can use a payment token passed through a compatible provider, instead of exposing the customer’s underlying card details to the agent. Agent Payments Protocol (AP2) adds signed evidence of authorisation. In UCP’s AP2 extension, the merchant signs checkout terms and the platform supplies proof that the customer authorised the purchase.

UCP requires manual completion through a trusted interface unless its AP2 Mandates extension is supported. Read the AP2 guide for the authorisation mechanism. The preparation task is to connect a payment flow your platform and provider both support.

Ask your payment provider to confirm the following implementation details.

  • The agent channels and checkout protocols supported for your Australian merchant account.
  • Accepted token or wallet methods and the point where customer authentication occurs.
  • The response to declined payments, expired proposals and repeated completion requests.
  • Records of customer authorisation and the process for refunds and disputed transactions in your order system.

Remove prohibited card surcharges from every checkout path, including agent proposals. The Reserve Bank of Australia (RBA) explains that eftpos, Mastercard and Visa have introduced no-surcharge rules, subject to applicable exceptions. Merchant card acceptance costs still exist. The RBA’s surcharge guidance explains the scope and commencement details.

Test in your provider’s sandbox before enabling purchases. An approved purchase must create one order with the agreed total. A decline must leave the purchase unpaid, and a repeated completion request must not create a second order or charge.

A 90-Day Readiness Plan

Use the first month to correct information, the second to connect one channel and the third to verify purchases and ongoing maintenance. The ecommerce lead owns the plan. Each task below has an owner and a result to inspect before expanding access.

  1. During the first month, the catalogue manager audits 50 products and corrects identifiers, attributes, stock, GST-inclusive prices and delivery information. Recheck the same sample after the next feed update.
  2. The customer service lead publishes readable policies during the first month. Confirm that product-specific questions produce the same answer for staff, customers and the connected agent.
  3. In the second month, the ecommerce manager connects one supported feed or repairs the existing one. Inspect rejected records and confirm that each accepted variant points to the correct product page.
  4. The technical lead and finance owner use the second month to select a supported checkout and payment flow. Document customer approval, token handling and the provider’s refund process before testing orders.
  5. During the third month, the technical lead runs sandbox purchases for an available variant, a sold-out variant and a changed delivery address. Test a declined payment and a repeated completion request too.
  6. The ecommerce lead approves the first channel only when the agreed variant and total match the resulting order. Assign the catalogue manager ongoing update checks and the customer service lead policy changes.

If an agent quotes the wrong price, compare the source record, feed update and checkout calculation to locate the mismatch. If it recommends a sold-out variant, inspect that variant’s stock mapping. A failed payment needs the provider’s error response and the checkout’s authorisation record, not a rewritten product description.

Your final readiness check is one complete sandbox purchase with a matching order record, followed by the failure cases above. Keep the results with the responsible owners so the next catalogue or policy change has a clear verification path.