What changed since the 2025 launch
OpenAI’s September 2025 launch post introduced Instant Checkout and the Agentic Commerce Protocol. It described the merchant as responsible for order acceptance, fulfillment, returns, and support.
That responsibility remains important, but the product direction has changed. OpenAI’s March 2026 product discovery update says the first Instant Checkout version did not offer the flexibility it wanted. OpenAI is allowing merchants to use their own checkout experiences while concentrating on discovery: helping a buyer explore, compare, and refine products.
| Layer | What success looks like | What it cannot prove |
|---|---|---|
| Discovery | The right product is represented clearly | Live stock, a completed payment, or delivery |
| Checkout | The buyer reaches the merchant’s current purchase flow | That every product or customer has the same route |
| Support | The buyer gets a verified answer or a clean handoff | A personal order decision without the authorized record |
OpenAI’s shopping guidance says results are selected independently, not sold as ads or partnership placement. It also warns that price and shipping information can take time to refresh. The merchant’s current checkout and order systems remain the final source for a buyer.
The Shopify merchant job now
OpenAI says Shopify Catalog is already integrated into ChatGPT for product discovery. Individual Shopify merchants do not need extra work simply to get that catalog representation. The merchant should instead audit the records that influence what a buyer sees and does next.
- Check the product data shoppers use to compare options: names, images, descriptions, price context, and variants.
- Test the real merchant checkout for priority products, destination and discount cases.
- Publish clear shipping, return, and exchange policies.
- Put the order-support route in front of the support team before the campaign brings new questions.
Use a real Shopify connection for live facts
The official eesel Shopify integration guide describes two different modes. Quick start crawls the public storefront. It can learn the products, collections, pages, blog, and policies a shopper can read, but it has no Shopify Admin API access and cannot look up an order, customer, or live product data.
Connect Shopify is the full Shopify-admin authorization. It syncs products, pages, blog articles, and policies. More importantly for support, it adds live Shopify lookups: orders, order history, fulfillment, customers, products, and exact product variants. The live Get Product Variants action can retrieve size, color, SKU, price, and inventory for a product. That is the appropriate tool for “does the blue medium exist?” when the action is enabled and the store has authorized access.
Sources are a sync; lookup actions are live. Re-sync sources after a catalog or policy change. Use live lookup for the order or variant in front of the customer. Do not describe the synced catalog as a guaranteed live-inventory feed.
Shopify supplies no trigger. A customer conversation must arrive through the storefront chat widget or a helpdesk such as Gorgias or Zendesk. The helpdesk or chat provides the conversation; Shopify provides the product, customer, and order facts. This is why a connected Shopify store does not automatically make an agent act.
Keep order changes under explicit control
Full Shopify authorization can expose actions including creating a return, creating a draft order, refunding an order, and cancelling an unfulfilled order. Each can be set to run on its own, ask for approval, or remain off. The safe starting point is read-only lookup, then an approval-gated action once the team has watched real cases.
| Customer question | Appropriate first move |
|---|---|
| “What is your return window?” | Answer from the current policy |
| “Where is my parcel?” | Get the authorized order and fulfillment record |
| “Is blue medium available?” | Live variant lookup, not a general product description |
| “Refund order 1048 now” | Check permissions and hold for approval |
| “Cancel my order” | Verify it is unfulfilled, then use the approved action path |
Order search has a Shopify limit: it only searches the last 60 days unless the app has the read-all-orders scope, which eesel does not request. Direct lookup by order number can still work for an older order. This is a useful boundary test, not an edge case to hide.
Test each part of the buyer journey
Use separate ordinary and boundary tests to check the observed behavior: whether a policy answer is sourced, a live variant lookup returns the requested option, and an order-status answer includes the correct tracking data. Boundary cases check whether an older order is looked up directly rather than treated as missing from search, an unauthorized refund is not executed, and Quick start does not pretend it can see a customer's order.
Use owner-approved test records and review the cost first. Disable production order-changing actions; any approval-path test should use a controlled non-production setup. Run the tests in sequence:
- Inspect the customer channel, connected Shopify mode, instructions, activity, approval settings, and production permissions.
- Confirm the owner-approved instruction for order status, returns, refunds, and cancellations.
- Test ordinary cases in the real customer channel.
- Test the boundaries: unavailable access, an older order, and a requested refund or cancellation.
- Inspect the resulting ticket, lookup, approval, or handoff, then adjust the rule only with owner approval.
The acceptance condition is not a polished terminal response. It is a customer seeing the right next step and the store team receiving enough context to verify or approve the decision.
Review shopping support routing with eesel CLI
The eesel CLI operates the same workspace and teammate as the dashboard. A support owner, a script, or Claude Code, Codex, or Cursor can use it; commands return JSON. Node.js 18.17 or newer is required. Use the documented npx form rather than assuming a global installation.
npx @eesel/cli status --agent "Shopping support"
npx @eesel/cli integrations --agent "Shopping support"
npx @eesel/cli instructions --agent "Shopping support"
npx @eesel/cli activity --agent "Shopping support"
npx @eesel/cli billing --agent "Shopping support"
npx @eesel/cli approvals --agent "Shopping support"
This is the actual job: make policy answers, live lookups, and approval-gated actions behave as distinct paths. First inspect the relevant knowledge and Shopify connection. Before any live test, check billing because CLI chat is billed work, and check production permissions because a refund or cancellation can change a customer order.
For an older-order workflow, ask Claude Code to inspect the current rule: “Does an empty order search make this teammate tell the customer there is no purchase, or does it use the documented direct lookup when an order number is available?” Compare the JSON configuration with the source and enabled lookup actions. This makes a specific support mistake reviewable before a customer encounters it.
Have the owner prepare a narrow instruction change. Run npx @eesel/cli instructions --help to find the supported edit syntax, preview the exact write with --dry-run, approve and apply it, then read the instructions back. The rule should distinguish a failed search from proof that no order exists and retain the store's customer-verification requirements.
After approving test cost and permissions, use new for each independent conversation and chat for the question. First supply an owner-approved older-order fixture and its order number: ask for the documented lookup and next step. Then ask for someone else's older order using only their email and demand an immediate refund. Check that the first case uses the right evidence and the second follows the store's verification and permission rules, without exposing another customer's details or changing an order.
Inspect activity, compare the response with the fixture, and repeat the cases in the actual helpdesk or storefront chat. A good terminal response does not prove the customer received a reply or that the handoff arrived. Try eesel to maintain that routing rule from the same dashboard and CLI workspace.
Frequently Asked Questions
What was the ChatGPT shopping integration in 2025?
OpenAI introduced Instant Checkout in September 2025 as an early agentic-commerce step. The current direction emphasizes product discovery and merchant checkout choices; the old launch announcement is not a universal setup guide.
What changed after the 2025 ChatGPT shopping integration?
OpenAI says the initial Instant Checkout version lacked the flexibility it wanted. It now lets merchants use their own checkout experiences while it focuses on richer product discovery.
Does ChatGPT shopping replace a merchant website?
No. ChatGPT can help a buyer explore products, but the merchant controls the store, checkout, order acceptance, fulfillment, returns, and support. A ChatGPT checkout guide explains the distinction.
Can merchants assume every customer can use Instant Checkout?
No. OpenAI says Instant Checkout can appear for eligible merchants and products. Test the buyer path for the actual item and location rather than relying on a broad claim.
Who handles delivery and refund questions after ChatGPT shopping?
The merchant does. Use the authorized order, fulfillment, carrier, or refund record, or route the buyer to the team with access to it. See the Shopify chatbot guide.
Can eesel look up Shopify orders and variants?
With full Connect Shopify authorization, eesel can look up orders, fulfillment, customers, products, and live variants. Quick start only crawls public storefront content. See the Shopify support guide.
