Skip to main content

Money integrity

The balance you see is not a number in a field. It is backed by a double-entry ledger, checked automatically against that ledger, and every movement on it is traceable back to the payment that produced it. This page describes the guarantees at a level your finance and engineering teams can hold us to.

Double-entry ledger under the balance​

Every unit collected is accounted for. A cleared collection posts to a double-entry ledger and credits your balance in the collected currency, net of fees. Because the ledger is double-entry, value is never created or destroyed by an update: every movement (collection, fee, refund, settlement) is a balanced posting, so your balance is always derivable from the postings underneath it, not merely stored next to them.

One ledger sits under every integration path and every rail: collections in any currency post onto it (as a balance per currency, per environment — test and live money never mix), and every movement against a balance is a posting on that same ledger. There is no per-method or per-market sub-balance to cross-check; the single ledger is the product.

Exactly-once at the front door​

Ledger integrity starts before the ledger: nothing may enter it twice. Payment creation is idempotent, and idempotency is enforced on the create path: a retried POST /payments with the same Idempotency-Key returns the original payment rather than creating a second collection, and refunds carry the same contract. A merchant-supplied payment_id closes the same door from the other side — a second create against one is rejected as a duplicate rather than admitted. Where decline recovery is enabled, it re-attempts within a single payment, so a recovered decline can never post twice either. The result: one customer intent, one payment, at most one credit. See Orchestration and routing.

Automated reconciliation​

An automated reconciliation run periodically compares your balance against the net of the ledger and records match or drift. Drift raises an operational alert for investigation. Automated reconciliation runs continuously.

The point of reconciliation is not that discrepancies are impossible; it is that a discrepancy cannot exist silently. Any divergence between what the balance says and what the postings prove is surfaced automatically and investigated, rather than discovered months later in an audit.

What you see in your balance​

You can view your balance broken down and drawn down:

  • Available - value that has cleared and had its fees booked.
  • Pending - collections received but still inside a corridor's clearing window.
  • Settled - value no longer counted as available on your account.

You can break the balance down by corridor and currency, and export the underlying collections for your own reconciliation. Refunds post back against the original collection on the same ledger, so a refunded payment nets out rather than leaving an orphaned credit.

Reconcile it yourself​

You do not have to take the balance on faith. A finance team can close the loop independently:

  1. Export the collections for a period from the dashboard (each row carries the payment_id and your metadata, so it joins to your own orders).
  2. Sum the net collected value and subtract refunds for the period.
  3. Compare against the movement in your balance over the same period.

Every number in that comparison — gross, fees, conversion, net — is a posting on the same ledger, so the export and the balance are two views of one set of books, not two systems to reconcile against each other.

Traceable end to end​

Every movement against your balance is a posting, and every posting names the payment or refund that produced it, so any figure can be walked back to the collection it came from without leaving the ledger. Exports carry the same identifiers (payment_id and your metadata), which is what lets your own books join to the ledger row by row.

Reading the balance​

GET /v1/balances reports available, pending and settled for each currency you collect in. What each of those means, and how test and live balances stay separate, is on Balances.

TensorRail, Limassol, Cyprus.