A PIN on every payment
Nothing moves money without your PIN — not a saved session, not a biometric shortcut, not a "trust this device". It is collected fresh each time, never stored on the phone, and locks out after five wrong attempts.
Security
The boring parts, done properly.
xPay is a payments interface over regulated rails, and it holds no balance of yours. Money is pulled from a bank account you authorised — or a card tokenised on the provider’s own page — and pushed straight to where it is going. Everything below applies to both xPay GO and xPay Business, because both sit on the same code.
Getting back in takes two channels
There is no password to forget — your PIN is what authorises payments. If you lose it, we send a code to your number and another to your email, and we need both before you can set a new one. A code to your number alone would mean that anyone who talked your network into moving your SIM to their handset owned your account. Setting a new PIN also signs you out everywhere.
Sessions bound to your device
Signing in binds the session to that specific phone. Revoking a device ends its access immediately rather than whenever its token happens to expire, so "sign out everywhere" means it.
A ledger that has to balance
Every movement is recorded as double-entry postings in kobo, and the database refuses to commit a transaction whose debits and credits disagree. The ledger is append-only: a correction is a new, reversing entry, never an edit.
Never failed until the bank says so
If our bank partner has not decided the outcome of a transfer, we do not guess. An unknown response is treated as pending and requeried until it resolves — because assuming failure would return money that had actually left, and a retry would then send it twice.
No card number ever reaches us
A card is tokenised on the provider’s own hosted page and comes back as an authorisation code. There is no field anywhere in xPay that a card number could travel in — which keeps the card path out of PCI scope as a property of the code rather than a promise about it.
Merchants never hold our provider’s keys
xPay Business issues its own credentials, scoped to an environment. A sandbox key does not work against production and cannot be made to. Keys are rotatable and revocable, the private key is never sent to a client or logged in plaintext, and every key and instrument action is audit-logged.
Deliveries are signed over raw bytes
Every webhook is verified against the exact bytes received, before anything is parsed. A body that has been decoded and re-encoded no longer matches, and an unsigned delivery is refused outright — accepting one would let anyone who found the endpoint settle a payment.
Your history is yours
History sits behind your PIN. Turning off "Let others find me" makes your number un-look-up-able, and blocking someone reads to them exactly like a number that is not registered — we do not confirm who blocked whom.
Reporting a vulnerability
Send findings to security@xpay.ng. We acknowledge within two working days and will not pursue researchers acting in good faith who avoid privacy violations, service disruption and data destruction.