Testing Overview | CrissCross

Every CrissCross integration is tested in the sandbox before it processes real money. The sandbox runs on the same endpoints as production and behaves the same way from your code’s point of view — but no prompt reaches a real handset, no operator is contacted, and no funds move.

This section is the testing plan: which endpoints to call, what data to send to produce a given outcome, and what you should see back. Start with Your First Payment or Your First Payout, then work through the approval flows your markets use — scenarios are grouped by flow rather than by error code, because the flow is what changes the calls you make. Afterwards it doubles as a reference you can dip into for a single scenario.

Before you start

You will need:

Sandbox client_id, client_secret and merchantId.
Network access to https://api.crisscross.money.
An HTTPS endpoint for webhooks. You can complete the first test without one by polling, but every scenario after that is easier to observe with webhooks running. See Webhooks.

How the sandbox works

There is no separate sandbox URL. Every request goes to https://api.crisscross.money, and your credentials decide the environment — a sandbox client_id and client_secret put you in the sandbox, production credentials put you in production. This means the only difference between your test and live integration is which secret you load.

Sandbox is enabled by default on every test merchant account. You will have been given a sandbox client_id, client_secret and merchantId during onboarding, alongside the production set.

This section covers Collect and Payouts. Exchange uses the same URL and the same credential model, but its sandbox is a separate profile with its own dashboard login, and your account manager funds its balances. See Exchange Sandbox.

Because the URL is identical, a misconfigured secret is the difference between a test and a real payment. Keep the two credential sets in separate secret stores, and never fall back to production credentials when a sandbox call fails.

How scenarios are triggered

Sandbox outcomes are deterministic — you choose what happens, by the value you put in one field:

What you are testing	Field	How it matches	Example	Full list
Collect — mobile money	`paymentDetails.payerMobileNumber`	The whole number, normalised to E.164	`0970000005`	Mobile Money Trigger Numbers
Payouts — mobile money	`recipient.phoneNumber`	Last two digits	`254723993112`	Payout Trigger Endings
Payouts — bank transfer	`recipient.accountNumber`	Last two digits	`0123456712`	Payout Trigger Endings
Account validation	The account number validated	Last two digits	`0123456712`	Verification Sandbox Testing

Anything not listed succeeds, so you reach for a trigger deliberately — and conversely, randomly generated payout test data can land on a trigger ending by accident.

Methods with no trigger table test against the provider’s own environment instead: same calls, test data from your solutions engineer.

What the sandbox does not prove

The sandbox tests your integration, not the market. Operator prompts and timeouts, payer limits, settlement timing and name matching all vary by market and only show up live. Before launching a market, your solutions engineer runs a small-value live pass with you on production credentials. See Going Live.