ChatGPT Commerce does not replace a merchant's commerce stack. OpenAI's current model starts with structured product feeds, then connects commerce actions through Agentic Commerce Protocol flows and delegated payment, while merchants still own payment processing, order acceptance, fulfillment, refunds, chargebacks, compliance, and support.
That is the useful starting point because it keeps the conversation grounded. The interesting part is not "AI shopping" as a slogan. The interesting part is what developers have to expose, orchestrate, and govern so a new conversational channel can safely use existing commerce systems.
If you are the person who gets handed this project, the practical question is not whether ChatGPT can show products. OpenAI already documents how merchants can onboard catalog data and support checkout through ACP. The real question is whether your current architecture can support a new channel without coupling ChatGPT to storefront code, duplicating business logic, or creating payment and order-state inconsistencies.
What OpenAI actually documents
OpenAI's current commerce guidance describes three core building blocks for merchants that want to participate in this model.
First, merchants share a structured product feed so ChatGPT can index products, understand core attributes, and present accurate product information in shopping experiences. OpenAI recommends starting here, and states that product-feed onboarding in ChatGPT is currently available to approved partners.
Second, ChatGPT can call the merchant's ACP endpoints to create or update checkout sessions, securely pass buyer and fulfillment information, and receive an order state back after the merchant validates the transaction and decides whether to accept or decline it. OpenAI also states that the checkout UI is embedded in ChatGPT, while the actual checkout state and payment processing remain on the merchant's systems.
Third, OpenAI's Delegated Payment Spec allows OpenAI to securely share payment details with the merchant or its designated PSP. The merchant and PSP then process the payment in the same manner as any other digital transaction, and OpenAI explicitly states that it is not the merchant of record.
That is the factual platform model. Everything else in this article is implementation advice about how to build around that model cleanly.
What developers need to build
In practical terms, a merchant integration needs five working layers.
- A reliable product-feed pipeline.
- A channel-safe merchant edge for ACP requests.
- Access to core commerce services like pricing, promotions, inventory, tax, and shipping.
- Delegated payment integration with an existing PSP or vault.
- Post-order connectivity to OMS, fulfillment, returns, and support systems.
The reason this matters is simple: ChatGPT can become a new intent and checkout surface, but it still depends on the merchant's systems for the underlying transaction. If those systems are fragmented, inconsistent, or hidden behind storefront-specific logic, the ChatGPT channel will surface those weaknesses quickly.
That is why this should be treated as a systems integration project, not a chatbot feature.
Architecture view
The approved architecture for this piece breaks the implementation into five layers: ChatGPT Channel, Merchant Edge, Commerce Services, Payment Stack, and Order Operations. That is an architectural recommendation, not an OpenAI diagram, but it maps well to the documented responsibilities in OpenAI's commerce model. Copy and paste the following FlowZap Code into a Diagram in your FlowZap Account and start editing it to fit your use case!
merchantEdge { # Merchant Edge
n1: rectangle label="Publish product feed"
n2: rectangle label="Validate feed"
n3: rectangle label="Expose ACP endpoints"
n4: rectangle label="Create checkout session"
n5: diamond label="Approve order?"
n6: rectangle label="Return order outcome"
n1.handle(right) -> n2.handle(left)
n2.handle(right) -> n3.handle(left)
n3.handle(right) -> n4.handle(left)
n4.handle(right) -> n5.handle(left)
n5.handle(right) -> n6.handle(left) [label="Yes"]
n2.handle(bottom) -> commerce.n7.handle(top) [label="Refresh catalog state"]
n4.handle(bottom) -> payment.n11.handle(top) [label="Delegated payment request"]
n6.handle(bottom) -> operations.n14.handle(top) [label="Create order event"]
n6.handle(top) -> chatgpt.n20.handle(bottom) [label="Order outcome"]
}
commerce { # Commerce Services
n7: rectangle label="Resolve content"
n8: rectangle label="Resolve price promo"
n9: rectangle label="Resolve inventory"
n10: rectangle label="Resolve tax shipping"
n7.handle(right) -> n8.handle(left)
n8.handle(right) -> n9.handle(left)
n9.handle(right) -> n10.handle(left)
n10.handle(top) -> merchantEdge.n4.handle(bottom) [label="Checkout data"]
}
payment { # Payment Stack
n11: rectangle label="Tokenize payment"
n12: rectangle label="Authorize payment"
n13: rectangle label="Return auth status"
n11.handle(right) -> n12.handle(left)
n12.handle(right) -> n13.handle(left)
n13.handle(top) -> merchantEdge.n5.handle(bottom) [label="Approved or declined"]
}
operations { # Order Operations
n14: rectangle label="Create OMS order"
n15: rectangle label="Reserve inventory"
n16: rectangle label="Trigger fulfillment"
n17: rectangle label="Handle returns support"
n14.handle(right) -> n15.handle(left)
n15.handle(right) -> n16.handle(left)
n16.handle(right) -> n17.handle(left)
n17.handle(top) -> chatgpt.n21.handle(bottom) [label="Service and support"]
}
chatgpt { # ChatGPT Channel
n18: circle label="Shopper intent"
n19: rectangle label="Display products"
n20: rectangle label="Show confirmation"
n21: circle label="Support entry"
n18.handle(right) -> n19.handle(left)
n19.handle(right) -> n20.handle(left)
n20.handle(right) -> n21.handle(left)
n18.handle(left) -> merchantEdge.n3.handle(right) [label="Discovery request"]
n19.handle(left) -> merchantEdge.n4.handle(right) [label="Session request"]
n20.handle(left) -> merchantEdge.n5.handle(right) [label="Purchase approval"]
}
Start with the feed
OpenAI's recommended integration path begins with the product feed, and that is the right starting point for engineering as well. The feed is what gives ChatGPT the catalog data it needs to understand titles, descriptions, images, price, availability, and other core product attributes.
The guidance is specific enough to turn into a real delivery plan. OpenAI recommends either file upload or API, generally suggests sending the entire feed once a day through file upload and using the API for updates during the day, and notes that promotions data can only be provided through the API. It also requires validation of required fields and regular refreshes of the data.
For developers, that translates into concrete work:
- Identify the system of record for each feed field.
- Map the internal product model to the documented schema.
- Validate required fields on every record.
- Publish a daily snapshot.
- Push intra-day changes for price, availability, and promotions.
- Monitor feed freshness and schema failures.
This is not glamorous work, but it is foundational. A storefront can hide poor catalog structure with templates, navigation, and merchandising logic. A machine-readable feed cannot.
Build a merchant edge
OpenAI documents the flow at the protocol level, but it does not require merchants to expose those capabilities through storefront controllers or page-specific APIs. That is where architecture judgment matters.
The cleanest implementation is usually to build a merchant edge: a gateway or orchestration layer that accepts ChatGPT-originated requests and coordinates the underlying commerce services. That layer should expose channel-safe endpoints for discovery, checkout-session creation, checkout updates, payment completion, and post-order service lookups.
A merchant edge should do four things well:
- Translate ChatGPT requests into internal service calls.
- Normalize downstream responses into channel-ready data.
- Apply policy, observability, idempotency, and tracing.
- Keep the channel decoupled from storefront-specific behavior.
That last point is important. If the ChatGPT channel depends on session cookies, page rendering logic, or storefront controllers, the integration becomes fragile. The better pattern is for ChatGPT to consume commerce capabilities, not storefront implementation details.
A practical capability surface might include functions like:
searchProducts(query, locale, filters)getProduct(productId)createCheckoutSession(items, buyerContext)updateCheckoutSession(sessionId, shippingAddress, deliveryChoice, promoCode)completeCheckout(sessionId, delegatedPaymentToken)getOrderStatus(orderId)getReturnEligibility(orderId, itemIds)openSupportCase(orderId, reason)
Those endpoint names are architectural examples, not part of OpenAI's published spec. The point is that the merchant edge should orchestrate business capabilities rather than reuse storefront APIs.
Keep truth in the source systems
A common failure mode in integration projects is turning middleware into an accidental second source of truth. This channel should avoid that.
The merchant edge should orchestrate, not own reality. Product truth should stay with the catalog or PIM. Pricing truth should stay with pricing and promotions services. Inventory truth should stay with inventory or ATP services. Tax and shipping truth should stay with the corresponding calculators. Order truth should stay with OMS. Payment truth should stay with the PSP and the merchant's payment systems.
That design keeps reconciliation manageable and makes the new channel much easier to operate.
How delegated payment actually works
OpenAI's Delegated Payment Spec is specific enough that developers can reason about the flow without guessing.
According to the spec, the buyer checks out using a preferred payment method saved in ChatGPT. OpenAI then sends a delegated payment payload directly to the merchant's PSP or vault. The delegated payment is single-use and constrained by allowances such as max amount, currency, checkout session ID, merchant ID, and expiry. The PSP or vault returns a payment token scoped to that delegated payment, and OpenAI forwards the token during the complete-checkout call so the merchant can complete the transaction.
OpenAI also states several important constraints. OpenAI is not the merchant of record. Merchants are expected to bring their own PSP and process payments as they would for any other digital transaction. Settlement, refunds, chargebacks, and compliance remain with the merchant and its PSP. Direct integration with the Delegated Payment Spec is intended for PSPs or PCI DSS Level 1 merchants using their own vaults, while other merchants may use a compatible PSP implementation such as Stripe's Shared Payment Token path.
From an implementation standpoint, the takeaway is straightforward: do not redesign payments. Integrate the delegated token flow into the merchant's existing PSP path, preserve idempotency and traceability, and create the order only after merchant-side authorization and policy checks succeed.
A practical runtime sequence
Once the feed exists and the merchant edge is in place, the end-to-end runtime becomes easier to reason about.
- The shopper expresses intent in ChatGPT.
- ChatGPT requests product data through the merchant edge.
- The merchant edge queries catalog, pricing, and inventory services and returns normalized results.
- ChatGPT initiates or updates a checkout session through ACP-compatible endpoints.
- The merchant edge resolves shipping, tax, promotions, and final totals from authoritative services.
- OpenAI triggers delegated payment through the PSP or vault flow.
- The merchant receives the delegated payment token and completes authorization on its own systems.
- The merchant accepts or declines the order and returns that state to ChatGPT.
- If approved, the merchant creates the OMS order, reserves inventory, and triggers downstream fulfillment.
- Post-order service continues through the merchant's own operational systems.
This sequence is not copied from a single OpenAI page. It is a practical synthesis of the documented feed, checkout, and payment flows into an implementable merchant architecture.
What usually breaks first
The weak points in this architecture are usually not surprising.
- Feed data drifts from real inventory.
- Promotions are resolved differently in different services.
- Shipping and tax totals change between steps.
- PSP token flows hit edge cases around retries or expiry.
- Fraud and risk logic were not designed with this channel in mind.
- OMS or support systems are not integrated early enough.
OpenAI's own guidance already hints at one of the big fixes: use daily snapshots plus API updates rather than relying on a static once-a-day feed if the underlying commerce state changes more frequently. Promotions are also explicitly API-driven, which means the merchant needs a robust update path beyond static file delivery.
The rest comes down to familiar engineering discipline: one authoritative checkout calculation path, clear service ownership, idempotent writes, and observability on every critical transition.
A realistic phased rollout
The safest rollout is narrow.
OpenAI notes that product-feed onboarding in ChatGPT is currently available to approved partners, and that Instant Checkout in ChatGPT is currently available to approved partners as well. That means the first phase is not full production rollout. It is readiness, access, and scope control.
A practical phased plan looks like this:
Phase 0: readiness
- Confirm partner access path.
- Write a short architecture note.
- Identify source systems and owners.
- Review prohibited-products policy and compliance ownership.
Phase 1: catalog readiness
- Map feed fields.
- Validate required fields.
- Generate and submit an initial sample.
- Publish daily snapshots.
- Add intra-day API updates for changing data.
Phase 2: transaction orchestration
- Build merchant-edge endpoints.
- Connect pricing, inventory, tax, shipping, and promotions services.
- Integrate delegated payment with the PSP path.
- Return merchant-owned order decisions and confirmation states.
Phase 3: post-order operations
- Connect OMS events.
- Add order status lookups.
- Add cancellation and return eligibility logic.
- Route support through the merchant's service stack.
This phased plan is not mandated by OpenAI, but it fits the documented platform model and reduces risk by avoiding a "connect everything at once" rollout.
What to tell leadership
Leadership teams may hear "ChatGPT Commerce" and assume this is a chatbot add-on or a thin UI integration. The more accurate description is different.
This is a new channel that uses the merchant's existing commerce capabilities through structured feeds, ACP-based checkout flows, and delegated payment, while the merchant retains responsibility for payment, order acceptance, fulfillment, compliance, and customer support.
That framing is useful because it keeps the conversation honest. The opportunity is real, but so is the implementation work.
Final point
The most useful way to think about ChatGPT Commerce is not as a replacement for the commerce stack, but as a new intent channel that demands cleaner exposure of the stack the merchant already has. OpenAI's documentation is explicit about merchant ownership of product quality, payment processing, order acceptance, and operational follow-through.
The originality in implementation does not come from inventing new facts about the platform. It comes from building the merchant edge well, keeping business truth in the right systems, and rolling out the channel in a narrow, observable, supportable way.
Inspirations
- OpenAI Commerce: Get Started
- OpenAI Commerce: Payment Spec
- OpenAI Commerce: Key Concepts
- Stripe and OpenAI Instant Checkout
- Worldpay ACP Documentation
- Marketing Interactive: OpenAI Commerce Steps
- Agentic Commerce Protocol: Feed Spec
- OpenAI: Buy it in ChatGPT
- TechInformed: OpenAI Refocuses on Discovery
- JD Supra: Gatekeepers of Agentic Commerce
- NCFA Canada: PayPal and OpenAI Partnership
- FBT Gibbons: Gatekeepers of Agentic Commerce
- Brenden: Feed Product Catalog to AI
- Chip Rodgers on OpenAI Partnership
- Checkout.com: OpenAI Agentic Commerce Shift