> ## Documentation Index
> Fetch the complete documentation index at: https://flutterwaveinc.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing

> Learn how to test your integration.

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.

<Warning>
  **Using Test Credentials and Mock Data**

  These credentials and data work exclusively in [Test Mode](/authentication). If you require mock data to test a specific flow or feature, please contact our [support team](https://developer.flutterwave.com/support).
</Warning>

### 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](/payment-api/card) scenarios.

### Successful Payments

Here is a list of cards to simulate a successful payment.

| Type                         | Network    | Card Number         | Expiry | CVV | OTP   | PIN  |
| ---------------------------- | ---------- | ------------------- | ------ | --- | ----- | ---- |
| PIN authentication           | Mastercard | 5531886652142950    | 09/32  | 564 | 12345 | 3310 |
| 3DS authentication           | Mastercard | 5438898014560229    | 10/31  | 564 | 12345 | 3310 |
| 3DS authentication           | Visa       | 4187427415564246    | 09/32  | 828 | 12345 | 3310 |
| PIN authentication           | Verve      | 5061460410120223210 | 10/31  | 780 | 12345 | 3310 |
| NoAuth                       | Verve      | 5061460166976054667 | 10/29  | 564 | -     | 3310 |
| Address Verification (AVS)   | Visa       | 4556052704172643    | 09/32  | 899 | 12345 | 3310 |
| Pre-authentication Test Card | Mastercard | 5377283645077450    | 09/31  | 789 | -     | 3310 |

### Failed Payments

Here is a list of cards to simulate a failed payment.

| Type                                 | Network    | Card Number      | Expiry | CVV | OTP   | PIN  |
| ------------------------------------ | ---------- | ---------------- | ------ | --- | ----- | ---- |
| Card Declined (Address Verification) | Mastercard | 5143010522339965 | 08/32  | 276 | 12345 | 3310 |
| Card Fraudulent                      | Mastercard | 5590131743294314 | 11/32  | 887 | 12345 | 3310 |
| Card Insufficient Funds              | Mastercard | 5258585922666506 | 09/31  | 883 | 12345 | 3310 |
| Do Not Honour                        | Mastercard | 5143010522339965 | 08/31  | 276 | -     | 3310 |
| Insufficient Funds                   | Mastercard | 5258585922666506 | 09/31  | 883 | 12345 | -    |
| Restricted Card, Retain Card         | Mastercard | 5551651630381384 | 08/31  | 276 | -     | -    |
| Invalid Transaction                  | Mastercard | 5551658157653822 | 08/31  | 276 | -     | -    |
| Function Not Permitted to Cardholder | Mastercard | 5258582054729020 | 11/30  | 887 | -     | -    |
| Function Not Permitted to Terminal   | Mastercard | 5258588264565682 | 11/30  | 887 | -     | -    |
| Transaction Error                    | Mastercard | 5258589130149016 | 11/30  | 887 | -     | -    |
| Incorrect PIN                        | Mastercard | 5399834697894723 | 09/31  | 883 | 12345 | 3310 |

### 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](#cards) and [mobile money](#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`

<Info>
  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](#failed-payments).
</Info>

### Bank Accounts

Bank account details to use to make a mock payment.

| Bank              | Account number | OTP   |
| ----------------- | -------------- | ----- |
| Access Bank (044) | 0690000031     | 12345 |
| Access Bank (044) | 0690000032     | 12345 |
| Access Bank (044) | 0690000033     | 12345 |
| Access Bank (044) | 0690000034     | 12345 |

<Info>
  **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`.
</Info>

## Mobile Money

### Successful Payments

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

### 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.

| S/N | Mobile number | Error message               |
| --- | ------------- | --------------------------- |
| 1.  | 233121212121  | Mocked a Failed Transaction |
| 2.  | 233010101011  | Mocked a Failed Transaction |

## Testing Apple Pay or Google Pay

When testing Apple Pay and Google Pay transactions, You can mock successful and failed transactions by appending the appropriate suffix to your transaction reference.

* **To mock a successful transaction**: Make sure your reference ends with `_success_mock` (for example, `"dfs23fhr7ntg0293039_success_mock"`).

* **To mock a failed transaction**: Make sure your reference ends with `_failed_mock` (for example, `"dfs23fhr7ntg0293039_failed_mock"`).

## Testing Transfers

<Warning>
  **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.
</Warning>

When testing a transfer, you can use any of our provided [test accounts](#bank-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"`).

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

* **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.

## Bill Payments

Here are some credentials to help you test some billers

| Biller | Credential Type   | Credentials  |
| ------ | ----------------- | ------------ |
| DSTV   | Smart card number | `0025401100` |

<Info>
  **DSTV Test**

  The Biller type for making mock DSTV payments is `DSTV Payment`
</Info>

## BVN Credentials

You can use the mock data below to test your BVN consent integration.

| BVN         | First Name | Last Name | OTP    |
| ----------- | ---------- | --------- | ------ |
| 22222222280 | Nibby      | Certifier | 111111 |
| 22123456789 | Nibby      | Certifier | -      |