Stripe Test Cards: Test US Checkout Payments and 3D Secure

The payment page is open, and the product and price are displayed correctly. What you need to confirm next is not just whether the pay button can be clicked.

When a card is declined, what does the page show? Can the buyer switch to another card and continue? If identity verification is canceled midway, will the order be mistakenly marked as paid?

Use three Stripe test cards to check success, failure, and identity verification separately. After each submission, check both the checkout and the backend records.

This article uses a checkout that requires a US billing address as an example. It is operated through the browser and does not require writing code.

1. Open the payment page in the test environment

Go to the Stripe Dashboard and use the account selector to switch to Sandbox, the test environment. All payment operations in this round are completed in this environment and will not move real funds. Stripe test environment documentation

If you already have a test payment link, open it directly.

If you have not created one yet, create a new link in Payment Links in the test environment, select a test product and price, then open the generated payment page. Payment Links can be created through the Dashboard without building a website. Create a payment link

First check three things:

Whether the product is correct.
Whether the amount and currency are correct.
Whether the page belongs to the test environment you just selected.

Do not rush to enter the card number at this step. If the wrong price is selected or the wrong link is opened, then even if the later tests are completed, they will not have checked the flow you plan to launch.

2. Fill in a US billing address

For billing country, select United States.

Open the address generator, select the United States, set the number to generate to 1, and click generate. Copy the street, city, state, and ZIP code into the payment form.

Fill in each field as follows:

Checkout field	What to enter	Example
Address line 1	Street address	5322 N Union Street
Address line 2	Apartment or suite number, leave blank if none	Leave blank
City	City	North Walpole
State	The corresponding state	New Hampshire
ZIP code	ZIP code	03609
Country	Country	United States

If the state field is a dropdown menu, select New Hampshire; if it requires a two-letter abbreviation, enter NH.

The first zero in ZIP code 03609 must be kept. Do not treat it as a number and write 3609.

Use a test email address you can access so you can check later notifications. After filling in the address, keep this sample and use the same address for all three test rounds.

This way, when the payment result changes, the first thing you compare is the card number and verification action. You do not have to also investigate whether the city, state, or ZIP code was changed incorrectly at the same time.

3. Use a success card to check the complete payment flow

First use this set of information:

Card number: 4242 4242 4242 4242
Expiry: 12/34
CVC: 123

The expiry date needs to be in the future. The month/year and CVC here are used for this test; the card number corresponds to Stripe's successful payment scenario. Test card documentation

Click pay and observe whether the page enters the expected completion state.

Then return to the same test environment, open the payment records, and find the transaction you just made. Check the amount, currency, and payment status. Payments from Payment Links can be viewed in the Dashboard payments overview. View payment records

In this round, check two things separately:

Whether the payment status is correct, and whether the page's follow-up actions are correct.

For example, if the backend shows a successful payment but the completion page does not open, the troubleshooting focus should be on the post-payment page configuration and redirect path. Do not re-enter the entire card number and address just because the browser reports an error.

Conversely, the browser showing "Thank you for your purchase" cannot replace the backend payment status. The confirmation page and the payment record need to correspond to each other.

If the payment link is connected to order, email, or download flows, check these steps as well:

Whether the order shows as paid.
Whether the amount matches the checkout.
Whether the configured notifications were sent.
Whether the configured download or access entry is available.

Features that are not connected do not need to be checked, and Stripe payment success must not be treated as proof that these features are complete.

4. Use a failure card to check error messages and card retry

Reopen the payment link and start a new test.

Keep the address, email, and other conditions unchanged, and only change the card number to:

4000 0000 0000 0002

This card simulates a general payment decline. Declined test cards

After clicking pay, check:

Whether the page shows a clear failure message.
Whether the card number input field can still be edited.
Whether the page incorrectly enters the payment completion state.
Whether the associated order is incorrectly marked as paid.

The failure message must not only say "An error occurred." The buyer should at least know that the payment was not completed and that they can still continue.

Next, in the current checkout, change the card number back to:

4242 4242 4242 4242

Submit again.

This step checks the recovery path after failure. Being able to pay successfully the first time does not mean that after one failure, the button, form, and order status are still correct.

If it keeps spinning after the first failure, record where it gets stuck. Check the retry operation first; do not change the address, change the product, and refresh all pages at the same time. Changing multiple conditions at once will lose the most valuable comparison.

5. Check both the completed and canceled identity verification paths

For the third round, use a US-issued 3D Secure test card:

4000 0084 0000 0027

Stripe's default Radar rules will request 3D Secure verification for this card. 3D Secure test documentation

The test must be performed on the payment page opened by the buyer. Creating a payment directly in the Stripe Dashboard cannot replace the verification flow in the browser.

First complete one verification and check:

Whether the verification interface can open.
Whether you can return to the payment flow after completing verification.
Whether the checkout and backend show consistent results.

Then start a new test and cancel in the verification interface.

After canceling, check whether the page still keeps an entry point to continue payment, and whether the order is still in an unpaid state. Completing identity verification and completing payment are two checkpoints; you cannot only look at whether the verification window closed.

If the verification interface does not appear, first confirm that you used the corresponding test card, opened the buyer payment page, and check whether Radar rules have been modified. Do not treat changing to a US address as a way to trigger verification.

6. If it gets stuck at a step, first determine which layer it is

A checkout error is not necessarily a card number problem. Break down the troubleshooting by where it occurs:

Symptom	What to check first	Next comparison
Address field error, cannot submit	Country, state, ZIP code, and required fields	Keep the card number unchanged and only correct the field with the error
Failure card is declined	Whether the failure scenario card number was used	Switch to a success card and check whether payment can recover
Success card also fails	Test environment, page configuration, backend error details	Repeat the same conditions with a new payment page
Backend succeeds, completion page errors	Post-payment redirect or page configuration	Check the payment record and target page separately
Still shows paid after verification is canceled	Status handling in the checkout and associated order	Compare the two tests: completed verification and canceled verification
First payment works, retry after failure does not	Recovery state of the form and button	Repeat the order "failure card -> success card"

The table is used to determine the next check; it does not mean the cause can be determined from a single symptom alone.

Record the original error message, test time, and payment record. If the screenshot only says "Something went wrong," it will be difficult later to determine whether the issue was address validation, card decline, or the post-payment page.

7. Keep a test record that can be reviewed

No need to write a long report. One table is enough:

Test scenario	Page result	Backend result	Associated order or delivery result
Successful payment	Record what is actually displayed	Record payment status	Check connected follow-up flows
Payment failure	Record the error message	Check failure details	Confirm it was not marked as paid
Card switch after failure	Check whether it can be submitted again	Check the new payment	Check whether the status recovers correctly
Complete identity verification	Check the return page	Check the final status	Check connected follow-up flows
Cancel identity verification	Check the entry point to continue payment	Check the actual status	Confirm it was not mistakenly judged as paid

Each time you modify the checkout, the post-payment redirect, or order handling, review it using this table.

What really needs to work end to end is the whole chain: fill in information, submit payment, handle failure or verification, confirm the payment result, and then complete the corresponding order operation. Seeing one "payment successful" alone is not enough to show that the checkout is ready.