A Tale of Two Ledgers

How the boundaries between the conflicting ledger modes inform the design of a ledger that could do both.

Most ledgers can only serve one of two use cases.

They’re either a consolidated view of the company’s finances, or a mechanism for approving or denying transactions. The first is called the Recording mode, the second is the Authorizing mode. But in time, every company needs a ledger that can do both, because products mature and the demands they place on ledgers evolve.

The most powerful ledgers can serve the two.

What tends to happen is that companies build one ledger per mode. I would too—I’d rather have these two working than one giant financial mess created as a result of a bad tech decision.

But having two ledgers, one Recording, and one Authorizing, is sub-optimal. And expensive. And slow. You’ve got two teams, and much of the coordination, delivery and operational costs will be caused by having two of what should’ve been one.

This is fine at lower scale. But try operating a ledger in any successful enterprise, and you’ll quickly run into trouble.

Take store credits, for example. When you offer store credits to your users, withdrawing from your main account shouldn’t require any approval process, right? It’s your account, after all, and any overhead is an unnecessary obstacle.

But at the same time, users shouldn’t be able to use more credits than the ones they have—and an approval mechanism must prevent that from being recorded in the ledger.

How to design mixed payment methods with store credits

This is The Payments Engineer Playbook, and today we’re putting the “edge” in ledgers. We’re going to learn what makes them difficult to operate at scale. And how that difficulty is precisely what can help us build an infinitely scalable ledger.

The Recording Mode