Sandbox
Sandbox and live: the differences
Test mode runs the same code as live mode. Every intentional difference, with its value and its reason.
Test mode is not a mock of AdProMaxPay: it is the same API, the same validation, the same state machine, the same events and the same webhooks. Only the payment providers are simulated, so that no real money moves. A request that works in test mode works in live mode, and a request refused in live mode is refused in test mode.
The differences below are deliberate. Each one keeps you from waiting, or from spending real money.
What differs
| Test mode | Live mode | Why | |
|---|---|---|---|
| Money | None moves; nothing reaches a bank | Real payments | The sandbox is for building |
| Keys | apx_sk_test_…, apx_pk_test_…, once your email is verified | apx_sk_live_…, apx_pk_live_…, once your account is activated | Two modes, two sets of data |
| Card payment page | A simulated page marked TEST, which takes only the test cards | The secure payment page of our card partner | A real card never enters test mode |
| 3-D Secure | A simulated page where you choose to approve or fail | Your customer's bank | So you can test both outcomes |
| Cash codes | Paid with Simulate payment or the test helpers; no agent accepts them | Paid in cash at a partner payment agent | No real cash for a test |
| Cash status checks | Every 10 seconds, and at once after a simulated payment | Every 2 minutes | A test confirms in seconds |
| Funds become available | 120 seconds after a payment succeeds | After the holding period set when your account is activated | You see the whole balance cycle in a test |
| Our fees | A placeholder taken from each succeeded payment: 2.5% for a card, 3% for cash | The fees announced with activation | Your test balance moves like a live one; the figures are not our prices |
| Card refunds | Complete within seconds | Can stay pending for longer while the card network carries them out | The simulated provider answers at once |
| Test helpers | Available | Refused: 403, test_mode_only | Simulating a payment has no meaning in live mode |
| Rate limits, per minute | All requests 600, writes 150, payment creations 60, searches 30 | All requests 1,200, writes 300, payment creations 120, searches 30 | Live traffic gets the larger share |
| Daily cap | 10,000 requests and 1,000 payment creations per day, Morocco time; then 429, test_daily_cap_reached | None | Protects the shared sandbox |
| Request logs | Kept 30 days | Kept 90 days | Test traffic is short-lived |
Rate limits are the defaults; yours may differ. The dashboard's API limits page shows the values that apply to you, and lets you ask for more: see Rate limits.
What is the same
- Validation: the same fields, the same checks, the same error codes and messages.
- Minimums: 100.00 MAD for cash, 1.00 MAD for a card, in both modes. A cash payment of 50.00 MAD is refused in test mode exactly as in live mode.
- Life spans: a card payment page lasts about 30 minutes; a cash code about three days (its
expires_atsays); a checkout session 24 hours unless you set less. - Idempotency: the same required keys, the same 24-hour replays.
- Events and webhooks: the same types, the same payloads, the same signatures, the same retries.
- Statuses: a payment intent goes through the same statuses, and succeeds once.
- Refunds: card payments can be refunded; cash payments cannot, in both modes.
Test and live never mix
- A test key sees test objects only; a live key sees live objects only. Reading a test object with a
live key answers
resource_missing, with a hint that the object exists in the other mode. - Webhook endpoints belong to one mode. Create your live endpoints when you go live.
- Test objects carry
"livemode": false; live objects"livemode": true.