The only safe question a payment system can ask is whether money actually moved.
This week I shipped a cancel-save system that lets card trialists cancel inside the product, get offered seven more free days, and receive a real confirmation whether they cancel in our app or in Stripe's portal. Adversarial reviewers caught five bugs the builders shipped. The worst one was not a typo. It was philosophical.
Both destructive code paths asked the same question before acting: did this person convert and pay. That sounds correct. It is not. A customer who had genuinely paid, but whose record had not yet been stamped, would have had their credits clawed back and their subscription deleted. The logic would have executed perfectly. Green all the way down. The only safe question is not did the record say they paid. It is did money actually move.
This is the same failure mode that quietly bleeds revenue inside home-services roll-ups. A CRM says the job closed. A billing sync says the invoice cleared. A dashboard says the ticket resolved. Each of those is a record of an event, not the event itself. When you consolidate five to a hundred brands onto shared systems, you inherit every place where the record and the reality drifted apart, and none of it shows up as an error.
The discipline is to design destructive actions around the hardest source of truth you have. For money, that is the money moving, not a status field describing it. Before you let any automated path delete, refund, or claw back, ask what the true event was and whether you are checking that event or a story about it.
Status fields lie by omission. Bank ledgers do not. Build against the ledger.
AI Value-Creation Diagnostic | All insights