The part of a payment platform nobody markets, and everybody depends on

Nobody chooses a payment platform because of its ledger. Everybody depends on it.

It is the part that decides whether every other feature can be trusted, and it is almost never the part anyone asks about.

The stored-balance mistake

A great many systems keep a balance as a column. A payment arrives, the column goes up. A payout leaves, the column goes down.

This works until something interrupts it halfway, or two things update it at once, or somebody with database access decides to help. And the moment a balance can be set rather than posted to, the books have stopped being evidence. They are now an opinion, held by whoever last had write access.

Derived, not stored

Here, a balance is the sum of its wallet’s own entries. It is computed, not kept.

That one decision removes an entire category of problem. There is no number to drift, no number to correct, and no way to assign a balance a value. You can only post to it — and a posting has to balance.

Balanced at write time

Every transaction is made of entries that sum to zero per currency. A transaction that would not balance is refused, not written and cleaned up later.

The books cannot go out of balance, not because a job checks them each night, but because an unbalanced state is not a thing that can be written.

Corrections are postings

When something is genuinely wrong, the fix is a new transaction in the opposite direction. The original stays exactly where it was.

Anyone reading the history later sees both: what happened, and what was done about it. A ledger whose mistakes can be made to disappear is a ledger nobody should trust — including the people who run it, because they lose the ability to prove their own good faith.

It checks itself

Reconciliation recomputes every balance from its entries and reports mismatches. It does not trust the stored figure, because there is no stored figure to trust.

Above that sit invariants — statements about things that should never be true, such as a payment captured without a posting. If one of them becomes true, the platform can halt rather than keep processing on top of a contradiction.

Halting is expensive. Continuing to process on broken books is the kind of expensive that ends companies.

And it is hash-chained

Every state change goes into an event log where each entry is chained to the one before it. The record can be shown not to have been rewritten afterwards — which is the question an auditor is really asking when they ask for the audit trail.

What it costs

Nothing. It is the floor, not a feature.

What you can check

These are facts about the running platform, not adjectives. Each one is visible in the product, in the API reference or in the ledger.

• Postings are balanced per currency at write time; an unbalanced transaction is refused rather than written and fixed later.
• Reconciliation recomputes every wallet balance from its entries and reports any mismatch, rather than trusting the stored figure.
• Reversals are opposing postings; nothing is deleted, so the history of what happened stays readable.
• Guardian invariants watch for states that should be impossible — such as a payment captured without a posting — and can halt the platform rather than continue past them.
• Every state change is written to a hash-chained event log, so the record can be shown not to have been rewritten afterwards.

What it costs

Included. It is not a feature so much as the floor everything else stands on.

Is it switched on?

Whether this is available depends on the authorisations in place and on what the administrator of a given deployment has switched on. That changes, and an article does not — so the live answer lives on the feature page, which reads it from the platform itself: The ledger on the features page.

Read next

• Wallets and transfers — Money that arrives the moment it leaves.
• Settlement and statements — Know what was taken, not just what arrived.
• E-money and safeguarding — Every balance is backed, by construction.