Payment infrastructure for multi‑tenant institutions
Prosoft Pay is an API-first payment gateway built for banks and financial institutions that need to process payments on behalf of their own merchants and products — every account, key, and ledger entry scoped to a tenant from the ground up.
Built for two audiences, one platform
An institution provisions the platform. Its merchants integrate against it. Neither one sees the other's data — that separation is enforced at the database level, not just the application layer.
Banks & institutions
Provision a new merchant, business unit, or product line as its own tenant — its own API keys, its own transaction history, its own ledger — without touching another tenant's data. A database-level guard rejects any query against a tenant-scoped table that doesn't filter by tenant, so isolation isn't left to code review alone.
Merchants they onboard
Each merchant integrates with its own signed API key, scoped to a single tenant — see everything they process, nothing anyone else does.
How a payment moves through Prosoft Pay
One request, four things that have to go right — each one live in the platform today, not on a roadmap.
- 01
Request is signed
Every merchant-API call carries an HMAC-SHA256 signature over a canonical string of method, path, timestamp, nonce, and body hash — no shared session, no cookies, just a key and a secret.
- 02
Idempotency is checked
Every state-changing request carries an Idempotency-Key. Retry the same request after a timeout and you get the original result back — never a duplicate charge.
- 03
The ledger is posted
A balanced, double-entry pair is written to an append-only ledger, enforced at the database level — the application role that serves this API cannot update or delete a posted entry, not just by convention.
- 04
A webhook fires
The lifecycle event (authorized, captured, failed, voided, refunded) is pushed to your endpoint as it happens — signed, and retried with backoff if you're briefly unreachable.
Read the full docs for the complete authentication, idempotency, webhook, and error-handling reference.
Built with the Burundi market in mind
Not a foreign platform with BIF bolted on — Burundian Franc is the default currency throughout the API, with USD supported alongside it.
Every amount is stored as a fixed-precision decimal, in BIF or USD — never floating point, so there's no rounding drift accumulating across a transaction's authorize, capture, and ledger-posting steps.