Skip to main content
Most payment APIs finish when money reaches an address. Useroutr finishes when your application has been credited, because that is the event your product actually cares about.

The guarantee

A funding intent reaches settled only when balanced double-entry records exist for it. A transaction hash is evidence that value moved. It is not evidence that your user should be credited. This gives you three things that are otherwise hard to build:

Exactly once

Postings are keyed by intent and kind with a uniqueness constraint. A replayed webhook or a retried worker cannot double credit.

Reversible

Corrections are compensating entries, never deletions. History is append only.

Reconcilable

Balances are derived from entries, never stored as the authority. A continuous reconciler compares them and alerts on any divergence.

Balances as a destination

Settling to rail: "ledger" credits an account we hold on your behalf rather than sending to a wallet:
Useful when the user’s value lives inside your product: a game balance, API credits, a trading account, a marketplace wallet. You avoid running your own ledger, and the balance is reconcilable against real settled funds rather than against your own bookkeeping.

What we hold, and where

We are non-custodial where the rail allows it and custodial in transit where it does not, and we say which per rail rather than glossing it.
Every unit we hold has a named liability account. There is no off-ledger operational wallet anywhere in the system.

Receipts

Every deduction is named, attributed, and ordered:
Flat fees apply before percentage fees. Receipts are generated from ledger entries rather than computed alongside them, so a receipt cannot disagree with the books.