The switch nobody had measured

Settlement means moving held funds from the wallet where a payment lands into the merchant’s spendable wallet, once the term agreed with the provider is met. The automated process was ready and only the flag was missing. But the system had spent months crediting payments without settling them, and nobody had looked at what had piled up on the other side of that switch. Turning it on takes a second and cannot be undone: once money moves, it has moved.

I measured the real state against a production copy before touching anything. Twenty-five credited, unsettled orders showed up — and the decisive part was that they were not one group but two opposite problems. Some had a release date already past: the process would take them all at once on the very first run, in a single batch, without anyone having decided that today was the day. The others had no date at all, and those the process would never pick up — the date is stamped at crediting time, and turning the automation on does not backfill. They would stay held forever, silently and without an error. On top of that, the held balance exceeded what the orders claimed by the exact amount of one of them: a duplicated credit, not a rounding gap.

Before anything was switched on, what moves by itself was separated from what would never move, and each group got its own path: automation for the overdue ones, and a manual desk in the backoffice for the ones the process would never take. Two more things were fixed along the way: the settled amount is the net that actually came in and not the gross the payer submitted — moving the gross would have released fees that do not belong to the merchant — and the automation flags were pulled out of the backoffice tree, because switching off a menu must never switch off the engine that moves money. The principle got written down: before turning on an automated process over money, measure the backlog it is going to find. A new switch over old data is not a new feature, it is a migration.