Executive summary
- What: POS UI extensions running API version 2026-10 now reject cart mutations when Shopify POS does not confirm that the cart actually changed, instead of resolving either way.
- Why: A dropped cart write used to pass unnoticed, so an extension could show a discount or fee as applied when the cart never received it.
- Who: Teams running custom POS extensions that call cart mutations. Extensions pinned to 2026-07 or earlier keep the old behaviour for now.
What changed
Shopify POS has always reported the outcome of a cart write. Until this release, the extension API ignored that outcome: the mutation resolved whether or not POS applied the change. On API version 2026-10, fifteen cart mutations reject unless POS confirms the write, including bulkCartUpdate, applyCartDiscount, addCartCodeDiscount, setLineItemDiscount, setCustomer, and the line item property and selling plan operations. updateLineItemQuantity is new in 2026-10 and rejects from its first release.
Two rejection messages describe an unconfirmed write. "POS refused the cart update. The cart was not changed." means POS declined the write and cart state is intact, which commonly happens once a cashier has moved through to payment. Retrying can succeed when cart editing is available again. "POS could not confirm the cart update." means the outcome is unknown and a partial write is possible, so read the cart before retrying. Cart mutations still reject for ordinary reasons such as an invalid discount value, so match on these messages only when you need to tell the two cases apart.
Scope is per extension, driven by the api_version the extension declares, not per store.
Why it matters
Silent failure is the expensive kind. A dropped discount write at the till means staff saw a confirmation on screen, the customer was charged the wrong amount, and nobody finds out until reconciliation. The usual trigger is timing: the cashier taps through to payment, POS stops accepting cart edits, and the extension carries on as though the write landed. For merchants whose in-store pricing logic lives in a custom Shopify app, this release converts an invisible data-loss path into an error at the call site, where the extension can retry, prompt the cashier, or roll back its own state. The error is now yours to handle, and an uncaught rejection stops the rest of the handler.
Role-specific impact
- Marketers: In-store promotion mechanics delivered through a custom extension become verifiable. Ask your development team whether a failed discount write is now visible to the cashier rather than absorbed quietly.
- Developers: Every cart mutation call site needs a catch handler, and that handler has to reset any applied-state and loading flags your component owns. Audit before you bump the API version, not after.
- Store admins: Expect new error messages at the till once extensions adopt 2026-10. Staff need a simple instruction, usually to retry the action before taking payment, and an escalation path when the message persists.
Use-case example
Real-world scenario
A specialty retailer with 40 locations runs a custom extension that applies an employee discount from a staff lookup. Across roughly 15,000 monthly in-store orders, about 0.4 percent of discount applications are dropped because staff move to payment faster than the write completes. That is near 60 transactions a month, each needing a post-sale adjustment that costs a manager around 8 minutes of refund and note-keeping work. On 2026-10 the mutation rejects, the extension re-prompts before payment, and almost all of that manual correction disappears.
Implementation checklist
- Inventory every cart mutation call site across your POS extensions, including any shared helper that wraps them.
- Wrap each call in try/catch or attach a catch handler, and reset loading and applied-state flags in the failure path.
- Decide retry behaviour per message: retry on an outright refusal, re-read cart state first when the outcome is unconfirmed.
- Add a staff-facing message that says plainly that the cart did not change.
- Test on a physical device, including a cart that has already advanced to payment, which is the case most likely to reject.
- Only then set api_version to 2026-10 and deploy, keeping 2026-07 as a tested rollback.
FAQ
Q: Can we stay on 2026-07 and skip this?
A: Only temporarily. Version 2026-07 keeps the current behaviour until it reaches the end of its support window under Shopify's quarterly versioning policy. Pinning is a scheduling tool, not a decision, and the work does not get smaller by waiting.
Q: Our extensions already catch cart errors. Are we done?
A: Probably for correctness, but review what those handlers do. Catch blocks written for invalid-input errors often show a message that makes no sense for an unconfirmed write, and they rarely reset the applied-state flag that the UI reads.
Resources
POS UI extensions Cart API reference
Need guidance? Talk to Makro.