The receipt switch that printed anyway
Our payment screen had a Print receipt toggle from the day it was built. It was drawn, it flipped, it looked live — and nothing read it. The paper came out either way.
There is a specific kind of bug that survives for months because it looks like a working feature. The payment screen had a Print receipt toggle. You could tap it. It moved. It redrew in the off state and stayed there. And nothing, anywhere, ever read it — the value was set into a variable, rendered, flipped, and then simply dropped. The customer copy printed according to the printer setup, whatever the person serving had chosen.
Why nothing caught it
Every individual piece was fine. The toggle rendered correctly. The printing path worked correctly. A test of the toggle would have found a control that changes its own appearance, which it does. A test of the printing path would have found paper coming out, which it should. The bug lived in the space between two things that both worked, and that space is not somewhere tests naturally look.
We found it by reading the whole path end to end while building something else — the same way the cash-drawer kick turned out to have a fully written serialiser that no caller had ever passed a value to.
Paper is a decision, so make it one
The fix was not just wiring the switch. Whether a receipt prints is a real venue decision with four honest answers, so that is what it now has: follow the printer setup, ask each time, always print, or never print. Under ask the pay screen starts with the receipt off and whoever is serving turns it on when the customer wants one — which, at a counter, is most of the time a no and a roll of paper saved.
Under always or never the venue has already answered, so the switch shows that answer and refuses to move, with the reason next to it. A control that can be moved but will be overruled a second later by the server is the same lie in a new costume.
Never does not mean the customer gets nothing
Turning off the paper at the counter leaves the QR receipt, the emailed receipt and the reprint button on past orders exactly where they were. That distinction matters enough to be written on the settings screen itself, because "never print" reading as "the customer cannot have a receipt" is precisely the misunderstanding that stops somebody using a setting that would save them a roll a day.