Sandbox Test Cards

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:

  1. Normal NGN card-payment sandbox.
  2. 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
BrandCard numberExpiry monthExpiry yearCVVExpected result
Mastercard52047300000024491235244Successful payment
Visa40055555550000090537000Successful 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"
}
ValueSandbox behavior
successProcesses the transaction through the normal successful-payment flow.
failedDeclines the test payment and returns Test payment declined (simulated).
pendingCreates 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

BrandCard numberExpiryCVVPINOTPExpected result
Mastercard512345000000000801/391001111123456Successful authorization
Verve506099058000021749903/501111111Not requiredSuccessful authorization

Recurring Authorization Failure Scenarios

BrandCard numberExpiryCVVPINOTPExpected result
Verve506183010000189501/401111111123456Issuing-bank timeout
Verve506099058000000039003/501111111123456Insufficient funds

Use these failure scenarios to confirm that your integration handles an unsuccessful subscription authorization without activating access for the customer.

Recurring Test Flow

  1. Authenticate with your SaySwitch test secret key.
  2. Create a test customer and an NGN recurring plan.
  3. Initialize a subscription with a unique Idempotency-Key.
  4. Open the returned data.authorization_url in a browser.
  5. Enter a recurring-payment sandbox card from the tables above.
  6. Enter the PIN and OTP when the hosted checkout requests them, then accept the recurring-payment consent.
  7. Retrieve the subscription and confirm its status after checkout.
  8. 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.