Skip to main content

Sandbox testing

The sandbox at https://sandbox.alixpay.com behaves like production — same contract, same error codes, same envelope — but no real money moves. Build against it first.

It also lets you decide how an order ends.

Forcing an outcome​

A real payout settles when the payment rail says so. On the sandbox you settle or fail an order yourself, which is what lets you exercise the FAILED branch of your integration at will:

JSON
{ "orderId": "acme-1042", "outcome": "FAILED" }

Scan-to-pay accepts SUCCESS, FAILED, and PROCESSING; cashout accepts SUCCESS and FAILED. SUCCESS and FAILED are terminal, so they also fire the order webhook — if the order was created with a webhookSecretKey, this is how you test your callback handler end to end.

These endpoints do not exist in production.

A full test pass​

  1. Get an access token for a test user.
  2. Submit that user's KYC and wait for VERIFIED.
  3. Fund check: Get your fund — the sandbox fund is pre-loaded.
  4. Quote, then create an order with a webhookSecretKey.
  5. Force it to SUCCESS and assert your webhook handler settled it.
  6. Create a second order and force it to FAILED. Assert you refund the customer and that the fund was credited back — check the ledger.
  7. Replay the create call for an existing orderId and assert you handle DUPLICATE_TRANSACTION_ID by fetching rather than by creating a second order.

Step 7 is the guard against double payment — give it the same attention as the happy path.

Going live​

Nothing changes but the base URL, your credentials, and the IP allowlist. Have the production IPs you will call from registered with AliX before you cut over; an unregistered IP answers PARTNER_IP_NOT_ALLOWED however valid the token is.

On this page