The price your storefront promises

A shopper reads a product page that says save twenty percent, adds the item, and arrives at checkout to find the full price. Nothing crashed. No error appeared. The store simply told them two different things about the same item, thirty seconds apart, and the second one was the one attached to their card.

They will not file a bug report. They will close the tab, and you will see it as an abandoned checkout with no explanation attached.

Two pieces of code, two answers

The disagreement is almost never dishonesty. It is architecture.

On most stores, the promise on the product page and the price at checkout are produced by two separate implementations of the same idea. The page gets a badge or a block, often theme code with some JavaScript, that works out what the shopper would save and renders it. Checkout gets a discount configured somewhere else entirely, evaluated by different code at a different moment with different inputs.

Two implementations of one rule will agree on the day they are written. They will not keep agreeing. Every edit to one of them is a chance for the pair to drift, and drift is silent by definition: the only party who sees both numbers is the shopper.

Where the drift comes from

The gaps are ordinary, which is why they are so easy to ship.

• Different inputs. The card reasons about the product in front of it. Checkout reasons about the whole cart, including quantity, subtotal and shipping, and can reach a different conclusion about the same item honestly.
• Different clocks. A promotion that starts “today” starts at a different instant for the browser, the server and the merchant. A schedule with no named timezone is a schedule with at least three answers.
• Different rounding. Percentage maths applied per line and then summed does not always equal the same percentage applied to a total, and cents are where shoppers look hardest.
• Caching. Theme markup and storefront responses get cached. A price the shopper is reading may be a price you stopped offering yesterday.
• The browser itself. Anything computed in the page can be edited in the page. If the shopper’s device participates in deciding the price, then the price is, in a small but real sense, negotiable.

What the disagreement actually costs

The direct cost is the abandoned order, and it is the most expensive kind of abandonment there is, because it happens after the shopper has decided to buy. They chose, they committed, they reached for a card. You lost them at the last step, on a promise you made yourself.

The indirect costs are worse and last longer. Support tickets asking why the discount did not apply. Refund requests from shoppers who noticed after the fact. A slow reputational tax, because the shopper does not conclude that your app has a bug, they conclude that the sale was never real.

Then there is what it does to you. Merchants who get burned by a mismatched promotion stop running promotions. The card comes off the product page and the offer goes quiet, which means the whole discount only exists at checkout where nobody is deciding anything anymore.

The fix is architectural, not careful

You cannot solve a two implementations problem by being more diligent about both. You solve it by removing one of them.

Every xDiscount discount lives in a single product metafield, and that record is written only by xDiscount’s own validated action. The Shopify Function that prices the cart at checkout reads it. The storefront offer card that shows the shopper the deal reads it. Same record, same rules, one writer.

Three properties follow from that shape, and they are worth naming.

Nothing is written by the browser. The shopper’s device reads a rendered offer, it never contributes to the price. A device that cannot write cannot influence what is charged, regardless of what its owner does to the page.

The card carries no price logic. The storefront offer card is a theme app extension, placed from the theme editor with no code, and it renders server side in Liquid. It is not computing a second opinion, it is displaying the first one.

Checkout is priced by Shopify. The discount is applied by a Shopify Function running inside Shopify’s own discount pipeline, on cart lines and on delivery. No script injected into your theme, no cart rewriting, no checkout workaround that a platform update will quietly break.

Which way each side should fail

Agreement is the normal case. The interesting design question is what happens when something goes wrong, and the honest answer is that the two sides should fail in opposite directions.

1

One writer

Only xDiscount's validated action writes the metafield. Every create is transactional, so a failure rolls back rather than leaving half a discount behind.

2

Two readers

The Shopify Function and the storefront offer card read the same record. There is no second implementation to drift away from the first.

✕

The Function fails closed

An unknown rule, a malformed record, or a condition it cannot evaluate produces no discount. A wrong discount costs money on every order it touches.

✓

The card fails open

It would rather show than vanish. A card that shows too often is visible and fixable. A card that quietly disappears just looks like a broken app.

The asymmetry is the point. Money should only move when the system is certain, so the Function refuses to guess. Visibility is cheap to correct, so the card leans towards being seen. Both choices protect the same thing, which is your ability to trust what you are looking at.

What you get back

Once the card and checkout read the same record, a set of small things become possible that were not before.

The offer card can state the conditions and the schedule, in English or French, because it is reading the rule rather than restating it from memory. Buy X get Y becomes usable on the product page, because the card renders the gift picker from the same record the Function will price. And the promise you make above the add to cart button becomes a promise you can leave unattended, which is the only kind worth making.

The price the card promises is the price checkout charges, because both read the same record. That sentence is not a slogan. It is a description of where the data lives.

Make the storefront and checkout agree

xDiscount is coming to the Shopify App Store. Founding merchants lock in lifetime founder pricing.

Install app→