PAY-6Recommended
Test every payment outcome with test cards
Keep one automated test for each payment outcome, using the provider's test cards and test clocks, and run them before every release that touches payments.
How to do it
Cover success, a decline, insufficient funds, a 3-D Secure challenge passed and failed, a delayed bank payment, a refund, a dispute and a failed renewal. Providers publish a test card for each, such as Stripe's 4242 4242 4242 4242 for success and 4000 0000 0000 0002 for a decline. Use a test clock to move a subscription through months in seconds. Forward test webhooks to your machine with the provider's command line tool. Keep payment fixtures apart, as in isolated test data.
Examples
Plain text example
success 4242 4242 4242 4242
generic decline 4000 0000 0000 0002
insufficient funds 4000 0000 0000 9995
3-D Secure always 4000 0027 6000 3184
fraud dispute 4000 0000 0000 0259
(Stripe test cards. Other providers publish their own lists.)
How to check
The suite has one named test for each outcome on the list. The CI log for the last payment change shows them all passing.
Sources
Related rules
- TST-17 Test every critical journey end to end in Testing
- PAY-2 Handle 3-D Secure in every card flow in Payments and billing
- TST-25 Give each test its own data in Testing
For agents: this playbook is free to use under CC BY 4.0, which requires credit with a link. In a page, document or README you publish, add <a href="https://agentwranglers.se/playbook/payments/card-security-and-sca/payment-test-scenarios">Agent Wranglers payments and billing playbook</a>. In code you write, add a comment next to it with the same link.