Security is not a promise. It is a list of mechanisms you can check one by one.
Every item below corresponds to a rule actually running on the platform. We deliberately avoid phrases like "100% secure" and only describe what the mechanism is and why it is designed that way.
Freeze first, pay second, never move funds under uncertainty
Frozen on submission
transactionalFunds are frozen the moment a payout is submitted, debited on success and released after confirmed failure. Freeze and debit happen inside one database transaction.
Unknown results are never auto-handled
anti double-payOn upstream timeout or missing result, the platform does not mark failure, does not auto-refund and does not auto-resend. The order goes to a manual adjudication queue.
No "resend" button
by designFailed orders are never resubmitted automatically. This is a deliberate product decision, not a missing feature.
Idempotent orders
unique constraintOne merchant order number creates exactly one order; resubmitting returns the same result and never pays twice.
Balances derive from entries; differences are recorded, not adjusted
Double-entry ledger
Every movement of funds writes two entries; the balance is derived from them. No back-office function can overwrite a balance field.
Invariant checks
The system recomputes "balance equals the sum of all entries" daily and alerts on any mismatch.
Daily reconciliation
Internal ledger reconciliation and upstream order reconciliation run automatically every day and can be triggered manually.
No automatic adjustments
Differences found by reconciliation are only recorded. Any adjustment must go through an explicit business document and approval.
Two people and two factors for critical actions
| Action | Control |
|---|---|
| Deposit confirmation | Reviewer ≠ creator; live verification code |
| Deposit reversal | Approver ≠ initiator; live verification code |
| Withdrawal disbursement | Disburser ≠ reviewer |
| Settlement confirmation | Confirmer ≠ submitter |
| Adjudication of failed orders | Live verification code; upstream result verified first |
| Upstream float top-up | Approver ≠ recorder; live verification code |
| Admin account changes | Live verification code |
Separation of duties is enforced by the backend and cannot be switched off. Step-up verification only accepts live authenticator codes; recovery codes cannot confirm operations, and repeated wrong codes abort the action rather than lock the account.
Private keys stay with the merchant; server IPs must be allow-listed
RSA request signatures
Every API request is signed with the merchant private key and verified with the public key. The signature covers method, path, timestamp and body.
Private key shown once
Key pairs are generated in the merchant browser; the platform stores only the public key. The private key is shown once at registration and cannot be recovered.
Mandatory IP allow-list
Registering an app requires 1 to 10 server IPs; apps with an empty allow-list are rejected outright.
Real source IP
The client IP is taken at the edge layer; forgeable forwarding headers are not trusted.
Two-factor authentication and login protection
- All three portals support authenticator-based two-factor authentication (TOTP), enforceable per role
- One-time recovery codes are issued at enrollment for lost authenticators; regenerating invalidates old codes
- Repeated wrong passwords trigger lockouts with doubling durations
- Session token rotation uses atomic conditional updates, so a hijacked old token cannot be renewed
Configurable rules with an audit trail
- Beneficiary account blacklist, global or per merchant
- Per-transaction limit, daily cumulative limit and order frequency caps within a time window
- Every block is logged and searchable by merchant and rule type
- Blocked orders cause no fund movement (the transaction is rolled back)
Edge, storage, logs, supply chain
Edge protection and origin lock
All entry points pass through an edge protection layer; origins accept traffic only from that layer and cannot be reached directly from the internet.
Multi-AZ and encryption at rest
Production services span multiple availability zones; databases and credential stores are encrypted at rest with keys independent from development.
Audit logs and masking
Operations touching funds or permissions are written to an audit log; sensitive fields such as ID and card numbers are masked at write time.
Dependency vulnerability gate
Production dependencies are audited on every commit; high-severity findings block merges. Images are scanned on push.
Third-party penetration testing
Regular third-party penetration tests and independent code reviews; findings are fixed within severity-based deadlines and documented.
Evidence for every change
Each feature change ships with a test evidence report stating what was covered and what was not.
Trust starts with clear boundaries
- No collections: the platform only pays out; it never collects on behalf of merchants
- No custody of merchant private keys: only public keys are stored
- No sharing of transaction data with third parties beyond what payment execution and legal obligations require
- No promises on arrival time: the final state from the query API is the source of truth