A store ran a promotion: spend over a threshold, receive a free item. Customers began writing in to say they were being charged for the gift and could not remove it. One message was explicit — the customer named the amount he believed he was being billed and asked whether he was being forced to buy something he had not chosen.
The obvious reading was that the promotion was misconfigured and customers were being overcharged.
Nobody was being charged. The promotion was configured correctly and the automation was working. Every affected order line carried a total of zero.
The defect was in the cart's price column, and it came from two plugins fighting over the same rendering hook. The promotion plugin added the item at zero. A separate discount plugin hooked the same cart price filter at a later priority, discarded the incoming price entirely, and rebuilt it from the product's own metadata — rendering the regular price struck through beside the sale price.
The line subtotal still read zero. The price column beside it read like a charge. So the customer saw a number that looked exactly like being billed for something they had not asked for, sitting next to a total that was, in fact, correct.
A display defect can have a real revenue cost
Nothing was wrong with the money. What was wrong was what customers believed about the money — which produced support load, a complaint that reached the owner, and an unknown number of abandoned carts by people who concluded they were being force-billed and left. Those carts leave no ticket and no trace.
Two plugins can both be correct and still be wrong together
Neither vendor had a bug in isolation. The discount plugin's behaviour is reasonable for the case it was written for. It is only wrong when something else has legitimately set a price to zero — and no amount of reading either plugin's documentation would predict the interaction.
The obvious diagnosis was the wrong one
Had we accepted the reported symptom, the fix would have been to change the promotion or the product's pricing, and neither would have touched the actual defect. Confirming the money was correct before changing anything is what kept a display bug from becoming a pricing incident.
- ✓A targeted fix rendering the gift line honestly — original price struck through, FREE beside it — and changing nothing else
- ✓It returns early unless the line carries the promotion's own marker, so it touches no other product, no totals, and no order data
- ✓Functionally tested before deployment without touching the live store: exercised against the real hook chain and real product data in a throwaway process
- ✓Verified again after deployment, in a fresh process that had not itself defined the fix
- ✓Rollback is a single toggle
Read-only diagnosis: store CLI, SELECT-only queries, and source inspection of the plugins' registered hooks and priorities, to establish which code was rewriting the value and where in the chain it sat.
Client, vendor, product and industry details are removed, along with any figures belonging to the client. The technical detail is unchanged. This shows how we work — it is not a claim about a business result, which would require the client’s consent and a baseline measured before the work began.