Testing

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

This page includes test card numbers and other information to make sure your integration works as planned. Use it to trigger different flows in your integration and ensure they are handled accordingly.

Payment Intents API

When using the Payment Intents API with Stripe's client libraries and 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.

Charges API

When using the Charges API with Stripe's client libraries and SDKs, ensure that:

  • The card Element is passed correctly to createToken in your submit handler.
  • 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.

Server-side code

In your server-side code, 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.

Basic test card numbers

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

Number Brand CVC Date
4242424242424242 Visa Any 3 digits Any future date
4000056655665556 Visa (debit) Any 3 digits Any future date
5555555555554444 Mastercard Any 3 digits Any future date
2223003122003222 Mastercard (2-series) Any 3 digits Any future date
5200828282828210 Mastercard (debit) Any 3 digits Any future date
5105105105105100 Mastercard (prepaid) Any 3 digits Any future date
378282246310005 American Express Any 4 digits Any future date
371449635398431 American Express Any 4 digits Any future date
6011111111111117 Discover Any 3 digits Any future date
6011000990139424 Discover Any 3 digits Any future date
3056930009020004 Diners Club Any 3 digits Any future date
36227206271667 Diners Club (14 digit card) Any 3 digits Any future date
3566002020360505 JCB Any 3 digits Any future date
6200000000000005 UnionPay Any 3 digits Any future date
Token Brand
tok_visa Visa
tok_visa_debit Visa (debit)
tok_mastercard Mastercard
tok_mastercard_debit Mastercard (debit)
tok_mastercard_prepaid Mastercard (prepaid)
tok_amex American Express
tok_discover Discover
tok_diners Diners Club
tok_jcb JCB
tok_unionpay 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

We recommend using our test IDs when testing your integration and creating charges, 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 (e.g., Stripe Elements, Stripe.js).

International test card numbers

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

Number Token Payment Method Country Brand
4242424242424242 tok_us pm_card_us United States (US) Visa
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
4000001000000000 tok_bg pm_card_bg Bulgaria (BG) Visa
4000001960000008 tok_cy pm_card_cy Cyprus (CY) Visa
4000002030000002 tok_cz pm_card_cz Czech Republic (CZ) 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
4000004700000007 tok_mt pm_card_mt Malta (MT) 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
4000006420000001 tok_ro pm_card_ro Romania (RO) Visa
4000006430000009 tok_ru pm_card_ru Russian Federation (RU) 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
4000003560000008 tok_in pm_card_in India (IN) 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 (3D Secure) test card numbers

The following card information tests payments affected by regional regulations such as Strong Customer Authentication (SCA). Use it to test saving cards with the Setup Intents API.

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.
4000053560000011 This card requires authentication on all transactions, regardless of how you set it up. You can only use this card for INR payments.
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 and tokens

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.
4000008400001280 Required 3D Secure authentication is required, but the 3D Secure lookup request will fail with a processing error. Payments will be declined with a card_declined failure code. 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.
4000000000003097 Supported 3D Secure authentication may still be performed, but is not required. However, attempts to perform 3D Secure result in a processing error. 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_threeDSecureRequiredProcessingError Required 3D Secure authentication is required, but the 3D Secure lookup request will fail with a processing error. Payments will be declined with a card_declined failure code. 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_threeDSecureOptionalProcessingError Supported 3D Secure authentication may still be performed, but is not required. However, attempts to perform 3D Secure result in a processing error. 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_threeDSecureRequiredProcessingError Required 3D Secure authentication is required, but the 3D Secure lookup request will fail with a processing error. Payments will be declined with a card_declined failure code. 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_threeDSecureOptionalProcessingError Supported 3D Secure authentication may still be performed, but is not required. However, attempts to perform 3D Secure result in a processing error. 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).
4000003720000278 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.
Token Description
tok_bypassPending Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).
tok_bypassPendingInternational 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_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.
tok_avsLine1Fail Charge succeeds but the address_line1_check verification fails.
tok_avsZipFail The address_zip_check verification fails. If your account is blocking payments that fail ZIP code validation, the charge is declined.
tok_avsUnchecked Charge succeeds but the address_zip_check and address_line1_check verifications are both unavailable.
tok_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.
tok_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.
tok_chargeCustomerFail Attaching this card to a Customer object succeeds, but attempts to charge the customer fail.
tok_riskLevelElevated Results in a charge with a risk_level of elevated.
tok_riskLevelHighest Results in a charge with a risk_level of highest.
tok_chargeDeclined Charge is declined with a card_declined code.
tok_chargeDeclinedInsufficientFunds Charge is declined with a card_declined code. The decline_code attribute is insufficient_funds.
tok_chargeDeclinedFraudulent Results in a charge with a risk level of highest. The charge is blocked as it's considered fraudulent.
tok_chargeDeclinedIncorrectCvc Charge is declined with an incorrect_cvc code.
tok_chargeDeclinedExpiredCard Charge is declined with an expired_card code.
tok_chargeDeclinedProcessingError Charge is declined with a processing_error code.
Payment Method Description
pm_card_bypassPending Charge succeeds and funds will be added directly to your available balance (bypassing your pending balance).
pm_card_bypassPendingInternational 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.
Token Description
tok_createDispute With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected if 3D Secure was run.
tok_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.
tok_createDisputeInquiry With default account settings, charge succeeds, only to be disputed as an inquiry.
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.

Sources

Use the following information when testing payments using Sources.

Redirect sources

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 redirect[return_url].

SEPA Direct Debit

You can create a test PaymentIntent that either succeeds or fails by doing the following:

  1. Create a test PaymentMethod with a test account number.
  2. Use the resulting PaymentMethod in a confirmSepaDebitPayment request to create the test charge.
Test account numbers
Account Number Description
AT611904300234573201 The PaymentIntent status transitions from processing to succeeded.
AT321904300235473204 The PaymentIntent status transitions from processing to succeeded after three minutes.
AT861904300235473202 The PaymentIntent status transitions from processing to requires_payment_method.
AT051904300235473205 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
AT591904300235473203 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
BE62510007547061 The PaymentIntent status transitions from processing to succeeded.
BE78510007547064 The PaymentIntent status transitions from processing to succeeded after three minutes.
BE68539007547034 The PaymentIntent status transitions from processing to requires_payment_method.
BE51510007547065 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
BE08510007547063 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
EE382200221020145689 The PaymentIntent status transitions from processing to succeeded.
EE222200221020145682 The PaymentIntent status transitions from processing to succeeded after three minutes.
EE762200221020145680 The PaymentIntent status transitions from processing to requires_payment_method.
EE922200221020145683 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
EE492200221020145681 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
FI2112345600000785 The PaymentIntent status transitions from processing to succeeded.
FI3712345600000788 The PaymentIntent status transitions from processing to succeeded after three minutes.
FI9112345600000786 The PaymentIntent status transitions from processing to requires_payment_method.
FI1012345600000789 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
FI6412345600000787 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
FR1420041010050500013M02606 The PaymentIntent status transitions from processing to succeeded.
FR3020041010050500013M02609 The PaymentIntent status transitions from processing to succeeded after three minutes.
FR8420041010050500013M02607 The PaymentIntent status transitions from processing to requires_payment_method.
FR7920041010050500013M02600 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
FR5720041010050500013M02608 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
DE89370400440532013000 The PaymentIntent status transitions from processing to succeeded.
DE08370400440532013003 The PaymentIntent status transitions from processing to succeeded after three minutes.
DE62370400440532013001 The PaymentIntent status transitions from processing to requires_payment_method.
DE78370400440532013004 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
DE35370400440532013002 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
IE29AIBK93115212345678 The PaymentIntent status transitions from processing to succeeded.
IE24AIBK93115212345671 The PaymentIntent status transitions from processing to succeeded after three minutes.
IE02AIBK93115212345679 The PaymentIntent status transitions from processing to requires_payment_method.
IE94AIBK93115212345672 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
IE51AIBK93115212345670 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
LT121000011101001000 The PaymentIntent status transitions from processing to succeeded.
LT281000011101001003 The PaymentIntent status transitions from processing to succeeded after three minutes.
LT821000011101001001 The PaymentIntent status transitions from processing to requires_payment_method.
LT981000011101001004 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
LT551000011101001002 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
LU280019400644750000 The PaymentIntent status transitions from processing to succeeded.
LU440019400644750003 The PaymentIntent status transitions from processing to succeeded after three minutes.
LU980019400644750001 The PaymentIntent status transitions from processing to requires_payment_method.
LU170019400644750004 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
LU710019400644750002 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
NL39RABO0300065264 The PaymentIntent status transitions from processing to succeeded.
NL55RABO0300065267 The PaymentIntent status transitions from processing to succeeded after three minutes.
NL91ABNA0417164300 The PaymentIntent status transitions from processing to requires_payment_method.
NL28RABO0300065268 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
NL82RABO0300065266 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
NO9386011117947 The PaymentIntent status transitions from processing to succeeded.
NO8886011117940 The PaymentIntent status transitions from processing to succeeded after three minutes.
NO6686011117948 The PaymentIntent status transitions from processing to requires_payment_method.
NO6186011117941 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
NO3986011117949 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
PT50000201231234567890154 The PaymentIntent status transitions from processing to succeeded.
PT66000201231234567890157 The PaymentIntent status transitions from processing to succeeded after three minutes.
PT23000201231234567890155 The PaymentIntent status transitions from processing to requires_payment_method.
PT39000201231234567890158 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
PT93000201231234567890156 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
SE3550000000054910000003 The PaymentIntent status transitions from processing to succeeded.
SE5150000000054910000006 The PaymentIntent status transitions from processing to succeeded after three minutes.
SE0850000000054910000004 The PaymentIntent status transitions from processing to requires_payment_method.
SE2450000000054910000007 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
SE7850000000054910000005 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.
Account Number Description
ES0700120345030000067890 The PaymentIntent status transitions from processing to succeeded.
ES2300120345030000067893 The PaymentIntent status transitions from processing to succeeded after three minutes.
ES9121000418450200051332 The PaymentIntent status transitions from processing to requires_payment_method.
ES9300120345030000067894 The PaymentIntent status transitions from processing to requires_payment_method after three minutes.
ES5000120345030000067892 The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created.

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?
Questions? Contact us.
Developer tutorials on YouTube.
You can unsubscribe at any time. Read our privacy policy.