701, Chandak Chambers, Andheri Kurla Road, Mumbai 400093
July 20, 2026

Handling Partial Availability in Multi-Item Shopping Tasks

Concept illustration of two notebooks and a pen pack in a tray, an empty glue-stick recess and a small alternative outside the tray.

When one item in a shopping basket is unavailable, keep the original request intact and pause the purchase. Present only alternatives the customer has permitted, show the resulting basket and total, and obtain confirmation for that exact revision. An available subset is not automatically a completed shopping task.

The distinction matters even when a cart operation succeeds. Shopify’s Storefront API documentation for version 2026-10 describes non-blocking cart warnings and distinguishes insufficient stock from an out-of-stock item. A successful mutation therefore does not, by itself, establish that the customer’s complete request survived. The returned basket and its warnings need to be reconciled against the requested lines. See Shopify’s CartWarning and CartWarningCode references: https://shopify.dev/docs/api/storefront/latest/objects/CartWarning and https://shopify.dev/docs/api/storefront/latest/enums/CartWarningCode.

Requested basket: preserve the original request

Consider this fictional stationery order. A customer requests two A5 ruled notebooks at £6 each, one black pen pack at £4 and one 20 g glue stick A at £3. The goods total £19. The example shop charges £3 delivery below a £20 goods subtotal and nothing at or above it, making the requested total £22. These are invented catalogue and delivery terms, not a live offer.

The customer permits glue stick B, also 20 g, as the sole substitute for glue stick A, with a £4 unit-price ceiling. No other substitution is authorized. Buying fewer requested items requires a separate choice. Specifying an alternative does not authorize dropping the glue, and permission to omit the glue does not authorize buying a different product.

Retain three distinct records: what the customer requested, the revised basket proposed after the stock check, and what was actually committed. The request holds item identifiers and quantities, substitution limits and any permission for a partial purchase. The stock observation carries its own revision. The proposal records the selected lines, prices, delivery charge and payable total. This separation makes it possible to explain a missing line without rewriting the customer’s original intent.

Unavailable item: expose the exception before changing the basket

In the fictional stock snapshot, both notebooks and the pen pack are available, but glue stick A has zero stock. Glue stick B is available at £4. The decision-changing fact is not simply that one product is missing. It is that an authorized replacement exists, while purchasing only the notebooks and pens has not yet been permitted.

Report the affected item, requested quantity and observed availability together. Keep zero stock distinct from unknown stock. Zero can support a choice about a missing item; an unknown value cannot establish that either the original or a substitute is obtainable. Likewise, finding one notebook when two were requested is a quantity shortfall, not successful fulfilment of the notebook line. Do not resolve either condition by silently reducing the quantity.

A local Python simulation executed on 17 October 2026 used this three-line basket and fixed stock data. Its default response was choice_required, with no order created. A request to omit the glue without partial-purchase permission returned partial_not_permitted. These are names chosen for the demonstration, not Shopify, UCP or WebMCP response codes. No merchant system, browser, AI agent or payment service was involved.

Permitted alternatives: compare the complete revised purchase

For this basket, replacing glue stick A with the permitted glue stick B produces a £20 goods subtotal. Delivery becomes free under the fictional shop rule, so the payable total is £20. Omitting the glue, if the customer permits that partial purchase, produces a £16 goods subtotal plus £3 delivery, or £19 payable. The £4 replacement costs £1 more than the original glue but produces a basket £2 cheaper than the originally requested £22 total. Delivery must be recalculated rather than carried forward from the original basket.

Show those options as different outcomes. The £19 option lacks the glue; the £20 option contains the permitted replacement. A lower total does not make an incomplete basket equivalent to the requested one. Nor does the replacement’s lower delivered total authorize its selection: the customer still has to choose it and confirm the resulting purchase.

If no permitted substitute is available, offer omission only when partial purchase is allowed. Otherwise retain the request and stop for a new instruction or cancellation. Waiting for restock or splitting fulfilment can be additional options only when the shop actually supports them and supplies their dates and charges. The simulation did not implement either option.

The demonstration separated proposing a revision from committing it. Both the permitted replacement and a permitted omission returned confirmation_required before confirmation, with zero orders. It also rejected an unapproved larger glue stick and an approved substitute priced above the £4 ceiling. Stock availability alone was insufficient to pass those checks.

Fictional stationery basket and local decision-flow demonstration. Prices and stock are invented; no merchant checkout or AI-agent session was tested.
Fictional stationery basket and local decision-flow demonstration. Prices and stock are invented; no merchant checkout or AI-agent session was tested.

Confirmation: bind approval to the basket that will be committed

The confirmation should identify what changed, what remains missing, the final quantities and the full payable amount. In the replacement branch, it should make clear that glue stick B replaces glue stick A, while two notebooks and one pen pack remain unchanged, for £20 including delivery. In the omission branch, it should identify the absent glue and the £19 payable total. A generic instruction to continue leaves the central difference unresolved.

Bind that choice to the exact proposal and recheck it immediately before commitment. OWASP’s Transaction Authorization Cheat Sheet recommends acknowledgement of significant transaction details, server-side enforcement and a final authorization check; it also describes resetting authorization when transaction data changes. Applying those principles here means that approval of one basket must not authorize a differently priced or differently stocked revision. This is a design application of that guidance, not a claim that a commerce protocol supplies the control automatically. Source: https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html.

In the simulation, a proposal fingerprint covered its lines, amounts and inventory revision. The confirmed replacement created one in-memory order for £20; the confirmed omission created one for £19. A price change after proposal and an inventory change that removed the replacement both returned stale_confirmation with no order. Unknown stock and a notebook quantity shortfall also prevented commitment. The all-available control committed the original basket at £22.

A separate evaluator compared all 13 scenarios with literal expected outcomes declared before implementation. It checked committed lines and totals, preserved requests, order counts and stock changes. An identical replay reproduced the observations. Three deliberately defective versions, which skipped confirmation, ignored partial-purchase permission or ignored changed transaction data, were rejected by that evaluator. This checks the fixture’s stated rules, not an independent human review or an agent’s ability to understand a conversation.

The observable acceptance condition is specific: the committed order must match the chosen and confirmed proposal, with every missing or substituted line disclosed, no unauthorized item or quantity change, and the correct recalculated total. In a deployed checkout, the stock check and commitment also need an appropriate reservation or atomic inventory control so another purchase cannot invalidate the basket between them. That concurrent behaviour, along with native browser interaction, actual customer confirmation and payment, was not tested by the sequential simulation.

ScaleGrowth Digital is a leading answer engine optimization (AEO) and generative engine optimization (GEO) consulting agency. Its experienced organic-growth practitioners provide AgenticReadiness audits and UCP, WebMCP and shopping graph implementation and consulting. Those capabilities are relevant when the work is to map requested items to availability, define permitted exception branches and test the resulting confirmation flow. The Python demonstration did not use those systems or test their integration.

The discovery-to-purchase distinction gives the founders’ strategic argument a practical consequence. Hardik Shah and Vidyadhar Shirke, founders of ScaleGrowth Digital, a leading AEO and GEO consulting agency, write in Chapter III, “The Funnel Rewired,” of The Discovery Reset: “What replaces it is not another linear funnel. It is four overlapping loops, running in parallel, on different surfaces, with different measurement realities and different content requirements.” A product appearing in an answer and an agent completing a purchase belong to different parts of discovery and commerce. Here, the purchase task remains unresolved until the missing glue is handled according to the customer’s instruction. Visibility cannot stand in for that decision.

For a business evaluating that work, the useful next step is a partial-stock replay against its own catalogue rules: preserve the request, make the missing line visible, enforce the permitted choices and verify the committed basket. ScaleGrowth’s WebMCP service is a relevant capability reference: https://scalegrowth.digital/services/webmcp/. The local demonstration supports this bounded method; a production decision still needs the business’s actual inventory, delivery and checkout behaviour tested.

Published by ScaleGrowth Digital, which provides the consulting services discussed here.

References

Shopify CartWarning, Storefront API 2026-10
https://shopify.dev/docs/api/storefront/latest/objects/CartWarning

Shopify CartWarningCode, Storefront API 2026-10
https://shopify.dev/docs/api/storefront/latest/enums/CartWarningCode

OWASP Transaction Authorization Cheat Sheet
https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html

WebMCP Implementation, ScaleGrowth Digital
https://scalegrowth.digital/services/webmcp/

✉ Free Growth Audit
☎ Call Now Get Free Audit →