OMNO provides a single production environment. You test by processing real API calls against fake PSPs that OMNO configures on your production account.
- Test transactions are not charged or billed.
- Fake PSPs return predefined statuses and controlled responses so you can simulate each outcome.
- When testing is finished, OMNO removes the fake PSPs from your configuration.
Contact OMNO to have fake PSPs configured on your account. In the Dashboard the fake providers appear under Payment Providers → Add Provider → Authorize, for example:
- Fake Card Pay-In
- Fake APM Pay-In
- Fake Card Pay-Out
- Fake APM Pay-Out
After authorization, make sure each provider is configured in the Router and active.
[TBD: exact process / contact for requesting fake PSP setup]
A transaction processed by a fake PSP has merchantPspId / processorPspId equal to the fake PSP ID provided by OMNO. Check this field (via webhook payload or the GET transaction endpoint) before touching balances.
⚠️ Warning: Never credit or debit real player balances for transactions processed by a fake PSP.
The fake PSP decides the outcome from a controlled input value: the CVC for cards, or a 3-digit value in the recipient field for APMs.
Card — use these test cards (fake PSP only):
| Purpose | Card number | Expiry | CVC |
|---|---|---|---|
| Success | 4539148803436467 | 12/29 | 123 |
| Failure (before PSP) | 6011111111111117 | 12/29 | 123 |
| 3DS challenge | 378282246310005 | 12/29 | 123 |
Cardholder name can be any value. For 3DS, you are redirected to a simulated provider page where you choose the final outcome.
Card decline simulation by CVC:
| CVC | Result |
|---|---|
| 001 | General card decline |
| 004 | Card expired |
| 005 | Card inactive or blocked |
| 011 | Insufficient funds |
| 013 | Invalid card number |
| 015 | CVV check failed |
| 026 | Transaction marked as fraud |
| 033 | Provider timeout |
| 034 | Provider rejected request |
| 040 | Service unavailable |
APM — the fake APM PSP uses the same 3-digit codes as card declines, but the value is entered in the recipient field instead of the CVC.
Crypto — [TBD: how to simulate success/decline/pending/timeout for crypto in the Cashier]
- APM — provide the 3-digit outcome code in the recipient field, as above.
- Crypto wallet — [TBD: how to simulate crypto wallet outcomes for Direct Link]
- Payout — use the payout decline codes below.
Card and APM behave as in the Cashier: CVC codes for cards, recipient-field codes for APMs.
Payout decline simulation:
| Code | Result |
|---|---|
| 002 | Transaction not allowed |
| 004 | Card expired |
| 005 | Card inactive |
| 011 | Insufficient funds |
| 013 | Invalid card number |
| 016 | Invalid amount or currency |
| 026 | Marked as fraud |
| 033 | Transaction timeout |
| 034 | Rejected by provider |
| 040 | Service unavailable |
For payouts requiring manual approval, exercise both confirm and reject.
| Outcome | How to simulate |
|---|---|
| Success | Success card / valid input (see above). |
| Decline (by PSP) | CVC / recipient decline codes above. |
| Failure (before PSP) | Failure card, or routing/provider restriction. |
| Pending → async final status | [TBD: how to simulate a pending-then-async-final outcome per flow] |
| Timeout | Card CVC 033, payout code 033. [TBD: confirm timeout simulation for APM/crypto] |
| 3DS (card) | Card 378282246310005 (see above). |
ℹ️ Note: Failures occur before the PSP (routing or provider restrictions); declines are returned by the PSP layer; success depends on valid input and routing eligibility.
These steps are the testing-and-go-live part of How Onboarding Works.
- OMNO has removed the fake PSPs.
- Live PSPs are configured and routers are verified.
- Webhook handling is verified, including idempotency and out-of-order statuses.
- Balance-crediting logic ignores fake PSP IDs.
- Final status is taken only from webhooks or the GET transaction endpoint.