Skip to main content
There is no request field for “test mode”. Mode is a property of which API key authenticated the request. Each tenant is issued a live credential set and, separately, a test set. Each is bound to its own tenant record with its own is_test flag. AptaPay resolves mode server-side from the authenticated key; it is never read from the body.
If your request body includes a mode field that disagrees with the key you signed with, AptaPay rejects it with 400 mode_mismatch rather than silently honouring either. This is deliberate — a body field that could flip a live charge to test would be a way to fake settlements.

​
What differs between modes

​
Test mode is not a sandbox

This is the point most integrations get wrong.
Eversend has no sandbox. “Test mode” for AptaPay means a real provider account with a low-balance wallet, not a consequence-free environment. Test-mode transactions move real money in small amounts.
Consequences for how you use it:
  • Do not load-test against test-mode credentials. You will drain a real wallet and hit real provider rate limits.
  • Expect the ceiling to be low. Test-mode amounts are capped at 500.00 — that is 50000 minor units in a 2-decimal currency, or 500 in UGX, RWF, XAF and XOF.
  • Failures in test mode are real provider failures, which makes them a genuinely good rehearsal for your error handling.
For testing your own integration logic — signing, retries, webhook handling — see Testing.

​
Keeping the two apart

Use separate secret storage per mode and select by environment, never by a runtime flag that a request could influence:
config.ts
Every webhook carries data.is_test_mode, so your handler can assert the mode matches the environment it is running in and refuse anything unexpected.