Stripe Test Cards - Comprehensive List

The main Stripe test card is 4242 4242 4242 4242 — use any future expiry date, any 3-digit CVC and any postal code. It simulates a successful Visa payment in test mode. For a generic decline, use 4000 0000 0000 0002; for 3D Secure authentication, use 4000 0025 0000 3155. Full list below.

How To Use Stripe Credit Card Test Data

Stripe equips developers with test API keys and a comprehensive list of Stripe test credit card numbers, enabling the simulation of realistic payment scenarios without the exchange of real money. These test cards, accessible directly in the Stripe Dashboard or via the Stripe API in test mode, are designed to mimic various aspects of card payments, from successful transactions to card declines and error messages.

This functionality is crucial for validating the integration of your payment gateway with Stripe payments, ensuring that everything from the payment form to the backend processes operates flawlessly.

The card number determines the simulated behavior. That makes it possible to test cases such as:

• successful authorization
• declined payment
• authentication
• validation failure
• payment recovery

without creating real financial transactions.

Use Stripe test cards only in test mode. They aren't real cards and won't create real charges.

Stripe recommends using a PaymentMethod such as pm_card_visa instead of raw card numbers in server-side test code. Raw card numbers are best reserved for interactive testing in a payment form or Dashboard test flow.

For an ecommerce release, these scenarios should also appear in your ecommerce test plan and payment-specific test cases.

Test Credit Card Numbers Stripe (Debit and Credit)

By employing these test cards to simulate different types of card payments - including debit and credit cards from major issuers - developers can thoroughly test their Stripe integration. The process encompasses everything from user interaction, where the user is prompted to insert their card information, to the final stages of payment authorization and processing. Stripe's testing environment is also equipped to handle card presentment scenarios, thanks to physical test cards and simulated test cards facilitated by Stripe Terminal SDKs.

These tools are invaluable for exploring a wide range of testing scenarios, ensuring that the payment gateway can handle various payment flows and card network specifics.

Engaging with Stripe's test cards and API in test mode allows for a detailed, hands-on understanding of how to effectively test and prepare your payment integration for the demands of real-world transactions, making them an indispensable resource for any developer looking to refine their online payment solutions.

Check out Stripe Form Recording - the new feature of BugBug.

Comprehensive List of Stripe Test Cards

Utilizing test cards allows developers to explore and troubleshoot the entire spectrum of payment flows, from simple transactions to more complex scenarios involving various payment methods. This hands-on testing approach ensures that all potential issues are identified and resolved before any real financial transactions take place.

By engaging with Stripe's test environment, developers can gain confidence in their payment systems, knowing they have rigorously tested their implementations against a wide range of simulated conditions. Stripe provides a detailed list of test cards for various card brands, each capable of simulating different scenarios within the payment process. These include:

Successful Payments by Card Brand

Unless noted otherwise, use any future expiry date, any three-digit CVC and any postal code. American Express test cards require a four-digit CVC.

Co-Branded Cards

Successful Payments by Country

Stripe test cards also extend their utility by simulating successful payments from various countries, such as the United States, Argentina, Brazil, Canada, and Mexico, among others. This feature is invaluable for developers aiming to ensure their payment systems are equipped for international transactions.

For other countries, refer to the Stripe testing documentation.

Declined Payments

To simulate a declined payment with a card attached to a Customer, use 4000 0000 0000 0341: attaching it succeeds, but attempts to charge it fail.

Fraud Prevention

Blocked payments return a card error with the error code fraud.

3D Secure Authentication

A checkout that works with a simple successful payment may still fail when authentication introduces:

• redirects
• modal dialogs
• additional browser state
• asynchronous status updates
• return URLs

A useful 3D Secure test should verify:

1. customer submits payment
2. authentication challenge appears
3. customer completes the test challenge
4. application returns to the correct page
5. payment reaches the expected final state
6. exactly one order is created

If you're automating this in the browser, treat it as a full integration or E2E scenario rather than only a card-field test. See End-to-End Testing for the wider testing layer.

Declined Payments and Fraud Prevention

To thoroughly test the resilience and error-handling capabilities of payment systems, Stripe offers test cards that simulate declined transactions for reasons such as insufficient funds, lost or stolen cards, and generic declines. Additionally, cards that simulate transactions with varying levels of fraud risk are available, enabling developers to test their systems' fraud prevention mechanisms effectively.

Stripe Declined Card

Use 4000 0000 0000 0002 to simulate a generic declined card.

The important test isn't simply:

Stripe declined the card.

You should verify how your application handles the failure.

A good checkout should:

• keep the user on a recoverable payment state
• preserve cart data
• show a useful error
• avoid creating a paid order
• allow another payment attempt

Example expected result:

Payment is rejected, no paid order is created, and the user can retry without losing checkout information.

This is a classic negative test case.

For more on structuring these cases, see the Test Case Template.

Invalid Stripe Card Number

A commonly used invalid-number scenario is 4242 4242 4242 4241. This intentionally fails card-number validation.

Use it to verify:

• invalid number is rejected
• useful validation appears
• payment request isn't incorrectly completed
• checkout remains usable

Don't treat client-side validation as sufficient on its own. The backend/payment integration should still behave safely if invalid or malformed payment input reaches it.

Expired Card Testing

Stripe provides a dedicated expired-card decline: 4000 0000 0000 0069. Use it when you want Stripe itself to return an expired-card error.

You can also use a normal successful test card with a past expiry date to verify client-side expiry validation before a payment request is sent.

Your application should:

• reject the payment details
• identify the expiry problem clearly
• avoid creating a successful payment
• keep the user in a recoverable checkout state

Also test the current-month boundary if your own frontend validates expiry dates.

Incorrect CVC Testing

Use 4000 0000 0000 0127 and provide any three-digit CVC to simulate Stripe's incorrect-CVC decline.

The test should verify that:

• the payment doesn't become successful
• the application shows a clear recoverable error
• the user can correct the card details
• order state isn't corrupted

Don't assert only against Stripe's raw error copy unless the exact wording is part of your product requirement. Your application may intentionally map provider errors into clearer customer-facing messages.

Disputes and Refunds

Some cards succeed first and cause a problem later, the way disputes and refunds behave in live mode. With all other test cards, refunds succeed immediately.

Implementing Stripe Card Details in Your Testing Strategy

Incorporating Stripe test card details into the development and testing workflows is crucial for a comprehensive testing process. Developers are advised to simulate a wide range of transaction scenarios, including successful payments, declined transactions, and fraud alerts, to ensure the payment system is robust and user-friendly.

To make the most of Stripe test cards, developers should adhere to best practices such as ensuring the Stripe integration is in test mode when using these numbers and avoiding common pitfalls like using random or real card numbers, which can lead to unpredictable results.

Payment Success vs Failure Test Matrix

A useful Stripe test suite shouldn't contain only one green and one red scenario.

This type of matrix belongs in a real software test plan rather than living only inside one developer's local notes.

Stripe Test Cards in Automated Testing

Payment flows are good automation candidates when:

• sandbox/test mode is stable
• test data can be reset
• authentication flow is predictable
• test orders can be identified and cleaned up

A browser automation test might cover: Login → Add product → Checkout → Enter Stripe test card → Complete payment → Verify confirmation.

A lower-level integration test may instead call your payment service directly and verify provider responses without opening a browser.

Use the lowest layer that proves the behavior you care about.

For tooling and architecture, see Integration Testing Tools and Test Automation Frameworks.

Testing Stripe with BugBug

BugBug can automate browser checkout flows that include payment forms (Stripe Form Recording), provided the payment flow is accessible in the test environment.

A typical test can:

1. open the store
2. add an item
3. proceed to checkout
4. fill the Stripe test card
5. submit payment
6. verify the order confirmation

For payment testing, always use:

• Stripe test mode
• dedicated test products
• dedicated test customer
• predictable cleanup

Avoid creating uncontrolled live transactions.

If your store runs on Shopify, see How to Test Shopify Credit Card Payments.

Final Thoughts

The ability to simulate various payment scenarios securely and effectively is crucial for the development of a reliable payment processing system. Stripe test cards provide a comprehensive solution for this need, enabling developers to refine their systems for optimal performance in real-world conditions. By leveraging these test cards, businesses can ensure their payment processes are seamless, secure, and ready to handle transactions on a global scale, ultimately enhancing the user experience and supporting business growth.

Frequently Asked Questions

What is the main Stripe test card?

The most common Stripe test card is 4242 4242 4242 4242. Use it in Stripe test mode with any future expiry date, any three-digit CVC and an appropriate postal code.

What Stripe test card should I use for a decline?

A commonly used generic-decline test card is 4000 0000 0000 0002. Use it to verify how your application handles unsuccessful payment attempts.

What Stripe test card triggers 3D Secure?

Use 4000 0025 0000 3155 for a common 3D Secure test scenario in Stripe test mode.

Can Stripe test cards make real payments?

No. Stripe test cards are intended for test mode and don't create real card charges.

Can I automate Stripe payments?

Yes. Payment tests can be automated in sandbox/test mode through browser automation, API/integration tests or a combination of both. Avoid using real payment cards in routine automated tests.

Should I test only successful Stripe payments?

No. At minimum, cover success, decline, validation errors, authentication and retry behavior. Failure handling is often where checkout bugs become most expensive.

Are Stripe and Shopify test cards the same?

Not always. Shopify Payments, Stripe test mode and Shopify's Bogus Gateway can use different testing flows and test values. Follow the documentation for the exact payment system being tested.

Last verified: October 2026.

Happy (automated) testing!