> For the complete documentation index, see [llms.txt](https://bagelpay.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://bagelpay.gitbook.io/docs/documentation/testing-mode/simulate-payments.md).

# Simulate Payments

To test your integration, simulate transactions without moving any money using special testing values in Test Mode. 

Test cards act as fake credit cards, and allow you to simulate the following scenarios:

* **Successful payments by** [**card brand**](#cards)
* **Card errors due to** [**declines**](#declined-payments)**,** [**fraud**](#fraud-prevention)**, or** [**invalid data**](#invalid-data)
* [**Disputes**](#disputes) **and** [**refunds**](#refunds)
* **Authentication with** [**3D Secure**](#regulatory-cards)

Testing non-card payments works similarly. Non-card payments are payment methods that aren’t credit or debit cards. BagelPay supports various non-card payment options, such as digital wallets and bank transfers. Each payment method has its own special values.

Don’t use testing environments to load test your integration because you might hit rate limits.

## How to use test cards <a href="#use-test-cards" id="use-test-cards"></a>

Any time you work with a test card at[ Test Mode](/docs/documentation/testing-mode/test-mode-vs-live-mode.md)  in all API calls. This is true whether you’re serving a payment form to test interactively or writing test code.

{% hint style="info" %}
**Common mistake**\
Don’t use real card details. BagelPay prohibits testing in live mode using real payment method details. Use your test API keys and the card numbers below.
{% endhint %}

### Testing interactively <a href="#testing-interactively" id="testing-interactively"></a>

When testing interactively, use a card number, such as `4242 4242 4242 4242`. Enter the card number in the Dashboard or in any payment form.

* Use a valid future date, such as **12/34**.
* Use any three-digit CVC (four digits for American Express cards).
* Use any value you like for other form fields.

<figure><img src="/files/p2BgYwfq5NCxzvOoBcJO" alt=""><figcaption></figcaption></figure>

## Cards by brand <a href="#cards" id="cards"></a>

To simulate a successful payment for a specific card brand, use test cards from the following list.

{% hint style="info" %}
Cross-border fees are assessed based on the country of the card issuer. Cards where the issuer country isn’t the US (such as JCB and UnionPay) might be subject to a cross-border fee, even in testing environments.
{% endhint %}

<table><thead><tr><th>Brand</th><th width="244.6263427734375">Number</th><th>CVC</th><th>Date</th></tr></thead><tbody><tr><td>Visa</td><td><code>4242 4242 4242 4242</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Visa (debit)</td><td><code>4000 0566 5566 5556</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Mastercard</td><td><code>5555 5555 5555 4444</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Mastercard (2-series)</td><td><code>2223 0031 2200 3222</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Mastercard (debit)</td><td><code>5200 8282 8282 8210</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Mastercard (prepaid)</td><td><code>5105 1051 0510 5100</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>American Express</td><td><code>3782 822463 10005</code></td><td>Any 4 digits</td><td>Any future date</td></tr><tr><td>American Express</td><td><code>3714 496353 98431</code></td><td>Any 4 digits</td><td>Any future date</td></tr><tr><td>Discover</td><td><code>6011 1111 1111 1117</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Discover</td><td><code>6011 0009 9013 9424</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Discover (debit)</td><td><code>6011 9811 1111 1113</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Diners Club</td><td><code>3056 9300 0902 0004</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Diners Club (14-digit card)</td><td><code>3622 720627 1667</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>BCcard and DinaCard</td><td><code>6555 9000 0060 4105</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>JCB</td><td><code>3566 0020 2036 0505</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>UnionPay</td><td><code>6200 0000 0000 0005</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>UnionPay (debit)</td><td><code>6200 0000 0000 0047</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>UnionPay (19-digit card)</td><td><code>6205 5000 0000 0000 004</code></td><td>Any 3 digits</td><td>Any future date</td></tr></tbody></table>

Most Cartes Bancaires and eftpos cards are co-branded with either Visa or Mastercard. The test cards in the following table simulate successful payments with co-branded cards.

<table><thead><tr><th width="208.9671630859375">Brand/Co-brand</th><th width="244.7772216796875">Number</th><th>CVC</th><th>Date</th></tr></thead><tbody><tr><td>Cartes Bancaires/Visa</td><td><code>4000 0025 0000 1001</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>Cartes Bancaires/Mastercard</td><td><code>5555 5525 0000 1001</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>eftpos Australia/Visa</td><td><code>4000 0503 6000 0001</code></td><td>Any 3 digits</td><td>Any future date</td></tr><tr><td>eftpos Australia/Mastercard</td><td><code>5555 0503 6000 0080</code></td><td>Any 3 digits</td><td>Any future date</td></tr></tbody></table>

## Declined payments <a href="#declined-payments" id="declined-payments"></a>

To test your integration’s error-handling logic by simulating payments that the issuer declines for various reasons, use test cards from this section. Using one of these cards results in a card error with the given error code and decline code.

{% hint style="info" %}
To simulate an incorrect CVC, you must provide one using any three-digit number. If you don’t provide a CVC, BagelPay doesn’t perform the CVC check, so the check can’t fail.
{% endhint %}

<table><thead><tr><th>Description</th><th width="232.985595703125">Number</th><th>Error code</th><th>Decline code</th></tr></thead><tbody><tr><td>Generic decline</td><td><code>4000 0000 0000 0002</code></td><td>card_declined</td><td>generic_decline</td></tr><tr><td>Insufficient funds decline</td><td><code>4000 0000 0000 9995</code></td><td>card_declined</td><td>insufficient_funds</td></tr><tr><td>Lost card decline</td><td><code>4000 0000 0000 9987</code></td><td>card_declined</td><td>lost_card</td></tr><tr><td>Stolen card decline</td><td><code>4000 0000 0000 9979</code></td><td>card_declined</td><td>stolen_card</td></tr><tr><td>Expired card decline</td><td><code>4000 0000 0000 0069</code></td><td>expired_card</td><td>n/a</td></tr><tr><td>Incorrect CVC decline</td><td><code>4000 0000 0000 0127</code></td><td>incorrect_cvc</td><td>n/a</td></tr><tr><td>Processing error decline</td><td><code>4000 0000 0000 0119</code></td><td>processing_error</td><td>n/a</td></tr><tr><td>Incorrect number decline</td><td><code>4242 4242 4242 4241</code></td><td>incorrect_number</td><td>n/a</td></tr><tr><td>Exceeding velocity limit decline</td><td><code>4000 0000 0000 6975</code></td><td>card_declined</td><td>card_velocity_exceeded</td></tr></tbody></table>

## Fraud prevention <a href="#fraud-prevention" id="fraud-prevention"></a>

BagelPay’s fraud prevention system, Radar, can block payments when they have a high risk level or fail verification checks. You can use the cards in this section to test your Radar settings. You can also use them to test how your integration responds to blocked payments.

{% hint style="info" %}
**Common mistake**\
To simulate a failed CVC check, you must provide a CVC using any three-digit number. To simulate a failed postal code check, you must provide any valid postal code. If you don’t provide those values, Radar doesn’t perform the corresponding checks, so the checks can’t fail.
{% endhint %}

| Description                        | Number                | Details                                                                                                            |
| ---------------------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------ |
| Always blocked                     | `4100 0000 0000 0019` | <p>The charge has a risk level of “highest”</p><p>Radar always blocks it.</p>                                      |
| Highest risk                       | `4000 0000 0000 4954` | <p>The charge has a risk level of “highest”</p><p>Radar might block it</p>                                         |
| Elevated risk                      | `4000 0000 0000 9235` | The charge has a risk level of “elevated”                                                                          |
| CVC check fails                    | `4000 0000 0000 0101` | <p>If you provide a CVC number, the CVC check fails.</p><p>Radar might block it</p>                                |
| Postal code check fails            | `4000 0000 0000 0036` | <p>If you provide a postal code, the postal code check fails.</p><p>Radar might block it</p>                       |
| CVC check fails with elevated risk | `4000 0584 0030 7872` | <p>If you provide a CVC number, the CVC check fails with a risk level of “elevated”</p><p>Radar might block it</p> |

## Invalid data <a href="#invalid-data" id="invalid-data"></a>

To test errors resulting from invalid data, provide invalid details. You don’t need a special test card for this. Any invalid value works. For instance:

* invalid\_expiry\_month: Use an invalid month, such as **13**.
* invalid\_expiry\_year: Use a year up to 50 years in the past, such as **95**.
* invalid\_cvc: Use a two-digit number, such as **99**.
* incorrect\_number: Use a card number that fails the [Luhn check](https://en.wikipedia.org/wiki/Luhn_algorithm), such as `4242 4242 4242 4241`.

## Disputes <a href="#disputes" id="disputes"></a>

To simulate a disputed transaction, use the test cards in this section. Then, to simulate winning or losing the dispute, provide winning or losing evidence.

| Description                  | Number                | Details                                                                                                                                                           |
| ---------------------------- | --------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Fraudulent                   | `4000 0000 0000 0259` | With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected after 3D Secure authentication.              |
| Not received                 | `4000 0000 0000 2685` | With default account settings, charge succeeds, only to be disputed as product not received. This type of dispute isn’t protected after 3D Secure authentication. |
| Inquiry                      | `4000 0000 0000 1976` | With default account settings, charge succeeds, only to be disputed as an inquiry.                                                                                |
| Warning                      | `4000 0000 0000 5423` | With default account settings, charge succeeds, only to receive an early fraud warning.                                                                           |
| Multiple disputes            | `4000 0004 0400 0079` | With default account settings, charge succeeds, only to be disputed multiple times.                                                                               |
| Visa Compelling Evidence 3.0 | `4000 0004 0400 0038` | With default account settings, charge succeeds, only to be disputed as a Visa Compelling Evidence 3.0 eligible dispute.                                           |
| Visa compliance              | `4000 0084 0000 0779` | With default account settings, charge succeeds, only to be disputed as a Visa compliance dispute.                                                                 |

## Refunds <a href="#refunds" id="refunds"></a>

Refunds are asynchronous: a refund can appear to succeed and later fail, or can appear as `pending` at first and later succeed. To simulate refunds with those behaviors, use the test cards in this section. (With all other test cards, refunds succeed immediately and don’t change status after that.)

| Description          | Number                | Details                                                                                                                                                                   |
| -------------------- | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Asynchronous success | `4000 0000 0000 7726` | The charge succeeds. If you initiate a refund, its status begins as `pending`. Some time later, its status transitions to `succeeded` and sends a `refund.created` event. |

## 3D Secure authentication <a href="#regulatory-cards" id="regulatory-cards"></a>

3D Secure requires an additional layer of authentication for credit card transactions. The test cards in this section allow you to simulate triggering authentication in different payment flows.

Only cards in this section effectively test your 3D Secure integration by simulating defined 3DS behavior, such as a challenge flow or an unsupported card.&#x20;

<table><thead><tr><th width="145.44110107421875">3D Secure usage</th><th width="96.226806640625">Outcome</th><th>Number</th><th>Details</th></tr></thead><tbody><tr><td>3DS Required</td><td>OK</td><td><code>4000 0000 0000 3220</code></td><td>3D Secure authentication must be completed for the payment to be successful. </td></tr><tr><td>3DS Required</td><td>Declined</td><td><code>4000 0084 0000 1629</code></td><td>3D Secure authentication is required, but payments are declined with a <code>card_declined</code> failure code after authentication.</td></tr><tr><td>3DS Required</td><td>Error</td><td><code>4000 0084 0000 1280</code></td><td>3D Secure authentication is required, but the 3D Secure lookup request fails with a processing error. Payments are declined with a <code>card_declined</code> failure code. </td></tr><tr><td>3DS Supported</td><td>OK</td><td><code>4000 0000 0000 3055</code></td><td>3D Secure authentication might still be performed, but isn’t required. </td></tr><tr><td>3DS Supported</td><td>Error</td><td><code>4000 0000 0000 3097</code></td><td>3D Secure authentication might still be performed, but isn’t required. However, attempts to perform 3D Secure result in a processing error. </td></tr><tr><td>3DS Supported</td><td>Unenrolled</td><td><code>4242 4242 4242 4242</code></td><td>3D Secure is supported for this card, but this card isn’t enrolled in 3D Secure. Even if your Radar rules request 3D Secure, the customer won’t be prompted to authenticate. </td></tr><tr><td>3DS Not supported</td><td></td><td><code>3782 822463 10005</code></td><td>3D Secure isn’t supported on this card and can’t be invoked. The PaymentIntent or SetupIntent proceeds without performing authentication.</td></tr></tbody></table>

## Captcha challenge <a href="#captcha" id="captcha"></a>

To prevent fraud, BagelPay might display a captcha challenge to the user on the payment page. Use the test cards below to simulate this flow.

| Description       | Number                | Details                                                                  |
| ----------------- | --------------------- | ------------------------------------------------------------------------ |
| Captcha challenge | `4000 0000 0000 1208` | The charge succeeds if the user correctly answers the captcha challenge. |
| Captcha challenge | `4000 0000 0000 3725` | The charge succeeds if the user correctly answers the captcha challenge. |

## Rate limits <a href="#rate-limits" id="rate-limits"></a>

If your requests in your testing environments begin to receive `429` HTTP errors, make them less frequently. These errors come from our rate limiter, which is more strict in testing environments than in live mode.

We don’t recommend load testing your integration using the BagelPay API in testing environments. Because the load limiter is stricter in testing environments, you might see errors that you wouldn’t see in production.&#x20;

## Non-card payments <a href="#non-card-payments" id="non-card-payments"></a>

Any time you use a test non-card payment method, use test API keys in all API calls. This is true whether you’re serving a payment form you can test interactively or writing test code.

BagelPay provides several test account numbers and corresponding tokens you can use to make sure your integration for manually-entered bank accounts is ready for production.

| Account number | Routing number | Behavior                                                                                               |
| -------------- | -------------- | ------------------------------------------------------------------------------------------------------ |
| `000123456789` | `110000000`    | The payment succeeds.                                                                                  |
| `000111111113` | `110000000`    | The payment fails because the account is closed.                                                       |
| `000000004954` | `110000000`    | The payment is blocked by Radar due to a high risk of fraud.                                           |
| `000111111116` | `110000000`    | The payment fails because no account is found.                                                         |
| `000222222227` | `110000000`    | The payment fails due to insufficient funds.                                                           |
| `000333333335` | `110000000`    | The payment fails because debits aren’t authorized.                                                    |
| `000444444440` | `110000000`    | The payment fails due to invalid currency.                                                             |
| `000666666661` | `110000000`    | The payment fails to send microdeposits.                                                               |
| `000555555559` | `110000000`    | The payment triggers a dispute.                                                                        |
| `000000000009` | `110000000`    | The payment stays in processing indefinitely. Useful for testing PaymentIntent cancellation.           |
| `000777777771` | `110000000`    | The payment fails due to payment amount causing the account to exceed its weekly payment volume limit. |

Before test transactions can complete, you need to verify all test accounts that automatically succeed or fail the payment.&#x20;

## Link <a href="#link" id="link"></a>

{% hint style="info" %}
**Caution**\
Don’t store real user data in sandbox Link accounts. Treat them as if they’re publicly available, because these test accounts are associated with your publishable key.
{% endhint %}

Currently, Link only works with credit cards, debit cards, and qualified US bank account purchases. Link requires domain registration.

You can create sandbox accounts for Link using any valid email address. The following table shows the fixed one-time passcode values that BagelPay accepts for authenticating sandbox accounts:

| Value                               | Outcome                      |
| ----------------------------------- | ---------------------------- |
| Any other 6 digits not listed below | Success                      |
| 000001                              | Error, code invalid          |
| 000002                              | Error, code expired          |
| 000003                              | Error, max attempts exceeded |