Testing
Stripe provides a number of resources for testing your integration. Make sure to test the following use cases before launch, and use our Postman collection to make the testing process simpler.
Each Stripe account includes a test and live mode. Test mode includes a separate set of data and API keys that you can use exclusively for testing your integration; we recommend using test mode to build the integration and replace your test keys with live keys when you’re ready to go live.
You’re welcome to test on as many accounts as you’d like; however, if you create a new test account, make sure to let your Stripe contact know so they can apply any custom configurations. You can open additional Stripe accounts directly from the Dashboard.
QA testing use cases
USE CASE | ACTION |
---|---|
Creating customers and saving a payment method. | Depending on the order of the checkout flow, there are several possible sequences of API calls that will create customer objects with a payment method. Ensure the invoice_settings.default_payment_method field within the customer object is populated.
|
Creating, finalizing, and paying invoices |
|
Creating, updating, and canceling subscriptions |
|
Create trial subscriptions and handle trial conversions |
|
Create credit notes (refunds or credits) |
|
Handle a failed payment on an invoice | Invoice should still be open and with a “Failed” payment in the Stripe Dashboard and return the below:
|
Radar block | No matter which version of Radar you use, a charge may be blocked due to high risk, or because of a rule. The response will be the same as above in Charge fail. |
Charge disputed | Charge should show as “Disputed” in “Payments.” Charge amount plus dispute fee should be debited from the balance, and a Dispute object should be created (and its associated charge.dispute.created event):
|
Charge inquiry opened | Inquiries are similar to disputes, with three key distinctions: no funds are withdrawn unless the inquiry is elevated to a dispute, they remain refundable until disputed, and have a different set of statuses. A charge.dispute.created event is fired:
|
Dispute won | When a dispute is won, the funds of the original charge are restored to the account, less the dispute fee. The existing Dispute object is updated (and a charge.dispute.closed event is fired):
|
Dispute lost | When a dispute is lost, the existing Dispute object is updated (and a charge.dispute.closed event is fired):
|
Inquiry won | When an inquiry is won, your balance remains the same, as no funds were removed when the inquiry was initially opened. The existing Dispute object is updated (and a charge.dispute.closed event is fired):
|
Inquiry lost | When an inquiry is lost, it will escalate to a dispute. At that time the status will be changed with a charge.dispute.updated event, and funds will be withdrawn in a charge.dispute.funds_withdrawn event:
|
Account balance goes negative | Ensure that your bank accounts can accept debits from Stripe, and test a negative balance on Stripe. |
Successful payout | If you’ve enabled webhooks for a successful payout (recommended), test your handling of the event. |
Failed payout | If you’ve enabled webhooks for a failed payout (recommended), test your handling of the event. |
Postman collection
Postman is a widely-used API development tool. To make integrating Stripe simpler, we provide a Billing-specific Postman collection with the tools you’ll need to test the server-side component of your integration.
Importing the collection
To get started, you’ll need access to the Postman application. The app is available in a browser-based version or a standalone desktop version. As soon as you have either version launched, the first step is to import the collection:
Desktop
Go to File > Import.
Web
Click the Import button on the upper left hand corner.
Select the tab titled Link and paste in the link for the Billing collection:

The Import Modal
You’ll now see the top level collection listed in your instance of Postman.
Using the collection
To get started, populate the {{secret_key}} collection variable. To do this, navigate to the collection you just imported in the workspace and you’ll see a tab titled Variables as shown below.

The Variables Tab for the Collection
Copy your testmode Stripe secret key from the Stripe Dashboard and paste it into the field titled Initial Value. When you’ve done that, you’re ready to begin making requests.
Other variables will get populated by scripts during the runtime of the collection. For example, when creating a customer or price, a script in the collection will save that ID to be used in subsequent requests, such as to create a subscription.
Start with the requests to create Customer objects, because these are required for any Billing implementation. The collection contains two Customers, one that stores a successful test payment method, and another that stores a failing test payment method. In both cases, the returned customer IDs are saved as collection level variables. If you’d like to create more customers to simulate other scenarios, replace the test payment method with another from this page.
Next, you can run the requests to create products and prices, as these are used heavily in the requests to create invoices and subscriptions. As with the customer requests, the associated IDs will be saved as collection variables.
Additional testing resources
We recommend using the following Stripe documentation to test your integration:
- The Stripe testing guide provides test card numbers to simulate successful or failing transactions, disputes, bank accounts, and more.
- The Integration security guide contains information about PCI compliance, secure connections, and other relevant security topics.