Skip to content
Create account
or
Sign in
The Stripe Docs logo
/
Ask AI
Create account
Sign in
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Developer tools
Get started
Payments
Finance automation
Get started
Payments
Finance automation
Platforms and marketplaces
Money management
Overview
Versioning
Changelog
Upgrade your API version
Upgrade your SDK version
Developer tools
SDKs
API
    API v2
    API keys
    Stripe-Context header
    Daily changelog
    Rate limits
    Automated testing
    Metadata
    Expanding responses
    Pagination
    Domains and IP addresses
    Search
    Localization
    Error handling
    Error codes
Testing
Workbench
Event Destinations
Workflows
Stripe CLI
Stripe Shell
Developers Dashboard
Agent toolkit
Stripe health alertsBuild with LLMsStripe for Visual Studio CodeFile uploads
Security
Security
Extend Stripe
Stripe Apps
Stripe Connectors
Partners
Partner ecosystem
Partner certification
HomeDeveloper toolsAPI

Automated testing

Learn how to use automated testing in your Stripe integration.

Copy page

Automated testing is a common part of application development, both for server and client-side code. Frontend interfaces, like Stripe Checkout or the Payment Element, have security measures in place that prevent automated testing, and Stripe APIs are rate limited. However, you can simulate the output of our interfaces and API requests using mock data to test your application behavior and its ability to handle errors.

Client side testing

If you want to test your application’s ability to recover from errors such as transaction declines when using the Payment Element, you can return a simulated error object by hard-coding error objects in your test code, or creating an API service that returns mock errors in an HTTP response. The error object represents what would be returned by the confirmPayment function when a card is declined. See the following section to learn how you can generate a simulated error object.

Generating an error object

First, manually use a Stripe UI element such as the Payment Element to produce an error object by confirming a test Payment Intent using one of the test card numbers for declined payments. Log the error during the confirmation process as shown below.

client.js
const { error } = await stripe.confirmPayment({ elements, confirmParams: { return_url: 'https://example.com' }, }) ; if (error) { console.log(error) }

This produces an error object logged to the browser console that resembles the one shown below. The specifics for properties such as error_code depend on the card used and the type of error it generates.

{ "charge": "{{CHARGE_ID}}", "code": "card_declined", "decline_code": "generic_decline", "doc_url": "https://docs.stripe.com/error-codes#card-declined", "message": "Your card has been declined.", "payment_intent": {"id": "{{PAYMENT_INTENT_ID}}", …}, "payment_method": {"id": "{{PAYMENT_METHOD_ID}}", …}, "request_log_url": "https://dashboard.stripe.com/test/logs/req_xxxxxxx", "type": "card_error" }

Modify your tests to return this error object instead of calling Stripe.js functions and the Stripe APIs. You can use different test cards to generate errors with different error codes to make sure your application properly handles each type of error.

Server side testing

You can use the same approach when testing server-side API calls. You can generate Stripe API responses manually for various errors and mock the response returned in backend automated testing.

For example, to write a test to validate that your application can correctly handle an off-session payment requiring 3DS, you can generate the response by creating a Payment Intent with the Payment Method pm_card_authenticationRequired and confirm set to true.

Command Line
cURL
curl https://api.stripe.com/v1/payment_intents \ -u "
sk_test_BQokikJOvBiI2HlWgH4olfQ2
:"
\ -d amount=2099 \ -d currency=usd \ -d payment_method=pm_card_authenticationRequired \ -d confirm=true \ -d off_session=true

This generates a Payment Intent with a status of requires_confirmation, and other properties associated with 3DS Authentication like next_action.

{ "id": "{{PAYMENT_INTENT_ID}}", "object": "payment_intent", ... "next_action": { "type": "use_stripe_sdk", ... }, ... "status": "requires_confirmation", ... }

Generating PaymentIntent objects that reflect different stages of the Payment lifecycle allows you to test your application’s behavior as the PaymentIntent transitions through various states. Use this approach in your automated testing to make sure your integration can successfully respond to different outcomes, such as requesting that the customer comes back on-session to authenticate a payment that requires a next action.

When to use this approach

The above examples all reference testing the behavior of your application and are suitable to use in a continuous integration test suite. When you need to perform tests to validate the response of the Stripe API, making requests to the API in a testing environment is an acceptable approach. You can also use Stripe API requests to periodically validate that Stripe API responses haven’t changed—but you should perform these tests infrequently to avoid rate limits.

Was this page helpful?
YesNo
Need help? Contact Support.
Join our early access program.
Check out our changelog.
Questions? Contact Sales.
LLM? Read llms.txt.
Powered by Markdoc