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`.

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.

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.

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.