Compliance & security
What the platform enforces in code, and what needs a contract.
Two questions get asked together and have very different answers. What the platform does on every request is on this page, verifiable against the API you are already calling. Certifications, licences and data residency are contractual, they change per market and per contract, and they come from enterprise@wajub.com rather than from a documentation page.
What runs on every request
| Guarantee | Mechanism |
|---|---|
| A secret key cannot be read back freely | Showing one again in the Dashboard asks for a security verification code |
| A revoked or expired key stops working immediately | 401, checked on every request |
| A private key cannot be used from a browser | A private key used from a browser is refused with 403, and the owner is emailed |
| A leaked key can be bound to your servers | Per-key IP allow-list, exact address or CIDR |
| A key can be narrowed to what it needs | Restricted keys, fourteen resource scopes, read and write |
| A webhook proves it came from Wajub | HMAC-SHA256 over timestamp and body, 300 second tolerance |
| Sandbox cannot reach live data | Sandbox and live share no data; the key you authenticate with decides the environment |
| A retry cannot charge twice | Idempotency-Key: a payment, transfer or refund is never created twice for one key |
Security best practices walks through each of those from the integrator's side, including rotation without downtime.
A key in a browser is reported, not just refused
A private key used from a browser is refused with 403, and the owner is emailed. Treat that
email as a leak notification and rotate, because the request reached us with a valid key.
Card data and your PCI scope
Card numbers never reach Wajub or your servers. The payer types the card into the card provider's own secure fields or payment page, inside Hosted Checkout, Wajub Components or the mobile SDKs, and Wajub only receives what the provider hands back, such as a token. Your servers only create the payment and hand the payer a checkout.
Raw card data is refused
A card number, security code or card PIN sent to POST /payments/{id} is refused with 422 and error_code: raw_card_data_not_accepted, before anything is
processed. Sandbox accepts only the cards listed in
Test scenarios, and refuses any other number with
error_code: sandbox_test_card_required.
Wajub never stores full card numbers. A saved payment method is a token, never a number you could charge elsewhere.
Deleting a payer
DELETE /customers/{id} is a real erasure request, not a status change. It anonymises the record
and deletes it.
| Data | What happens |
|---|---|
| The customer's details | Erased: name, contact details, addresses and saved payment methods |
| Transactions and invoices | Kept for your accounting, with the customer's details replaced by a pseudonym |
| Recorded events and delivered webhooks | Konsole, GET /events, a replay and a resent webhook show the anonymised record |
Tax IDs are the one exception: they are kept when one of them has been verified, because a verified tax ID is identity evidence, and the obligation to keep it outlives the request.
The operation is idempotent
Repeating the call on a customer already erased answers the same 200.
What already left Wajub cannot be called back: a webhook your endpoint received, or a payload a
connected platform stored on its side, is yours or theirs to erase. With X-Sync, the call is
refused with 403: erasing a customer is the merchant's decision, not a platform's.
Transactions themselves are not deleted, which leaves your books intact. The wallet or account number a payment was made with stays on that payment: it is part of the financial record that has to be kept.
Sandbox and live are separate systems
The key you authenticate with decides the environment. Sandbox and live share no data, even for keys of the same team.
The practical consequences show up as 404, not as a permission error. A live payment id looked up
with a test key does not exist, and the reverse is equally true. Nothing crosses: not customers,
not webhook endpoints, not events.
Verification gates live money
A team that has not passed compliance verification takes no live payment at all, whichever
provider would carry it, your own connected providers included. Every live
payment answers 402 with error_code: merchant_not_verified until the verification is approved;
the next attempt after the approval goes through. Payouts answer 422 until then. Sandbox keeps
working unchanged. Limits and quotas describes the account limits verification
unlocks.
Reporting a vulnerability
Send it to security@wajub.com. The API, Konsole, the SDKs and this documentation site are all in scope. There is no public bounty programme, and disclosures are credited in the changelog when the reporter wants to be named.
Questionnaires, certifications and residency
Anything that belongs in a contract is answered by a person, not by this page: certification status and certificates, penetration test reports, data processing agreements, residency commitments, per-market licensing and the regulated partners behind each corridor.
Write to enterprise@wajub.com with the questionnaire you need completed.