Testing Payments for SCA

    Learn about the different methods to test your integration before going live.

    Use our available test information to trigger different flows in your integration and ensure they are handled accordingly. Use the 3D Secure test card numbers to trigger the 3D Secure authentication challenge in your integration.

    When using the Payment Intents API with Stripe.js and Elements, the iOS, or Android client SDKs, ensure that:

    • Authentication flows are triggered when required (use the regulatory test card numbers and PaymentMethods)
      • No authentication (default U.S. card): 4242 4242 4242 4242
      • Authentication required: 4000 0027 6000 3184
    • The PaymentIntent is created with an idempotency key to avoid erroneously creating duplicate PaymentIntents for the same purchase
    • Errors are caught and displayed properly in the UI

    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

    Test card numbers and payment methods

    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.

    Number Brand
    4242424242424242 Visa
    4000056655665556 Visa (debit)
    5555555555554444 Mastercard
    2223003122003222 Mastercard (2-series)
    5200828282828210 Mastercard (debit)
    5105105105105100 Mastercard (prepaid)
    378282246310005 American Express
    371449635398431 American Express
    6011111111111117 Discover
    6011000990139424 Discover
    30569309025904 Diners Club
    38520000023237 Diners Club
    3566002020360505 JCB
    6200000000000005 UnionPay
    Payment Method Brand
    pm_card_visa Visa
    pm_card_visa_debit Visa (debit)
    pm_card_mastercard Mastercard
    pm_card_mastercard_debit Mastercard (debit)
    pm_card_mastercard_prepaid Mastercard (prepaid)
    pm_card_amex American Express
    pm_card_discover Discover
    pm_card_diners Diners Club
    pm_card_jcb JCB
    pm_card_unionpay UnionPay

    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 IDs when testing your integration, instead of passing card information directly to the API. Using these test IDs 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 test ID is human-readable and represents card information that has been tokenized with our client-side libraries.

    International test card numbers and payment methods

    You can use any of the following test cards to simulate a successful payment for different billing countries.

    Number Token Payment Method Country Brand
    4000000760000002 tok_br pm_card_br Brazil (BR) Visa
    4000001240000000 tok_ca pm_card_ca Canada (CA) Visa
    4000004840008001 tok_mx pm_card_mx Mexico (MX) Visa
    Number Token Payment Method Country Brand
    4000000400000008 tok_at pm_card_at Austria (AT) Visa
    4000000560000004 tok_be pm_card_be Belgium (BE) Visa
    4000002080000001 tok_dk pm_card_dk Denmark (DK) Visa
    4000002330000009 tok_ee pm_card_ee Estonia (EE) Visa
    4000002460000001 tok_fi pm_card_fi Finland (FI) Visa
    4000002500000003 tok_fr pm_card_fr France (FR) Visa
    4000002760000016 tok_de pm_card_de Germany (DE) Visa
    4000003000000030 tok_gr pm_card_gr Greece (GR) Visa
    4000003720000005 tok_ie pm_card_ie Ireland (IE) Visa
    4000003800000008 tok_it pm_card_it Italy (IT) Visa
    4000004280000005 tok_lv pm_card_lv Latvia (LV) Visa
    4000004400000000 tok_lt pm_card_lt Lithuania (LT) Visa
    4000004420000006 tok_lu pm_card_lu Luxembourg (LU) Visa
    4000005280000002 tok_nl pm_card_nl Netherlands (NL) Visa
    4000005780000007 tok_no pm_card_no Norway (NO) Visa
    4000006160000005 tok_pl pm_card_pl Poland (PL) Visa
    4000006200000007 tok_pt pm_card_pt Portugal (PT) Visa
    4000006430000009 tok_ru pm_card_ru Russian Federation (RU) Visa
    4000007050000006 tok_si pm_card_si Slovenia (SI) Visa
    4000007030000001 tok_sk pm_card_sk Slovakia (SK) Visa
    4000007240000007 tok_es pm_card_es Spain (ES) Visa
    4000007520000008 tok_se pm_card_se Sweden (SE) Visa
    4000007560000009 tok_ch pm_card_ch Switzerland (CH) Visa
    4000008260000000 tok_gb pm_card_gb United Kingdom (GB) Visa
    4000058260000005 tok_gb_debit pm_card_gb_debit United Kingdom (GB) Visa (debit)
    Number Token Payment Method Country Brand
    4000000360000006 tok_au pm_card_au Australia (AU) Visa
    4000001560000002 tok_cn pm_card_cn China (CN) Visa
    4000003440000004 tok_hk pm_card_hk Hong Kong (HK) Visa
    4000003920000003 tok_jp pm_card_jp Japan (JP) Visa
    3530111333300000 tok_jcb pm_card_jcb Japan (JP) JCB
    4000004580000002 tok_my pm_card_my Malaysia (MY) Visa
    4000005540000008 tok_nz pm_card_nz New Zealand (NZ) Visa
    4000007020000003 tok_sg pm_card_sg Singapore (SG) Visa

    Regulatory test card numbers

    Use the following card information to test payments affected by regional regulations such as Strong Customer Authentication (SCA).

    Number Description
    4000002500003155 This card requires authentication for one-time payments. However, if you set up this card and use the saved card for subsequent off-session payments, no further authentication is needed. In live mode, Stripe dynamically determines when a particular transaction requires authentication due to regional regulations such as Strong Customer Authentication.
    4000002760003184 This card requires authentication on all transactions, regardless of how the card is set up.
    4000008260003178 This card requires authentication for one-time payments. All payments will be declined with an insufficient_funds failure code even after being successfully authenticated or previously set up.
    4000003800000446 This card requires authentication for one-time and other on-session payments. However, all off-session payments will succeed as if the card has been previously set up.
    Payment Method Description
    pm_card_authenticationRequiredOnSetup This card requires authentication for one-time payments. However, if you set up this card and use the saved card for subsequent off-session payments, no further authentication is needed. In live mode, Stripe dynamically determines when a particular transaction requires authentication due to regional regulations such as Strong Customer Authentication.
    pm_card_authenticationRequired This card requires authentication on all transactions, regardless of how the card is set up.
    pm_card_authenticationRequiredChargeDeclinedInsufficientFunds This card requires authentication for one-time payments. All payments will be declined with an insufficient_funds failure code even after being successfully authenticated or previously set up.
    pm_card_authenticationRequiredSetupForOffSession This card requires authentication for one-time and other on-session payments. However, all off-session payments will succeed as if the card has been previously set up.

    3D Secure test card numbers

    Not all cards support 3D Secure or require the customer be redirected to their card issuer's authentication page. Use the following card information to test 3D Secure payments.

    Number 3D Secure usage Description
    4000000000003220 Required 3D Secure 2 authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    4000000000003063 Required 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    4000008400001629 Required 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card.
    4000000000003055 Supported 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card.
    4242424242424242 Supported 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card.
    378282246310005 Not supported 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.
    Token 3D Secure usage Description
    tok_threeDSecure2Required Required 3D Secure 2 authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    tok_threeDSecureRequired Required 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    tok_threeDSecureRequiredChargeDeclined Required 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card.
    tok_threeDSecureOptional Supported 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card.
    tok_visa Supported 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card.
    tok_amex_threeDSecureNotSupported Not supported 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.
    Payment Method 3D Secure usage Description
    pm_card_threeDSecure2Required Required 3D Secure 2 authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    pm_card_threeDSecureRequired Required 3D Secure authentication must be completed for the payment to be successful. By default, your Radar rules will request 3D Secure authentication for this card.
    pm_card_threeDSecureRequiredChargeDeclined Required 3D Secure authentication is required, but payments will be declined with a card_declined failure code after authentication. By default, your Radar rules will request 3D Secure authentication for this card.
    pm_card_threeDSecureOptional Supported 3D Secure authentication may still be performed, but is not required. By default, your Radar rules will not request 3D Secure authentication for this card.
    pm_card_visa Supported 3D Secure is supported for this card, but this card is not enrolled in 3D Secure. This means that if 3D Secure is requested by your Radar rules, the customer will not go through additional authentication. By default, your Radar rules will not request 3D Secure authentication for this card.
    pm_card_amex_threeDSecureNotSupported Not supported 3D Secure is not supported on this card and cannot be invoked. The PaymentIntent will proceed without performing authentication.

    All other Visa and Mastercard test cards do not require authentication from the customer's card issuer.

    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).

    Number Description
    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.
    4000000000000010 The address_line1_check and address_zip_check verifications fail. If your account is blocking payments that fail ZIP code validation, the charge is declined.
    4000000000000028 Charge succeeds but the address_line1_check verification fails.
    4000000000000036 The address_zip_check verification fails. If your account is blocking payments that fail ZIP code validation, the charge is declined.
    4000000000000044 Charge succeeds but the address_zip_check and address_line1_check verifications are both unavailable.
    4000000000005126 Charge succeeds but refunding a captured charge fails asynchronously with a failure_reason of expired_or_canceled_card. Note that because refund failures are asynchronous, the refund will appear to be successful at first and will only have the failed status on subsequent fetches. We also notify you of refund failures using the charge.refund.updated webhook event.
    4000000000000101 If a CVC number is provided, the cvc_check fails. If your account is blocking payments that fail CVC code validation, the charge is declined.
    4000000000000341 Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
    4000000000009235 Results in a charge with a risk_level of elevated.
    4000000000004954 Results in a charge with a risk_level of highest.
    4100000000000019 Results in a charge with a risk_level of highest. The charge is blocked as it's considered fraudulent.
    4000000000000002 Charge is declined with a card_declined code.
    4000000000009995 Charge is declined with a card_declined code. The decline_code attribute is insufficient_funds.
    4000000000009987 Charge is declined with a card_declined code. The decline_code attribute is lost_card.
    4000000000009979 Charge is declined with a card_declined code. The decline_code attribute is stolen_card.
    4000000000000069 Charge is declined with an expired_card code.
    4000000000000127 Charge is declined with an incorrect_cvc code.
    4000000000000119 Charge is declined with a processing_error code.
    4242424242424241 Charge is declined with an incorrect_number code as the card number fails the Luhn check.
    Payment Method Description
    pm_card_bypassPending Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).
    pm_card_domesticPricing Charge succeeds and domestic pricing is used (other test cards use international pricing). This card is only significant in countries with split pricing.
    pm_card_avsFail The address_line1_check and address_zip_check verifications fail. If your account is blocking payments that fail ZIP code validation, the charge is declined.
    pm_card_avsLine1Fail Charge succeeds but the address_line1_check verification fails.
    pm_card_avsZipFail The address_zip_check verification fails. If your account is blocking payments that fail ZIP code validation, the charge is declined.
    pm_card_avsUnchecked Charge succeeds but the address_zip_check and address_line1_check verifications are both unavailable.
    pm_card_refundFail Charge succeeds but refunding a captured charge fails asynchronously with a failure_reason of expired_or_canceled_card. Note that because refund failures are asynchronous, the refund will appear to be successful at first and will only have the failed status on subsequent fetches. We also notify you of refund failures using the charge.refund.updated webhook event.
    pm_card_cvcCheckFail If a CVC number is provided, the cvc_check fails. If your account is blocking payments that fail CVC code validation, the charge is declined.
    pm_card_chargeCustomerFail Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
    pm_card_riskLevelElevated Results in a charge with a risk_level of elevated.
    pm_card_riskLevelHighest Results in a charge with a risk_level of highest.
    pm_card_chargeDeclined Charge is declined with a card_declined code.
    pm_card_chargeDeclinedInsufficientFunds Charge is declined with a card_declined code. The decline_code attribute is insufficient_funds.
    pm_card_chargeDeclinedFraudulent Results in a charge with a risk level of highest. The charge is blocked as it's considered fraudulent.
    pm_card_chargeDeclinedIncorrectCvc Charge is declined with an incorrect_cvc code.
    pm_card_chargeDeclinedExpiredCard Charge is declined with an expired_card code.
    pm_card_chargeDeclinedProcessingError Charge is declined with a processing_error code.

    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)

    Disputes

    In test mode, you can use the test cards below to simulate a disputed transaction:

    Number Description
    4000000000000259 With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected if 3D Secure was run.
    4000000000002685 With default account settings, charge succeeds, only to be disputed as product not received. This type of dispute is not protected if 3D Secure was run.
    4000000000001976 With default account settings, charge succeeds, only to be disputed as an inquiry.
    4000000000005423 With default account settings, charge succeeds, only to receive an early fraud warning.
    Payment Method Description
    pm_card_createDispute With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected if 3D Secure was run.
    pm_card_createDisputeProductNotReceived With default account settings, charge succeeds, only to be disputed as product not received. This type of dispute is not protected if 3D Secure was run.
    pm_card_createDisputeInquiry With default account settings, charge succeeds, only to be disputed as an inquiry.

    The following evidence, when submitted in the uncategorized_text, produces specific actions that are useful for testing the dispute flow:

    Evidence Description
    winning_evidence The dispute is closed and marked as won. Your account is credited the amount of the charge and related fees.
    losing_evidence The dispute is closed and marked as lost. Your account is not credited.

    Rate limits

    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.

    The rate limit in test mode is lower than the one in live mode. If you are experiencing rate limits but are unable to determine why, please let us know.

    Webhooks

    To test your integration, perform actions using the API (in test mode) to send legitimate events to your endpoint. For instance, creating a charge triggers the charge.succeeded event that contains the charge data. You can then use the API to verify the resulting event data. If you're migrating to the Payment Intents API, also see Monitoring a PaymentIntent with Webhooks.

    You can also send test events to your integration's endpoint within your account's webhooks settings. However, the event data contained within these events is fabricated and not available in the API—its purpose is only to test that your endpoint is working and configured correctly.

    Was this page helpful?

    Thank you for helping improve Stripe's documentation. If you need help or have any questions, please consider contacting support.

    On this page