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

• Card errors due to declines, fraud, or invalid data

• Disputes and refunds

• Authentication with 3D Secure

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

Any time you work with a test card at Test Mode in all API calls. This is true whether you’re serving a payment form to test interactively or writing test code.

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.

Testing interactively

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.

Cards by brand

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

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.

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

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.

Brand/Co-brand	Number	CVC	Date
Cartes Bancaires/Visa	4000 0025 0000 1001	Any 3 digits	Any future date
Cartes Bancaires/Mastercard	5555 5525 0000 1001	Any 3 digits	Any future date
eftpos Australia/Visa	4000 0503 6000 0001	Any 3 digits	Any future date
eftpos Australia/Mastercard	5555 0503 6000 0080	Any 3 digits	Any future date

Declined payments

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.

To simulate an incorrect CVC, you must provide one using any three-digit number. If you don’t provide a CVC, Stripe doesn’t perform the CVC check, so the check can’t fail.

Description	Number	Error code	Decline code
Generic decline	4000 0000 0000 0002	card_declined	generic_decline
Insufficient funds decline	4000 0000 0000 9995	card_declined	insufficient_funds
Lost card decline	4000 0000 0000 9987	card_declined	lost_card
Stolen card decline	4000 0000 0000 9979	card_declined	stolen_card
Expired card decline	4000 0000 0000 0069	expired_card	n/a
Incorrect CVC decline	4000 0000 0000 0127	incorrect_cvc	n/a
Processing error decline	4000 0000 0000 0119	processing_error	n/a
Incorrect number decline	4242 4242 4242 4241	incorrect_number	n/a
Exceeding velocity limit decline	4000 0000 0000 6975	card_declined	card_velocity_exceeded

Fraud prevention

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.

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.

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

Invalid data

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, such as 4242 4242 4242 4241.

Disputes

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

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

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.

3D Secure usage	Outcome	Number	Details
3DS Required	OK	4000 0000 0000 3220	3D Secure authentication must be completed for the payment to be successful.
3DS Required	Declined	4000 0084 0000 1629	3D Secure authentication is required, but payments are declined with a card_declined failure code after authentication.
3DS Required	Error	4000 0084 0000 1280	3D Secure authentication is required, but the 3D Secure lookup request fails with a processing error. Payments are declined with a card_declined failure code.
3DS Supported	OK	4000 0000 0000 3055	3D Secure authentication might still be performed, but isn’t required.
3DS Supported	Error	4000 0000 0000 3097	3D Secure authentication might still be performed, but isn’t required. However, attempts to perform 3D Secure result in a processing error.
3DS Supported	Unenrolled	4242 4242 4242 4242	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.
3DS Not supported		3782 822463 10005	3D Secure isn’t supported on this card and can’t be invoked. The PaymentIntent or SetupIntent proceeds without performing authentication.

Captcha challenge

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

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.

Non-card payments

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.

Link

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.

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