FoxReload Order Flow Explained — Active, Paid, Processing, Completed, Failed

If you are integrating FoxReload at scale, you need to model order state carefully on your side: customer support and reconciliation both hinge on understanding what each status means and when transitions happen. This article walks through the full FoxReload order flow as it actually runs in production.

The six statuses

Every order moves through up to six statuses. Most happy-path orders complete in under 60 seconds.

The state machine is strictly forward-only. A completed order cannot revert. Cancelled orders carry a cancelReason: payment_failure, payment_expiration, user_request, or null.

1. Creating an order

Call POST /api/orders with a JSON body listing items by itemId (the product id from the catalog), quantity, and optionally totalPrice and a note object for products that require extra data such as a player ID.

curl -X POST "https://public-api.foxreload.com/api/orders" \
  -H "X-API-Key: YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      {
        "itemId": "product_01krgfgww8eth9xvvysd6y7r4j",
        "quantity": 1,
        "note": {"player_id": "123456"}
      }
    ],
    "isMock": false
  }'

A successful call returns HTTP 201 with the order object and status: "active". Orders draw from your account balance; if the balance is too low you receive a BalanceNotEnough error. There is no sandbox environment — use "isMock": true to receive fake codes for testing without spending real balance.

2. Paying an order

Once the order is active, call POST /api/orders/{order_id}/pay to create an external payment for it. The request body accepts an optional paymentProvider (pally, yookassa, or tbank; default pally), paymentMethodType (e.g., bank_card, sbp; default sbp), and paymentReturnUrl. The response includes a confirmationUrl to redirect the customer.

When payment is confirmed the order moves to paid, then almost immediately to processing.

3. Processing → completed

The order is dispatched to the supplier. When delivery succeeds, the status becomes completed and each items[].externalData array is populated with the delivered codes or activation data. Per-item errors, if any, appear in items[].error.

Poll GET /api/orders/{order_id} to check progress. FoxReload does not push webhooks — polling is the supported pattern.

curl "https://public-api.foxreload.com/api/orders/{order_id}" \
  -H "X-API-Key: YOUR_API_KEY"

A practical polling loop: check every 5 seconds for up to 2 minutes, then every 30 seconds for up to 10 minutes. If still not completed or cancelled/failed after that, alert your operations team.

4. The cancelled and failed paths

When an order ends in cancelled or failed, your balance is not debited (or is refunded if it was debited before the failure). Update your UI and notify the customer accordingly.

5. Test orders

Pass "isMock": true in the order body to receive realistic but fake codes. The order goes through the full status lifecycle so you can test your polling and delivery logic without using real balance or real supplier stock. There is no separate sandbox URL — mock orders go to the same https://public-api.foxreload.com base URL.

Ready to integrate? Sign up at foxreload.com — API keys are created in Dashboard → API and can be restricted to an IP allowlist for security.