Testing

When integrating a payment gateway, you will need to test your implementation before going live. We've got test credentials for you to test a variety of use cases and allow you to simulate both successful and failed scenarios.

🚧

Using Test Credentials and Mock Data

These credentials and data work exclusively in Test Mode. If you require mock data to test a specific flow or feature, please contact our support team.

Cards

Below are card details to use to make a mock payment. To ensure accurate testing, please select the appropriate test card based on the authorization model (PIN, 3DS, AVS, and NoAuth) required for your card transaction.

Each card triggers a specific authorization flow, essential for replicating the different direct card charge scenarios.

📘

Test Mode Transaction Receipt Email Delivery

In test mode, transaction receipt emails are sent to your business email, not your customers'. To send test receipts to customers, please contact support.

Successful Payments

Here is a list of cards to simulate a successful payment. These cards can only be used for testing Successful payments in the test environment.

Failed Payments

Here is a list of cards to simulate a failed payment. These cards can only be used for testing failed payments in the test environment.

Testing Payment on Checkout

To properly render checkout on your local environment, you'd need to route your app to localhost:<preferred-port> e.g. localhost:3000. Pointing your app to an IP address e.g. 127.0.0.1:3000 would result in errors.

Credentials are listed in the card, and mobile money sections to help you test your checkout integration.

OTPs

Any OTP passed in test transactions will pass validation. However, you can use these special OTPs to mock specific error scenarios:

• WRONG OTP: 5548
• INSUFFICIENT FUNDS: 6648

ℹ️

Testing Tip

These special OTPs will only work (simulate failed payments) when the OTP validation happens directly in our payment modal. If you are redirected to our OTP validation page, you'll need to use one of the test cards designated for failed payments.

Bank Accounts

Successful Payments

Bank account details to use to mock a successful payment.

ℹ️

Testing Tip

If you need more Access Bank test account numbers, you can keep incrementing the last digit of the test account numbers above to get new test account numbers, right up to 0690000041.

Blacklisted Accounts

A blacklisted account indicates that the account has been flagged due to suspicious activity or non-compliance with regulations. When an account is blacklisted, transfers to that account are blocked to safeguard users from potential risks.

Common Reasons for Blacklisting:

• Fraudulent activity (e.g., money laundering or unauthorized transactions).
• Violation of terms (e.g., using the service for prohibited activities).
• Security concerns (e.g., account compromise).
• Regulatory compliance issues (e.g., sanctions or anti-money laundering regulations).

Blocking transfers to blacklisted accounts helps ensure compliance and protect users from fraud.

Testing Blacklisted Accounts in Your Application

To simulate a blacklisted account and handle the expected 400 error response, you can use the following test credentials in test mode:

You’ll get a response similar to this:

{
   "status": "error",
   "message": "Payout was made to a blacklisted account number",
   "data": null
}

Mobile Money

Successful Payments

To mock a successful mobile money payment, you can use any mobile number and the OTP 123456. To mock a WAVE transaction, you can use any mobile number.

Failed Payments

You can make mocked failed transactions for your integration tests using any of the following numbers below. Update the country code of each number to match the code of your customer's number.

Testing Transfers

🚧

IP Whitelisting

In order to conduct a successful integration test, it's important to ensure that you whitelist the IP addresses of the servers making the transfer API calls.

When testing a transfer, you can use any of our provided test accounts. By default, such transfers will always remain in a PENDING state. You can force transfers to behave differently by using a special kind of transaction reference when creating the transfer.

• To mock a successful transfer: Make sure your reference ends with _PMCK (for example, "dfs23fhr7ntg0293039_PMCK").
• To mock a failed transfer: Make sure your reference ends with _PMCK_ST_F (for example, "dfs23fhr7ntg0293039_PMCK_ST_F").

📘

Testing Tip

By default, the status of the mocked transfer will only be updated after 10 minutes.

• To change the time delay: append DU_{minutes} to your transaction reference.
  For Example

  • A transfer with a reference of "dfs23fhr7ntg0293039_PMCK" will succeed after 10 minutes.

  • A transfer with a reference of "dfs23fhr7ntg0293039_PMCKDU_1" will succeed after 1 minute.

  • A transfer with a reference of "dfs23fhr7ntg0293039_PMCK_ST_F" will fail after 10 minutes.

  • A transfer with a reference of "dfs23fhr7ntg0293039_PMCK_ST_FDU_1" will fail after 1 minute.

Capitec

Here are test credentials for simulating different scenarios. To mock a successful transaction, any value can be passed as the account number/phone number.

Bill Payments

To purchase airtime, the customer_id must begin with the international code (+234) followed by a valid Nigerian mobile operator prefix (e.g., 705, 803, 708). For a complete list of supported prefixes across MTN, Glo, Airtel, and 9Mobile, see the Nigerian MNO Prefixes Guide.

Use the following credentials to test your bill payment integration. These credentials are intended for testing only and are not valid in the production environment.

BVN Credentials

There are two main cases when verifying your customer's BVN:

• Case 1: New customer consent flow i.e. initiating the customer's content.
• Case 2: Existing consent flow i.e Fetching previous consent.

Use these mock credentials to test your integration for verifying users BVN information;