When using Stripe Elements, you should ensure that:
cardElement is passed correctly to
- In the response handler for
createToken, card errors are handled and displayed properly
- Only valid tokens are passed to your server as part of payment form submission
In your server-side code, you should ensure that:
- All requests are being made successfully. You may find it useful to view your account's events and logs as you test your integration
- All API errors are handled properly
- Relevant webhooks are handled correctly
When you're ready to take your integration live, make sure that you replace your test publishable and secret API keys with live ones. Live payments cannot be processed if your integration is still using your test API keys. You can find your API key information in your account settings.
Test card numbers and tokens
Genuine card information cannot be used in test mode. Instead, use any of the following test card numbers, a valid expiration date in the future, and any random CVC number, to create a successful payment. Each test card's billing country is set to U.S. If you need to create test card payments using cards for other billing countries, use our international test cards.
We recommend using our test tokens when testing your integration and creating charges, instead of passing card information directly to the API. Using tokens in place of card numbers helps ensure your production integration is developed in a PCI compliant manner and is not going to handle card information directly. Each token is human-readable and represents card information that has been tokenized with our client-side libraries (e.g., Stripe Elements, Stripe.js).
International test card numbers and tokens
You can use any of the following test cards to simulate a successful payment for different billing countries. For countries that have separate domestic and international pricing (e.g., Australia), the fee calculated for test card payments is at the international rate.
|4000006430000009||tok_ru||Russian Federation (RU)||Visa|
|4000008260000000||tok_gb||United Kingdom (GB)||Visa|
|4000058260000005||tok_gb_debit||United Kingdom (GB)||Visa (debit)|
|4000003440000004||tok_hk||Hong Kong (HK)||Visa|
|4000005540000008||tok_nz||New Zealand (NZ)||Visa|
3D Secure test card numbers
|4000000000003055||3D Secure is supported but not required on this card. The value of the card source's
|4000000000003063||3D Secure is supported and required on this card. The value of the card source's
|378282246310005||3D Secure is not supported or required on this card. The value of the card source's
All other Visa and Mastercard test cards do not require verification from the customer's bank. The 3D Secure Source status is immediately set to
chargeable upon source creation.
Testing for specific responses and errors
The following test cards can be used to create payments that produce specific responses—useful for testing different scenarios and error codes. Verification checks only run when the required information is provided (e.g., for
cvc_check to be set to fail, a CVC code must be provided).
|4000000000000077||Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).|
|4000000000000093||Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing.|
|4000000000000028||Charge succeeds but the
|4000000000000044||Charge succeeds but the
|4000000000000101||If a CVC number is provided, the |
|4000000000000341||Attaching this card to a
|4000000000009235||Charge succeeds with a
|4000000000000002||Charge is declined with a
|4100000000000019||Charge is declined with a
|4000000000000127||Charge is declined with an
|4000000000000069||Charge is declined with an
|4000000000000119||Charge is declined with a
|4242424242424241||Charge is declined with an
|tok_bypassPending||Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).|
|tok_domesticPricing||Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing.|
|tok_avsLine1Fail||Charge succeeds but the
|tok_avsUnchecked||Charge succeeds but the
|tok_cvcCheckFail||If a CVC number is provided, the |
|tok_chargeCustomerFail||Attaching this card to a
|tok_riskLevelElevated||Charge succeeds with a
|tok_chargeDeclined||Charge is declined with a
|tok_chargeDeclinedFraudulent||Charge is declined with a
|tok_chargeDeclinedIncorrectCvc||Charge is declined with an
|tok_chargeDeclinedExpiredCard||Charge is declined with an
|tok_chargeDeclinedProcessingError||Charge is declined with a
By default, passing address or CVC data with the card number causes the address and CVC checks to succeed. If this information isn't specified, the value of the checks is
null. Any expiration date in the future is considered valid.
You can also provide invalid card details to test specific error codes resulting from incorrect information being provided. For example:
invalid_expiry_month: Use an invalid month (e.g., 13)
invalid_expiry_year: Use a year in the past (e.g., 1970)
invalid_cvc: Use a two digit number (e.g., 99)
In test mode, you can use the test card below to simulate a disputed transaction:
|4000000000000259||tok_createDispute||With default account settings, charge succeeds, only to be disputed.|
The following evidence, when submitted in the
uncategorized_text, produces specific actions that are useful for testing the dispute flow:
||The dispute is closed and marked as won. Your account is credited the amount of the charge and related fees.|
||The dispute is closed and marked as lost. Your account is not be credited.|
It is extremely unlikely for users to experience any rate limits with normal usage of the API, even at high volume. The most common causes for a user to experience rate limits are bugs, bulk data fetches, or extreme load testing.
Should your requests begin to receive
429 HTTP errors, reduce the frequency of your requests. Each failed request is perfectly safe to retry as rate limiting takes place before any other action and prevents the request from being processed. When reducing your request frequency, we recommend an exponential backoff by first waiting one second before trying again. If your request continues to receive the same response, wait two seconds, then four seconds, etc.
Rate limits for both test and live modes are identical. Requests made in test mode are an accurate representation of what to expect when making live requests. If you are experiencing rate limits but are unable to determine why, please let us know.
Use the following information when testing payments using Sources.
In test mode, you can use the following email addresses to test Bitcoin payments. By default, a receiver is always paid 3 seconds after creation.
||Bitcoin are never sent to the receiver address.|
||The next time that the receiver is retrieved after creation, it has been filled by bitcoin.|
When creating a test Source object that uses a redirect flow (e.g., iDEAL), you can follow the URL returned in the
redirect[url] field. This leads to a Stripe page that displays information about the API request, and where you can either authorize or cancel the payment.
Authorizing the payment redirects you to the URL specified in
SEPA Direct Debit
You can mimic a successful or failed charge by first creating a test source with one of the following test IBAN account numbers. Use the resulting source in a charge request to create a test charge that is either successful or failed.
||The charge status transitions from pending to succeeded.|
||The charge status transitions from pending to failed.|
You can send test webhooks to your integration's endpoint within your account's webhooks settings. The event data contained within one of these test webhooks is fabricated and not available in the API–its purpose is only to test that your endpoint is working and configured correctly.
To fully test your integration, perform actions using the API in test mode that results in legitimate webhooks being sent. For instance, creating a charge triggers the
charge.succeeded webhook that contains the charge data. The resulting event data can then be verified using the API.
If you don't have a server set up to receive webhooks but want to see example webhook requests, we suggest using a service like RequestBin to inspect the requests we send.