A 300 Millisecond Wait Fixed the Stale Installment Figure at Checkout

The checkout page showed a 30% coupon applied to the main total, but the payment message beside the buy button kept offering four payments based on the old, higher price. The correct discounted total was being passed in. The message simply refused to redraw with it. Nothing errored, and the number that was wrong was not the number that had been calculated wrong.

Picture it from the customer’s side. The order would charge the discounted amount. The figure beside the buy button would not match it. At the last possible moment, one part of the page said “here is what this costs” while another part told a different story.

That is not a small bit of polish. Payment is where people decide whether to trust a page. If a price drops and the installment estimate does not, a customer has a fair reason to pause. They may wonder which number is real, whether the coupon worked, or whether something worse is about to happen after they click.

The fix that looked embarrassingly simple

The payment message had been given the original total. When the coupon changed that total, we tried handing the message the new one and asking it to draw itself again in the same spot. The rest of the page already knew how to update. The running total changed. The tax line changed. The label on the buy button changed. The payment message ought to have followed along.

It did not.

There was no error message and nothing visibly broke. The old number stayed there, as if the new one had never arrived. We spent time checking the coupon math and checking that the correct total was being passed in. Both were fine. That part matters, because it is easy to keep hunting for a mistake in the number when the number is not the problem.

The technical name for the culprit is an SDK. It is a packaged piece of software from another company that you place inside your own page. This one had settled into the little box where it first appeared, and asking it to draw again in that same box was not a dependable way to make it read the new price.

Replacing the note on the refrigerator door

The answer was less like fixing a calculator and more like replacing a note on the refrigerator door. Instead of erasing and rewriting the old note, we took down the little box that held the payment message, put a fresh blank box back in the exact same place, and then asked the payment message to appear there.

The fresh box mattered because it gave the message somewhere it had not already claimed. But it had to go back carefully. If the new box lost its styling, the message could look different or make the page jump. If it went back in the wrong place, it could slide to the bottom of its section. So the replacement kept the same appearance and returned to the same spot before the message was redrawn.

The price was still moving

That solved the stuck number, but there was another wrinkle. The price on the page did not just change. It animated down after the coupon was applied, so the number was moving for a moment before it reached its final value.

If we replaced the payment box at the exact instant the coupon was applied, it could sometimes catch the price halfway through that movement. The displayed estimate was then new, but not settled. It is like writing down the score while the scoreboard is still flipping its cards.

The fix was a short wait of 300 milliseconds, three tenths of a second. That was long enough for the price animation to finish and short enough that nobody would notice a lag beside the buy button. 300 is not a magic number for every checkout. The point was to wait until the thing the message depends on had actually stopped changing.

The shortcut that skipped the refresh

There was also a sneaky edge case. The page had a sensible shortcut: if the newly calculated total matched the previous total, it skipped some of the update work. Usually that saves effort. But “the total is unchanged” does not always mean “the payment message is right.” The message could still be showing an older amount because an earlier update had arrived at an awkward time, or because it had failed to appear cleanly before.

So the refresh had to happen even on the shortcut path. Otherwise the rare, frustrating cases would stay broken precisely because the page decided there was nothing new to do.

What finally made the numbers agree

The big number was correct. The order charge was correct. Yet a smaller number next to the button was enough to make the whole moment feel unreliable.

The payment message was handed the correct discounted total and still showed the old one, first because it had claimed its box and would not redraw there, and then because it could catch the price mid-animation, before the total had stopped moving. A fresh box put back in the same spot after a 300 millisecond wait, and a refresh that runs even when the new total matches the old one: those three details are what made the small figure beside the buy button agree with the large one above it.

When a discount or other price change goes live, check every figure on the checkout page, including third-party payment estimates beside the buy button, and not only the order total. Here the total charged was correct while the installment message kept showing the old price.

dxdev LESSON · paste into your AI coding agent
LESSON: Re-rendering an embedded SDK widget in place doesn't guarantee it re-reads new data
SOURCE: dxdev.com/everyday-ai/four-payments-that-would-not-move
WHAT HAPPENED: A checkout page's installment-payment message, rendered by a third-party payment SDK, kept displaying the pre-discount price after a coupon was applied, even though the page's own total updated correctly right beside it. Asking the SDK to redraw into the same container element was not a reliable way to make it read the new price. The fix destroyed and recreated the container element before re-invoking the SDK, added a short delay so a price-change animation could finish before the refresh ran, and made sure the refresh still fired even on the "total unchanged" fast path, since the displayed message could still be stale even when the newly computed total happened to match the previous one.
THE RULE: A third-party embedded widget that reads its input once at render time may not update on an in-place re-render. When live data changes, give it a fresh mount point rather than trusting an in-place refresh, and don't skip that refresh just because your own computed value happened not to change.
CHECK MY CODE, then report PASS or FAIL with file:line for each:
  1. Any place a third-party payment or SDK widget is re-rendered into the same DOM node after underlying data changes, without destroying and recreating that node first.
  2. Any UI update that skips a refresh entirely when a newly computed value equals the previous one, without checking whether a dependent display element is already stale for an unrelated reason.
  3. Any price-dependent widget update that fires synchronously during a CSS or JS animation of the value it depends on, without waiting for the animation to settle first.
THEN PRINT: a table (check, PASS/FAIL, evidence, fix) + a verdict (applies / partially / OUT_OF_SCOPE / no) + the single most important next action.