Security
Can someone on your team take money?
That is the question people actually mean when they ask about security, and it deserves a straight answer rather than a list of technical words. Most money lost by card operators does not leave through the front door. It leaves through somebody who already had a login.
Everything described on this page exists in the source code you receive, so you never have to take our word for any of it.
Your own staff
Five things that make it hard, and obvious.
- Nobody holds a master keyThere is no single administrator password that opens everything. Each member of staff is given only the part of the job they actually do. The person who checks identity documents cannot move money. The person answering support cannot change your provider settings.
- Moving money asks who you are, twiceBeing signed in is not enough. Before anyone can change settings, adjust the books, or act on a customer's card, the system stops and makes them prove who they are again. Somebody who walks up to an unlocked laptop cannot move money with it.
- Every action has a name on it, permanentlyAnything a member of staff does is written down with their name and the exact time. That record is written at the same moment as the action itself, so an action cannot quietly succeed while its record fails. Nobody, including you, can go back and erase an entry.
- The money is counted twice, every nightEvery movement is recorded on both sides, the way a bank records it, so a balance is something the system works out from its own history rather than a number somebody could edit. Each night it recounts everything and compares it against your card provider. If a single cent is out of place, you see it the next morning instead of at the end of the year.
- A stuck payment is never quietly repeatedIf the connection to your provider fails halfway through moving money, the system does not try again on its own, because a failed connection does not mean the money stayed put. It marks the payment unfinished and settles it against the provider's own record. This is how operators end up paying twice, and it is designed out.
Outsiders
If somebody did break in.
The best protection is having nothing worth taking. Most of what an attacker would want is simply not kept.
- There are no card numbers to stealFull card numbers and security codes are never kept. When a customer asks to see theirs, it is fetched from the provider for that one moment, shown, and thrown away. It is never saved, never written into a log file, never held in memory for later. Somebody who took a complete copy of your database would find no card numbers in it.
- Your provider keys are not in the database eitherThe keys to your card provider account are given to the running system separately and are never stored in the database. No screen in the product will show one back to you. Your staff can see whether a key is working. They cannot see what it is, and neither can anyone who steals the database.
- Passwords cannot be read, only checkedCustomer and staff passwords are stored in a form that can be checked but never turned back into the original password. Even with full access to the database, nobody can read anyone's password out of it.
- Customer documents are scrambled at restSensitive stored information, including the codes behind two factor authentication, is encrypted before it is written down. The key that unlocks it is kept separately from the data it protects.
Your side
What stays your responsibility.
The platform runs on your own servers, so part of keeping it safe is genuinely in your hands rather than ours. That is the trade you make by owning the system instead of renting it, and it is better to say so now than to discover it later.
Yours to look after: the servers and keeping them updated, database backups and actually testing that they restore, the certificates on your domain, deciding who on your team gets access to the live system, and keeping your provider keys and encryption key somewhere safe.
You get a written deployment guide covering all of it, and we set the first one up with your team rather than emailing you instructions.
Plainly
What we do not have.
Vendors usually leave this part out, which is exactly why it is worth saying.
- We hold no SOC 2 report and no ISO 27001 certificate. If your bank or your regulator asks for one, we cannot produce it today.
- No independent security firm has tested the platform. You are welcome to hire one, and because you get the source code you do not need our permission.
- We are not a financial institution and hold no licence. We never touch customer money, settlement, or identity documents, so every regulatory relationship stays yours.
What we offer instead is the thing most vendors will not: the whole source code, so anyone you trust can check every claim on this page themselves.
The detail
For whoever you ask to check us.
If you bring in a developer or a security consultant, this is the version for them. Each line corresponds to something in the source code you receive.
| Area | Implementation |
|---|---|
| Secrets at rest | AES-256-GCM field encryption, key supplied as deployment configuration |
| Password hashing | Argon2id, with delegating encoder so migrated hashes stay valid and upgrade on first sign in |
| Provider credentials | Deployment environment only, never persisted, never exposed through any API |
| Card data | PAN and CVV fetched at reveal time, never persisted, logged or cached |
| Access control | Role and permission model on staff accounts, enforced server side |
| Sensitive operations | Step up re-authentication on settings, ledger and card administration |
| Audit | Administrative actions recorded transactionally with actor and timestamp |
| Accounting | Double entry ledger, balances derived from postings, nightly internal re-proof |
| Provider reconciliation | Nightly comparison of every live card against the provider |
| Money operations | No automatic retry on timeout, pending operation resolved from provider record |
| Abuse controls | Per customer rate limits on card creation, funding, freeze and reveal |
| Two factor | TOTP, seeds encrypted at rest |
Reporting
Found a problem?
If you think you have found a security problem in the platform, write to security@wanzalabs.com. You get an acknowledgement within one working day and a proper assessment within five. We will tell you what we found either way, including when we conclude there is nothing to fix.
Please give us a reasonable window to get a fix to the operators running the platform before you publish anything. We will not threaten anyone for reporting in good faith.