Testing and sandbox
Test your Sandbox and Development environments before you launch to production.
Sandbox environment
| Value | Description |
|---|---|
| Base URL | Provided by your system in admin. Later under API → URLs → Sandbox |
| Marker | Use your Merchant Test Key as merchant_key |
| Effects | No real money moves; transactions appear in the admin panel marked as test. |
Card scenarios
All sandbox card scenarios use 4111 1111 1111 1111 with any 3-digit CVV; the expiry date selects the scenario:
| Expiry | Outcome |
|---|---|
01/38 | Success (immediate settle). Use this for recurring initialization. |
02/38 | Decline by processing. |
05/38 | 3DS challenge → success. |
06/38 | 3DS challenge → fail. |
Invalid Luhn (e.g., 1111 2222 3333 4444): rejected at form validation with Bad Request. Brand of card does not support.
note
For testing recurring, you must use 01/38 for the initial sale. Other expiries do not return a recurring token.
Webhook testing
Your notification_url must be reachable from the public internet for callbacks to arrive. While developing locally:
- Use RequestBin / webhook.site to capture and inspect raw callback payloads (good for one-off debugging, not for actual integration).
- Trigger a manual resend from admin panel → Components → Callback Response Management.
Common test recipes
| Goal | Steps |
|---|---|
| Successful sale | Quickstart payload + card 4111... / 01/38. |
| 3DS success | Same payload, expiry 05/38. Verify you receive two callbacks: type=3ds, status=success then type=sale, status=success. |
| Decline | Expiry 02/38. Verify type=sale, status=fail, reason="Declined by processing.". |
| Two-step (DMS) | Use a MID configured for DMS. The first callback is type=sale, status=success, order_status=pending (funds held, not captured). Then call /payment/capture and observe type=capture, status=success, order_status=settled. |
| Refund | After a settled sale, call /payment/refund. Observe type=refund, status=success. |
| Recurring | Initial sale with recurring_init=true (expiry 01/38). Capture recurring_init_trans_id + recurring_token from callback. Call /payment/recurring to charge again. |