Built so every cent is accounted for.
The rules that keep money exact, tenants apart and card numbers out of our systems. They hold for every product on the engine.
A double‑entry ledger, in integer cents.
Every amount is a whole number of cents with a currency code. Every posting balances, and a posted entry never changes.
- Money is never edited. A correction is a new entry, so the history always adds up.
- Fees are estimates until the processor's statement confirms them. A difference is its own line.
- No fractions of a cent, anywhere money is counted.
- Payment captured$79.00
- Processing fee, estimated−$2.61
- Fee difference from the statement−$0.04
- Deposit to the merchant's bank$76.35
Example data. The difference is a new line. The estimate is never changed.
Every gateway call sits between two database transactions.
The engine writes the intent before it calls the gateway, and writes the result after. If the answer is unclear, nothing is guessed.
- First, record the intent. One transaction commits before the call.
- Then call the gateway.
- Then record the result. A second transaction commits the answer.
- No clear answer? The intent is held as "unknown." Only reconcile can move it, by asking the gateway what happened. Nothing is sent again until then.
- Refunds wait for an undo window before they are sent.
One payment, when the network goes quiet
- Intent recordedpending
- Gateway calledno answer
- Intent heldunknown
- Reconcile asks the gatewayit was approved
- Intent moves tocaptured
Example. Nothing is sent again while the intent is unknown.
Each level sees only its own rows.
PostgreSQL row-level security keeps tenants apart in the database itself, not only in application code. A query from one partner cannot read another partner's data.
- Composite tenant keys on every reference, so a row can't point across tenants.
- The application cannot delete. Its database role has no DELETE.
- Three database roles, each with only the rights it needs.
The partner tree
- SovaraRuns the engine
- ISOIts book and everything under it
- Sub-ISOIts own book, under its ISO
- PlatformA developer platform and the merchants it brings
- MerchantIts own payments and settings
- LocationIts own merchant account and deposits
Operators run the engine. They never decide about a merchant.
Sovara's operators run automated controls and route alerts. They never approve, decline, hold or release a merchant. Those decisions belong to named people at the processor and the boarding ISO or sub-ISO.
- Every live gate needs proof on file and a second person to approve it.
- Every act is on the audit log, with who did it and when.
- Two-step sign-in for every operator.
Example data
Card numbers go straight to NMI.
Card fields come from the gateway in a secure window, and terminals talk to the gateway directly. The engine never sees a card number.
- The engine stores a token and the last four digits, plus the brand to show the card.
- Bank accounts keep only the bank name and the last four digits.
- Buyers see who they paid. The merchant is always named as the seller.
What the engine keeps
- Card numberNever
- Token from NMIKept
- Card brandKept
- Last four digitsKept
The processor, the gateway and the software.
A registered processor handles every payment. NMI is the gateway. Sovara Core™ is software. Deposits go from the processor straight to each merchant's own bank.
The processor
A registered ISO's processor approves each merchant account through the merchant's ISO or sub-ISO, and settles its payments to the merchant's own bank. The processor is named on each merchant's checkout once it approves the wording.
NMI
The gateway. Card data goes to NMI, and NMI returns a token. Terminals talk to NMI directly.
Sovara Core™
The software. It records every intent, result and fee in the ledger. It never holds funds and is never the processor.
See it for yourself.
Request a sandbox, take a test payment and watch it move through the ledger.