Sandbox Test Cards
Use these card details only with SaySwitch test credentials:
Authorization: Bearer sk_test_...Test cards only: These cards cannot complete live or real-money transactions. Never use real card details in the sandbox.
SaySwitch has two separate card-testing environments:
- Normal NGN card-payment sandbox.
- Recurring-payment authorization sandbox.
A normal card-payment sandbox card may not work for recurring-payment authorization. Always use a card from the section matching the payment flow being tested.
Normal NGN Card-Payment Test Cards
Use these SaySwitch sandbox cards for normal NGN S2S card payments through:
POST https://backendapi.sayswitchgroup.com/api/s2s/v1/transaction/initialize| Brand | Card number | Expiry month | Expiry year | CVV | Expected result |
|---|---|---|---|---|---|
| Mastercard | 5204730000002449 | 12 | 35 | 244 | Successful payment |
| Visa | 4005555555000009 | 05 | 37 | 000 | Successful payment |
Encrypt the selected card before initializing the payment. Use the same unique reference for the encryption and initialization requests. The sandbox simulator processes the payment without contacting a real bank or moving money.
These cards are for normal NGN S2S payments only. Do not use them to authorize a recurring payment.
See NGN S2S card payments for the complete payment flow and S2S sandbox testing for request examples. For USD integrations, follow the separate USD S2S card payment guide.
Choose a Test Status
You may include an optional status field in a valid sandbox initialization request:
{
"status": "success"
}| Value | Sandbox behavior |
|---|---|
success | Processes the transaction through the normal successful-payment flow. |
failed | Declines the test payment and returns Test payment declined (simulated). |
pending | Creates a pending transaction that is scheduled to resolve successfully after the sandbox delay, which is about 20 seconds by default. |
The card payload must still be complete, encrypted, and valid when you choose a status. An unsupported status is rejected with HTTP 400. Always verify the transaction instead of relying only on the initialize response or a timer.
Recurring-Payment Sandbox Cards
Use these recurring-payment sandbox cards only in the SaySwitch-hosted checkout opened from the authorization_url returned when you initialize a sandbox subscription.
Do not use these cards for normal S2S payments, live transactions, production subscriptions, or direct calls to any API outside SaySwitch.
Successful Authorization
| Brand | Card number | Expiry | CVV | PIN | OTP | Expected result |
|---|---|---|---|---|---|---|
| Mastercard | 5123450000000008 | 01/39 | 100 | 1111 | 123456 | Successful authorization |
| Verve | 5060990580000217499 | 03/50 | 111 | 1111 | Not required | Successful authorization |
Recurring Authorization Failure Scenarios
| Brand | Card number | Expiry | CVV | PIN | OTP | Expected result |
|---|---|---|---|---|---|---|
| Verve | 5061830100001895 | 01/40 | 111 | 1111 | 123456 | Issuing-bank timeout |
| Verve | 5060990580000000390 | 03/50 | 111 | 1111 | 123456 | Insufficient funds |
Use these failure scenarios to confirm that your integration handles an unsuccessful subscription authorization without activating access for the customer.
Recurring Test Flow
- Authenticate with your SaySwitch test secret key.
- Create a test customer and an NGN recurring plan.
- Initialize a subscription with a unique
Idempotency-Key. - Open the returned
data.authorization_urlin a browser. - Enter a recurring-payment sandbox card from the tables above.
- Enter the PIN and OTP when the hosted checkout requests them, then accept the recurring-payment consent.
- Retrieve the subscription and confirm its status after checkout.
- Confirm that your test webhook endpoint receives the expected lifecycle event.
An initial successful card authorization confirms only the customer-authorized first payment and card setup. It does not certify every future unattended renewal scenario. Certification of some unattended recurring sandbox scenarios is still in progress. If a scheduled charge requires additional customer authentication that cannot be completed off-session, the charge may fail and the subscription may move to past_due.
Continue with the Recurring Payments overview, recurring sandbox guide, or initialize a subscription.
Security Rules
- Use test secret keys only.
- Never use sandbox cards with live credentials.
- Never store PAN, CVV, or PIN.
- Never log raw card data.
- Encrypt normal S2S card details using the documented card-encryption flow.
- Enter recurring card details only on the SaySwitch-hosted authorization checkout.
- Do not collect recurring card details through your own backend for the subscription flow.
- Collect an OTP only during the active customer-authorized checkout session.
- Keep secret keys on your server and out of browser JavaScript.
- Use a unique reference or idempotency key for each new test.
- Verify the final transaction or subscription status before providing value to a customer.