Verification Sandbox Testing
The sandbox environment lets you exercise account verification without calling real providers. A deterministic sandbox provider resolves every request based on the last digit of the account identifier (bank account number or mobile-money number), so you can reproduce each outcome — verified, name mismatch, not found, and the asynchronous pending flow — on demand.
All examples use the current, unified verification endpoint POST /accounts/validate (poll with GET /accounts/validate/{id}). The older /verification/mobile and /verification/bank-account endpoints are deprecated — see Mobile Number Verification and Bank Account Verification.
Sandbox verification is available for both mobile_money and bank_account account types across Kenya (KEN), Rwanda (RWA), Ghana (GHA) and Tanzania (TZA). The same last-digit rules apply to every market and both account types.
How scenarios are triggered
Set the last digit of accountIdentifier to the scenario you want:
Default behaviour: any identifier whose last digit is not 3, 5, 7 or 9 resolves to verified.
Mobile Number Verification
Send accountType: mobile_money and put the recipient’s mobile number in accountIdentifier. bankCode is not required for mobile money.
Example: Verified (Kenya)
Response (200 OK):
Example: Name mismatch (Ghana)
Response (200 OK):
Test numbers by country
Change the final digit to select the scenario (see the table above). The prefixes below are representative sandbox numbers; only the last digit is significant.
Bank Account Verification
Send accountType: bank_account, put the account number in accountIdentifier, and include bankCode. In sandbox the bankCode is not validated against a real institution, so any non-empty value works.
Example: Verified (Tanzania)
Response (200 OK):
Example: Account not found (Kenya)
Response (200 OK):
Test account numbers by country
Only the last digit is significant; use any bankCode.
Polling pending validations
Any identifier ending in 7 returns status: pending with an id. Poll until you observe the terminal state:
Because the sandbox provider is stateless, a pending scenario stays pending — it is intended to let you exercise the poll loop and your handling of the asynchronous case, not to simulate an eventual success.
Important notes
- Sandbox only. These rules apply only in the sandbox. Production validation uses real account numbers/phone numbers and real providers.
- Deterministic. The same identifier always produces the same result (including the generated name for the
5/9mismatch scenarios), so results are stable across retries and consistent with the validation cache. - Name matching. Supply
accountHolderNameto exercise thename_mismatchbranch. Without it, a5/9identifier still returnsname_mismatchusing a generated name. - Country codes. Use 3-letter ISO country codes in
country(KEN,RWA,GHA,TZA) — these are country codes, not currency codes.
Next steps
- Payout Sandbox Testing — simulate payout outcomes end to end.
- Payout Beneficiaries — how verification feeds beneficiary creation.
- Verification API Reference — full request/response schema for
/accounts/validate.