News and analysis
Before checkout: display confirmed cart state
Shopify clarifies write outcomes and discount values; FastSpring limits purchases per buyer. Verify the complete offer workflow.
A discount appears on screen while the order total stays unchanged. Or an offer allows one purchase, but the buyer completes checkout again on another device. These errors involve different levels of state. October Shopify changes and a September FastSpring addition are useful together before releasing offer rules.
An accepted call does not always mean an applied write
On 7 October, Shopify changed cart mutations in POS UI extensions API 2026-10: unconfirmed writes now reject. A refusal leaves the cart unchanged, while an unknown outcome allows a partial change and requires reading the cart before retrying. API versions 2026-07 and earlier are unaffected by this change.
For the application, make the transition from intent to outcome explicit. An employee clicks, the system requests a write, and then receives confirmation or another state. “Applied” should reflect a confirmed change. Do not silently convert an unknown outcome into success or a supposedly safe retry.
The value type is part of the contract
In a separate 7 October Shopify update, POS 11.15 corrects Discount.amount for Percentage to return a percentage rather than a monetary value. The correction affects all API versions; FixedAmount and Code are unchanged. This is a different version boundary from the cart-mutation change.
The connection inside checkout is concrete: applying a discount correctly and interpreting its value correctly are separate checks. If the interface treats a percentage as money, a successful write does not repair the display or calculation error.
A buyer limit extends beyond one cart
On 28 September, FastSpring described Purchase Limits, tracking a buyer’s cumulative purchases across orders, sessions, devices and payment methods. This earlier article adds another layer: an offer rule may depend on customer history.
The comparison does not present the products as a ready-made integration. It suggests that checkout should reflect a confirmed write, the correct value type and the relevant customer history. Each layer has its own source of truth.
For acceptance, prepare a sample discount, a repeated request and a second purchase from another device. Check the display following refusal, an unknown outcome and a fresh cart read. Compare amount and percentage by type, and the purchase cap by the agreed buyer identity. Establish that staff can explain a restriction to the customer.
Our business rules guide helps describe the states. The rental application project provides customer-journey context without claiming these payment connections. For your product, discuss checkout confirmations and limits.