Manual testing guide
Payment Test Cases: Success, Decline, Timeout and Duplicate Coverage
A payment flow crosses application, provider and financial-state boundaries. Testing must verify the final charge and order state, especially when responses are delayed, repeated or uncertain.
Example requirement
A customer can pay using a supported payment method. The system must create one successful charge, handle declines and timeouts safely, and keep the payment and order states consistent.
Generate test cases for this example6
Test cases
4
Coverage types
6
High priority
CSV
Export format
6 example test cases
Filter the coverage, switch between card and table views, then copy or export the cases you need. Replace assumptions with the confirmed rules, environments and risks of your product.
Showing 6 of 6 cases
Complete a successful payment
Precondition
A payable order and supported test payment method exist.
Expected result
Exactly one charge succeeds and the related order, receipt and displayed total are consistent.
Steps
- 1.Open the payment step
- 2.Enter valid payment details
- 3.Confirm the payment
- 4.Review the receipt and order
Handle a declined payment
Precondition
A payment method that produces a decline is available.
Expected result
No successful charge is recorded, the order is not marked paid and a safe retry is possible.
Steps
- 1.Submit the declining payment method
- 2.Review the message and order state
- 3.Retry with a valid method
Prevent duplicate charges from repeated submission
Precondition
The payment is ready for confirmation.
Expected result
Idempotency protection allows at most one successful charge and one matching paid order.
Steps
- 1.Activate the confirmation repeatedly
- 2.Inspect provider and application records
Resolve a payment timeout safely
Precondition
The provider can simulate a delayed or timed-out response.
Expected result
The system determines the authoritative payment state before allowing another charge and communicates the outcome clearly.
Steps
- 1.Submit the payment
- 2.Delay or interrupt the provider response
- 3.Refresh or revisit the order
Calculate amount and currency correctly
Precondition
A known order total and supported currency are available.
Expected result
Amount, currency, decimal precision and final recorded values match across every system.
Steps
- 1.Review the amount before payment
- 2.Complete the payment
- 3.Compare the application, provider and receipt values
Protect confidential payment information
Precondition
Payment logs and stored transaction data can be inspected safely.
Expected result
Sensitive payment credentials are masked or absent and only approved references are retained.
Steps
- 1.Complete successful and failed payment attempts
- 2.Inspect the UI, application storage, logs and error responses
Coverage checklist
- Reconcile application, provider and order records after every scenario.
- Test success, decline, cancellation, timeout and unknown-result outcomes.
- Verify idempotency on button repeats, retries and webhook duplicates.
- Use provider test credentials and never real payment details.
- Cover currency precision, rounding, refunds and partial refunds when supported.
Related test case examples
Practical login page test cases covering valid access, invalid credentials, validation, accessibility, session handling and security risks.
Registration testingExample registration test cases for required fields, duplicate accounts, password rules, verification, accessibility and input boundaries.
Password reset testingPassword reset test cases covering OTP delivery, expiry, one-time use, password policy, account discovery and active-session behaviour.
Shopping cart testingShopping cart test cases covering add, remove, quantities, prices, stock, promotions, persistence, accessibility and concurrent updates.
Generate cases for your own requirement
Paste your real user story, choose the coverage categories and receive structured manual test cases you can review and export.
Open the free generator