The Number at the Bottom of the Checkout Page

Near 1 a.m., the checkout page was the only bright thing in the room. I had been changing it since 6:30 that evening. By then, I had made 23 small saved changes. A card lifted a little when a pointer passed over it. A missing sport picture showed a readable label instead of a broken icon. One option wore a small “MOST POPULAR” ribbon.

Those were satisfying changes because I could see them right away. The number at the bottom of the page was different. It had to be right before anyone could pay.

The first arrangement did not work for the change in front of us. The old checkout put two different costs on one screen: the monthly membership and the price of running one event. The redesign needed to separate them without throwing away the existing way that payment happens.

I did not start by replacing the live page. I used a query-string flag, which is just a small extra note added to the end of a web address. With ?prototype=1 on the address, I could see the new checkout. Without it, the old checkout stayed in place. It was like putting a new sample kitchen behind a staff-only door while the old kitchen kept serving dinner.

That gave me a place to work and let controlled reviewers see the new layout. It did not make the new layout safe just because it was hidden from the normal page. A different door does not change what happens in the same kitchen underneath it. The temporary view still needed proper access limits, a person responsible for it, and a clear point when it would either become the real thing or be taken away.

At first, I worked on what was easiest to judge with my eyes. The ribbon, the softer unpaid badges, the hover effect, and the empty state all moved forward in small pieces. That approach did not answer the hard question. It took minutes to make many of those visual changes. The real hours went into making two different kinds of charges add up correctly in the same purchase.

I only understood that by being wrong about it. The new page showed the full balance in the bar at the bottom, and the check I had been given said everything was wired up correctly. I took that to mean the pay button led to a page that agreed. So I treated the page as good enough and moved on to the next screen. I clicked pay and it said the total was zero. The checkout page read its numbers from a record that the new cart never wrote to, so it had no idea what I was buying.

A customer could be buying a monthly membership and paying for an event at the same time. The new event cart could not simply replace the older membership path. Both needed to feed one order, one final total, and the existing handoff where payment happens. The membership also involved real proration, meaning the price needed to account for the part of a billing period already used. A made-up number would have looked fine on the screen and been wrong where it mattered.

I think of it like a grocery cart at the kitchen table. One person has a recurring pantry delivery and a one-time birthday cake in the same cart. The receipt still has to show one total that is correct. You cannot decide that the cake total is close enough because the box has a nice ribbon on it.

That was the wall in this work. The page could show two paths at once, but the two paths still had to share the same money math. The temporary web-address trick separated what people could see. It did not separate the work underneath. Before the new version could ever be used more broadly, the expected totals and the different account situations had to be checked, along with the point where payment passes from the cart to the existing checkout.

The 23 small changes still mattered. They made the work easier to inspect. If the card lift felt wrong, I could remove that one change without touching the price work. If the image fallback caused trouble, I could find the small change that introduced it. Weeks later, a question about why a toggle was arranged a certain way would have a real answer instead of a vague memory of a late night.

I also did not want the temporary view to become permanent merely because it was there. So the night ended with a written record, not another visual tweak. I wrote down how different account situations should be handled, what capacity warnings were needed, what a downgrade should do, why this direction had been chosen, and what other choices had been considered. Just as important, the record named the assumptions behind putting it into use and the conditions that would mean the temporary path needed to be revisited or removed.

That last part sounds less exciting than a shiny new checkout card. It is the part that keeps a useful experiment from quietly becoming a permanent promise. A temporary path needs an owner and an exit plan, because memory is a poor system for keeping a promise.

The checkout page told me the total was zero because it read from a record the new cart never wrote to, and that one wrong number at the bottom cost more hours than all 23 small changes combined. The ribbon, the hover lift, and the image fallback could each be judged by eye and removed one at a time. The zero could only be caught by pressing pay and watching the handoff, which is why the totals for membership proration and event charges, checked through that handoff, are what decide whether the flagged view ever becomes the real page.

dxdev LESSON · paste into your AI coding agent
LESSON: A prototype behind a query-string flag is still a live purchase path that has to add up
SOURCE: dxdev.com/blog/2026-04-10_number-at-the-bottom-of-the-checkout
WHAT HAPPENED: A checkout redesign was built behind a query-string flag so visual changes could be reviewed without touching the live page. The visual work was straightforward; the real difficulty was making a new event-purchase cart and the existing membership and proration logic feed one correct total into the existing payment handoff. A false confidence moment: the new checkout displayed a full total and appeared wired up correctly, but clicking pay charged nothing, because the payment step read its numbers from a record the new cart had never written to.
THE RULE: Hiding a redesign behind a flag controls who sees it, it doesn't separate the underlying money or data logic from the live system. Before trusting a new purchase flow, verify the actual payment step reads from the same record the new UI writes to, not just that the displayed total looks right.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any feature-flagged or prototype checkout or purchase flow where the displayed total and the actual charge are computed from different data sources; verify they are the same record.
  2. Any UI element, a total or a badge, presented as evidence a feature works without confirming the value all the way through to the actual transaction it precedes.
  3. Any temporary or prototype code path, such as a query-string flag, with no written owner, exit plan, or condition for becoming permanent or being removed.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.