A Discovered Product Is Not a Current Offer

OpenAI withdrew in-chat checkout and handed the transaction back to merchants. Read as conversion math, that is a fix. Read as a boundary, it is an admission — because the state that governs an execution was never held in one system to begin with.

What changed

Instant Checkout arrived inside ChatGPT in September 2025, with Etsy among the first merchants to adopt it. Within six months it was being withdrawn. By March 2026 the role had been redefined: discovery stays in the conversation, while control of checkout, payment, and fulfilment moves back to the merchant. Discovery itself was not abandoned — it was strengthened. What was withdrawn was the idea that the transaction completes inside the assistant.

The clearest evidence came from Walmart, which made roughly 200,000 products available through Instant Checkout from November 2025. At a March 2026 investor conference the company disclosed that purchases completed inside ChatGPT converted at about one-third the rate of shoppers sent to walmart.com, and that it was moving away from the arrangement.

The conversion result is unambiguous. What it does not establish is that the failure was one of demand. The channel could form intent. What it could not do was reproduce the environment an order requires.

That environment was reported as missing in specific pieces. Purchases were made one item at a time rather than consolidated with the shopper’s existing basket, raising the prospect of a fragmented checkout and several separate deliveries. Loyalty programmes were not connected, so members could not apply their benefits. Coupons, promotions, and store pickup were absent. In the United States, tax collection infrastructure had not been built. Merchant adoption stayed narrow — by early 2026 only around thirty Shopify merchants had fully integrated.

And separately from all of that: the product information shown was not always current. Descriptions could be inaccurate, prices were not always synchronised, and inventory data could lag actual availability.

The remedial work now under way is the tell. Real-time inventory and pricing integration is being strengthened, while the transaction itself has been handed back to merchants.

The usual reading

Two readings dominate, and both are defensible.

The first is conversion math. Shoppers abandoned in-chat checkout at three times the rate, so the feature failed on its own metric and was withdrawn. Nothing philosophical about it.

The second is trust. Consumers were willing to delegate discovery, comparison, and advice, but wanted the last step on a surface they knew — with their saved payment method, their order history, their loyalty balance, and a merchant who would answer for the order. Merchants, for their part, had no interest in surrendering the cross-sell, the account relationship, or the returns desk.

Both are true. Neither asks what the fix implies about where the boundary was.

What the fix actually did

The industry’s solution was to move the transaction closer to the systems that hold the merchant-controlled parts of the current state.

That phrasing is deliberate, because the imprecise version — move it to where the state lives — hides the more interesting problem.

Look again at the list of what was missing. A unified cart is held by the merchant’s order system. Loyalty and benefit state is held by a membership system. Coupons and promotions are governed by pricing and campaign policy. Store pickup depends on local inventory and fulfilment. Tax treatment is determined by jurisdiction and tax rules. The right to use the payment instrument, and the limits on it, sit with the issuer or the payment provider. The shopper’s current authority sits with whatever holds the session or the mandate.

What was missing was not one merchant database. It was a transaction environment: a unified cart, loyalty and promotion state, local fulfilment, tax treatment, payment authority, and the merchant’s current ability to accept this order.

None of those is a feature gap in the ordinary sense. Each is a different authoritative source holding a different piece of the state that governs whether an order can be placed. A price and a stock count can be perfectly current while the card is suspended, the session has been taken over, the spending limit has changed, or the item has become unsellable in that region.

So relocating checkout narrowed the mismatch — the product-and-order part of it. It did not resolve execution eligibility, because eligibility was never a single lookup. It is several current states, held by different systems, that have to be brought together and bound to one specific act.

Discovery evidence is not execution evidence

The distinction the rollback exposes is between two different kinds of evidence about the same product.

Discovery evidence is what the assistant had: this product existed, at this price, with this description, when the catalogue was last synchronised. That is enough to recommend. Product feeds are supplied by merchants and refreshed on a cycle; a cycle is not a guarantee.

Execution evidence is what an order requires: this SKU, from this seller, in this channel, at this price, with this stock, under these delivery and return terms, right now — and within what the shopper actually approved.

The gap between them is not only freshness. A listing can be live while the item is not orderable: stock at zero behind a cached page, a region the seller cannot ship to, a displayed price that the checkout quote does not honour, a marketplace listing whose seller has been suspended, a last unit lost to someone else’s reservation. What execution needs is not the existence of a product but a current executable offer — confirmation that this object can actually be ordered now, on these terms, by this buyer.

These are not the same fact at two levels of detail. They are answers to different questions, taken at different moments, and the second cannot be inferred from the first. A recommendation is a snapshot. An order is an execution.

The channel is part of the identity

A second gap is easy to miss because the product name does not change.

The same item, from the same merchant, can carry different conditions on the merchant’s own store, on each marketplace it lists through, and on each assistant surface that surfaces it. Price, coupon, stock allocation, shipping cost, delivery date, return window, points, regional restriction, available payment methods — any of these can differ by channel.

So a product discovered on one surface does not carry its terms to another. The price seen during discovery does not qualify an order placed elsewhere. And identifying “the same product” by name is not identification at all: merchant, channel, product, SKU, variant, quantity, currency, seller, and fulfilment method are what fix a transaction to a single object. Two listings called the same thing can be different sellers, different conditions, different goods.

Discovery-channel information cannot establish execution-channel eligibility.

What to re-check, and where

It is tempting to say the fix is to check the product page. That is close but imprecise, and the imprecision matters.

The page is a representation for a human reader. What has to be re-checked at the moment execution opens is the current authoritative source for each execution dependency, in the channel where the order will actually be placed.

For the object and its terms, the strongest evidence is the authoritative transactional interface for that channel — a live checkout quote, a reservation response, an order API that will answer whether this can be placed now. Underlying inventory, pricing, and fulfilment systems come next, where direct and consistent access exists. The published page is weaker. A rendered screen is a last resort.

The ordering is not arbitrary, and it is not simply “backend first.” Seeing a quantity in an inventory record does not establish that the order can be placed: reservations, concurrency, regional allocation, minimum-order rules, and holds all sit between a stock count and an executable offer. A transactional quote already carries those. A count does not.

And for the dependencies the merchant does not hold — payment authority, session authority, limits, tax treatment, policy — the relevant source is elsewhere entirely. Reading a cached page and calling it verification produces evidence that looks current and is not; reading only the merchant produces evidence that is current and incomplete.

Evidence has a lifetime

There is a failure that survives every one of the fixes above, and it is the one most easily overlooked: a check that was correct when it ran, reused after it stopped being true.

The world can change between approval and execution.

Consider an ordinary sequence. Price and stock confirmed at 10:01. Shopper approves at 10:02. Order submitted at 10:07. Nothing in that sequence is negligent, and the confirmation was accurate when it was taken. But the order executes against a state verified six minutes earlier, and six minutes is long enough for a price to move, a promotion to expire, or the last unit to sell.

A verification is bound to the moment it was taken. Treating it as a standing fact is the same error the series has described elsewhere in other domains: a conclusion outliving the conditions that justified it. If the check is old enough that the state may have moved, it is not a check — it is a record of a check.

None of which means that any change stops the order. Re-qualification does not require interrupting every fluctuation. Whether a change remains inside what was actually authorised is a separate question, and it is addressed elsewhere in this series.

The propositions

Three statements, each of which the rollback demonstrates:

A discovered product is not a current offer. The catalogue said so once; catalogues lag. More strictly: what execution needs is a current executable offer, and a live listing is not that.

A current offer is not an authorised purchase. The terms may be live and still outside what the shopper agreed to.

An authorised purchase is not yet an eligible transaction. Authorisation was given under conditions. Whether those conditions still hold is a separate question, answered later, at the point the order is submitted.

Why a protocol does not close this

Standards for agent-to-merchant transactions are being assembled now, and they matter. Protocols such as the Agentic Commerce Protocol define how a transaction is expressed, routed, and settled between assistants, merchants, and payment systems, and the discovery integrations now replacing Instant Checkout run on exactly that kind of rail.

A protocol can carry a great deal that a determination needs: the facts, the mandate, the proof that a shopper authorised something. Treating it as a dumb pipe understates it.

What conformance does not do is establish that a specific execution is still eligible. A well-formed, correctly routed, properly authorised transaction can still be one whose conditions have moved. And the determination does not live at one point in the protocol — it attaches to each consequential action it qualifies. Before the order is submitted. Before payment is authorised. Before it is captured. Before goods are released. Each of those is its own act, and eligibility is a question asked of the act, not of the channel it travelled through.

What cannot be carried forward

ChatGPT became the place where purchase intent is formed. It has not become the place where transaction authority is trusted — and the gap between those two facts is not a trust deficit to be marketed away. It is a boundary that was never built.

What the withdrawal showed is that the surface holding the decision was not holding the state. Moving checkout to the merchant narrowed the gap by relocating part of it — the part the merchant controls. The rest of it did not move, and was never in one place to begin with.

Which leaves the question the field still has to answer. Not which screen should the payment happen on, but: who holds each piece of the current state, and what is the determination bound to? What this item is, in this channel, at this price, with this availability, under these terms, with this payment authority, inside what was actually approved — established at the moment execution opens rather than recalled from when the conversation began.

A snapshot is what made the recommendation possible. It is not what makes the order eligible. Answering that difference is not interface design. It is execution governance.