Testing & Go-Live

Going Live

Move a tested integration from the sandbox to production

Going live changes less than you might expect. The URL stays the same, and the requests stay the same. What changes is the credentials you load, and a few things that only exist in production.

Before you ask for production access

Make sure you’ve tested:

  • The happy path for each product you use: Your First Payment and Your First Payout.
  • The approval flow for each market, using the Approval flow column on its country page and the matching trigger numbers.
  • Failures: your integration shows a sensible message for each failure your markets can produce.
  • Webhooks: your endpoint verifies signatures, handles duplicate deliveries, and updates your records from transaction.* and payout.* events. See Webhooks.
  • Duplicate references: resending a payout with a used merchantReference returns 409 Conflict, and your code treats that as “already sent”, not as a failure.

Then ask your account manager to enable production access.

What to change

1. Load your production credentials. Swap in your production client_id, client_secret and merchantId. Keep them in a separate secret store from the sandbox set, and never fall back to production credentials when a sandbox call fails. Because the URL is the same, the credentials are the only thing that decides whether money moves.

2. Subscribe a production webhook endpoint. Webhook subscriptions belong to a merchantId, so the endpoint you set up for the sandbox won’t receive production events. Add an endpoint for your production merchant, subscribe it to the same events, and verify signatures with its own secret. Check paymentAttributes.merchant_type is "real" before you treat an event as a real payment.

3. Check your network rules. Your servers need outbound HTTPS to api.crisscross.money. If you allowlist incoming webhook traffic, ask your account manager for the current source IP ranges.

4. Fund your payout balance. Production payouts draw on your real CrissCross balance. See Funding Your Payout Balance.

5. Don’t reuse sandbox data. Bank codes, rates and rate limits can all differ in production. Fetch bank codes at runtime rather than hardcoding them, because some sandbox codes are placeholders that production rejects.

Run a live pass for each market

The sandbox can’t show you what the market does: the operator’s prompts and timeouts, payer limits, settlement timing, or how strictly names are matched. Before you launch a market, your solutions engineer runs a small-value live payment with you on production credentials.

Check that:

  • the payer gets the prompt, OTP or redirect you expect for that operator
  • the payment reaches COMPLETED and your production webhook receives it
  • a refund or payout, if you use them, reaches the recipient
  • the amounts in your records match what the payer paid

After launch