Mobile money collection,
accounted for perfectly.
CashierWPay routes bKash and Nagad collections through a real double-entry ledger — not a balance column that can silently drift. Every deposit, payout, and correction is a journal that has to balance to zero, or it never happened.
Admin wallet
৳842,650.00
Every journal
DR = CR, always
4
MFS providers
bKash, Nagad, Rocket, Upay
100%
Journals balanced
Every entry, DR = CR, enforced
1
Ledger, no exceptions
No module writes a balance directly
3
Roles, one identity model
Admin, sub-admin, merchant
Built on solid ground
Every feature exists to protect one number: the balance.
Real double-entry ledger
Every balance change is a journal of debits and credits that must sum to zero. No module ever writes to a balance directly.
Append-only ledger history
The database itself revokes UPDATE and DELETE on ledger entries and audit logs. A correction is a new, opposite journal — never an edit.
Three roles, one identity model
Admin, sub-admin, and merchant accounts share the same underlying user model, with permissions enforced at the API layer, not scattered across tables.
Per-merchant balances
Each merchant gets an isolated ledger account with its own transaction history — visible to them, and to admins who manage it.
Complete audit trail
Every admin action — creating a user, suspending an account, adjusting a balance — writes an immutable audit log entry with before/after state.
How it works
One wallet, three roles, zero ambiguity.
Admin owns the wallet
One admin account holds the platform wallet. Everything else — sub-admins, merchants, balances — is provisioned from there.
Sub-admins run day-to-day operations
Sub-admins manage merchants and post transactions on the admin's behalf, with no wallet of their own — full operational access, zero privilege escalation.
Merchants get their own dashboard
Each merchant sees exactly their balance and transaction history — nothing more, nothing less — with self-service profile management.
The ledger settles every move
A credit to a merchant is a journal: debit the admin wallet, credit the merchant. Balanced, logged, and impossible to half-apply.
Built for developers
Integrate in an afternoon, not a sprint.
Plain REST, snake_case fields, and predictable errors. Create a payment, redirect your customer to the hosted checkout URL, and let the webhook tell you how it ended.
- Authenticate with a public/secret API key pair — no OAuth dance
- A hosted checkout page handles the MFS flow for you
- Webhooks on every final state, signed with HMAC-SHA256
- Every request carries a reference — retries are safe, never double-charged
curl -X POST "https://api.yourdomain.com/api/v1/payment/create-payment" \
-H "X-Authorization: pk_live_•••" \
-d '{"amount":"1100","reference":"inv_001", ...}'{
"reference": "inv_001",
"payment_method": "bkash",
"status_name": "completed"
}Security posture
Boring, on purpose.
The most dangerous part of a payment system is the part that's clever. CashierWPay is built to be small, flat, and predictable — so the ledger is the thing you have to trust, not the code around it.
- Passwords hashed with argon2id — never stored, never logged in plain text
- Sessions are database-backed and revocable, not long-lived tokens you can't kill
- The API connects to Postgres as a restricted role that cannot UPDATE or DELETE ledger history
- Every admin action — create, suspend, adjust — writes an audit log entry with actor, before, and after
- New accounts start with a one-time password and a forced change on first login
- Suspending a user immediately revokes every active session, not just future logins
Your wallet, run with ledger discipline.
Admins, sub-admins, and merchants all sign in through the same door — with exactly the access their role should have.