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 gives you something production cannot: the ability to decide how an order ends.

Forcing an outcome​

A real payout settles when the payment rail says so, which makes the FAILED branch of your integration almost impossible to exercise. On the sandbox you settle or fail an order yourself:

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 one people skip, and it is the one that double-pays customers in production.

Going live​

Nothing changes but the base URL, your credentials, and the IP allowlist. Make sure the production IPs you will call from are registered with AliX before you cut over — otherwise every request comes back PARTNER_IP_NOT_ALLOWED, with a perfectly valid token.

On this page