Money always moves

Designing payment systems always requires an attention to details.

The deterministic approach to solving a money problem is almost always a state machine. Distinct states representing the real life - who holds the money and where does it rest in the books. The convergence of the two is the necessary substrate, a condition that shores up the integrity of the system.

When and where does this money movement stop, how much of it should be accounted for?

Obvious candidate for this eventual collapsible state is the word SETTLED – a final destination beyond which nothing is possible. Yet the money always moves.

“Does SETTLED mean terminal? If yes, then why and what is the reasoning?”.

While designing the system, the same tension arose. We ended up with three forks. Most consequential of these was the question How do we handle refunds and chargebacks? Since most chargebacks and refunds in every case are after the fact scenarios, and always appear or happen only after the payment rail has accounted for a transaction.

A payment that can’t be refunded, or when refund mechanisms are added, they start to look like a brittle retrofit – violation of the constraints and invariants of the system.

The problem in the design was the conflation of two orthogonal aspects of a payments machine.

First and foremost, we should be able to answer What happened to the payment to be collected? The fact which becomes the basis of everything else that comes afterwards. Payment rail should be able to tell whether transaction authorization has been captured or not, and deduction from the intended party has materialized. A fact that carries immutability and provenance both.

Second, an equally consequential aspect, is the answer to the question Where is the money at?, which section or stage of the pipeline it rests.

These inquiries allow for visibility into two different timelines, two different clocks tell us two different truths about the state of the system. A collected payment allows for service fulfilment or another leg of the transaction to go through in almost real time. Actual money movement, which is often slower, and happens with a pre-defined delay allows for managing solvency of the system.

With this discovery, the system could account for refunds and chargebacks as just another state, a payment collected can be refunded or a chargeback processed.

Reasoning and rethinking the state machine allowed two different aspects to be tracked and treated as source of truth, which otherwise would have left the system brittle as well as ambiguous. An uncertainty of a kind would have been baked into the logic, violating its principal role as a truth oracle.

SETTLED state still remained the correct choice for the state machine. The two clocks which run in parallel for payment systems were delineated. A structured and deliberate approach to design paid off where we saved ourselves from landing a costly mistake into production or extensive rework of the codebase in development.