The Day a Negative Number Tried to Lie to Us

The bug that a thousand green tests missed

One merchant had a returns-heavy day. The batch total was negative. I typed it in, and the tool added it as a positive number. The merchant's processing volume went up when it should have gone down, and the tracker nudged them toward "activated" on money that never existed.

Every automated test on that build was green. Over a thousand of them. Not one caught it, because tests check what you thought to ask, and nobody thought to ask what happens when a real day goes backward.

What the instrument actually does

Here is the thing we were shipping. Our deployment and ops team wanted one answer every morning: of the merchants we just boarded and shipped equipment to, who is actually processing, who reached their stride, who went quiet, and who got helped back on track?

So the tool now puts every delivered boarding into one of four honest buckets: watching, reached, stalled, solved. The morning batch upload feeds it. If a day's upload gets missed, a coverage strip nags about it instead of pretending the quiet is fine. Every volume entry lands in an audit log you can read right on the page: who entered what, when, from which source. And when a stalled merchant gets rescued, the person who solved it gets their name on it.

That last part was deliberate. The team that chases activations does real, unglamorous work. The instrument exists to make that work visible, not to replace it.

Honor the sign

Back to the negative number. The fix was not complicated once we saw it. We ruled it simply: honor the sign. A negative batch subtracts. A merchant's total can read negative if that is the truth of their week. A merchant who had "reached" their stride can fall back to "watching" if returns pull them under. And if someone types something that is not a number at all, the tool refuses loudly instead of guessing.

Then we walked it again. Negative subtracted. The total read honest. The refusal was loud. Only then did it ship.

This is a standing rule for us now, proven again and again: the walk before the merge is not ceremony. A green test suite tells you the code does what the builder imagined. A walk tells you what the software does to a real person on a real Tuesday. Those are different questions, and the second one is the one that matters.

What this means if you run an ISO

If you track merchant activations in a spreadsheet, or worse, in someone's memory, you already know the failure mode. The quiet merchant nobody notices for three weeks. The rescue nobody gets credit for. The number somebody fat-fingered that nobody can trace.

An instrument fixes that only if it is honest. Honest means it shows its work on its face, refuses bad input out loud, and reports the bad weeks as faithfully as the good ones. A tracker that only knows how to count up is not a tracker. It is a cheerleader.

We build these tools for our own book first. VizyPay runs on them before anyone else does, which is exactly how a negative number gets caught at midnight instead of in a merchant's ledger. That is the whole model: prove it on ourselves, then open the doors.

If you want to follow along as we do, the newsletter at getvexis.ai is where these field notes land first.