Browse the Knowledge Hub32 resources
Test cases
Payment test cases that live in the failure paths
Thirty cases across 3D Secure, declines, gateway timeouts, duplicate charge prevention, replayed requests, stock reservation, refunds, partial capture, webhook ordering and what your logs must never contain. Every case here assumes the provider will misbehave, because eventually it does.
All 30 test cases, ready to copy
Free to use and adapt, no sign-up. Download as CSV or Markdown, or copy it straight into your own tooling.
Last updated
30 worked examples
Complete a purchase with a valid card
TypeFunctionalPriorityHigh- Test data
- Provider test card that authorises without a challenge
- Expected result
- Payment authorised, order created once, confirmation shown, confirmation email sent, amount charged equals the amount displayed.
Complete a purchase requiring 3D Secure
TypeFunctionalPriorityHigh- Test data
- Provider test card that triggers the authentication challenge
- Expected result
- Challenge presented, completed, and the user returned to a confirmed order. Works on mobile, where the challenge may open in a new context.
Abandon the 3D Secure challenge
TypeNegativePriorityHigh- Test data
- Close the challenge, or leave it until it times out
- Expected result
- No charge, no order, cart intact, and a clear message inviting a retry. The most commonly broken case on this list.
Handle a card decline
TypeNegativePriorityHigh- Test data
- Provider test cards for generic decline, insufficient funds and expired card
- Expected result
- Specific and safe messaging, no order created, no stock consumed, cart preserved, retry possible without re-entering everything.
Handle a card flagged as fraudulent
TypeNegativePriorityHigh- Test data
- Provider fraud test card
- Expected result
- Refused without disclosing the reason to the user. Event recorded for review. No hint that helps a card tester tune their attempt.
Reject invalid card details client side and server side
TypeNegativePriorityHigh- Test data
- Failed Luhn check, past expiry date, two digit security code
- Expected result
- Field level validation, and the same rules enforced if the request is sent directly.
Payment succeeds but the provider response is lost
TypeStatePriorityHigh- Test data
- Drop the response after authorisation, or kill the tab mid request
- Expected result
- Reconciliation through webhook or a status poll creates the order exactly once. Money taken with no order is the worst outcome in this table.
Retry after a timeout without double charging
TypeStatePriorityHigh- Test data
- Force a gateway timeout, then submit again
- Expected result
- An idempotency key ensures one charge. Two authorisations for one intent is a refund, a support ticket and a chargeback risk.
Double click the pay button
TypeStatePriorityHigh- Test data
- Two rapid submissions
- Expected result
- One charge, one order. Control disabled while in flight and the request idempotent.
Replay the payment request
TypeSecurityPriorityHigh- Test data
- Capture and resend the authorisation request
- Expected result
- Rejected as already processed. No second charge, no second order.
Tamper with the amount in the payment request
TypeSecurityPriorityHigh- Test data
- Reduce the amount, change the currency, alter the order reference
- Expected result
- Server computes the amount from the order and ignores the client value. Mismatched intents are refused, not reconciled.
Reuse a payment intent belonging to another order
TypeSecurityPriorityHigh- Test data
- Substitute a valid intent identifier from a different order
- Expected result
- Refused. Intents are bound to one order and one session.
Access another user order confirmation
TypeSecurityPriorityHigh- Test data
- Change the order identifier in the confirmation URL
- Expected result
- Refused. Order pages are authorised against the session, and guest orders require a signed token rather than a sequential number.
Verify stock is reserved and released correctly
TypeStatePriorityHigh- Test data
- Last unit in stock, two users at checkout simultaneously
- Expected result
- One succeeds and one is told clearly before payment. Overselling the last unit is the failure to prevent, and abandoned checkouts release the reservation.
Apply a discount at checkout and verify the charged amount
TypeFunctionalPriorityHigh- Test data
- Percentage code plus shipping and tax
- Expected result
- The authorised amount matches the displayed total to the penny, with the discount applied to the correct base.
Calculate tax by billing and shipping address
TypeFunctionalPriorityHigh- Test data
- Domestic, cross border and a tax exempt case as applicable
- Expected result
- Correct rate applied and recalculated when the address changes. Tax computed before the address is known must not be the charged figure.
Change address or shipping method after entering payment details
TypeStatePriorityHigh- Test data
- Return a step and change the delivery option
- Expected result
- Totals recalculate and the payment intent is updated, so the amount authorised reflects the final choice.
Validate address and postcode formats by country
TypeBoundaryPriorityMedium- Test data
- Postcodes for several supported countries, plus a country with no postcode system
- Expected result
- Accepted per country rules, and countries without postcodes are not blocked by a required field.
Pay with each supported alternative method
TypeFunctionalPriorityHigh- Test data
- Wallet, bank redirect, buy now pay later, saved card as supported
- Expected result
- Each completes and each fails safely. Redirect methods must survive the user pressing back mid flow.
Use a saved card and verify no full details are exposed
TypeSecurityPriorityHigh- Test data
- Saved payment method on an authenticated account
- Expected result
- Only the last four digits and brand are shown, the token is scoped to that user, and no full number is retrievable through any endpoint.
Interrupt the flow on mobile
TypeStatePriorityHigh- Test data
- Incoming call, app backgrounded, or the device rotated during payment
- Expected result
- On return, the state is recoverable and unambiguous. No duplicate charge and no order stuck in a pending state with no resolution path.
Pay on a slow or unstable connection
TypePerformancePriorityHigh- Test data
- Throttle to 2G with packet loss
- Expected result
- One charge, one order, and clear progress feedback. Users retry when nothing happens, which is exactly how duplicates are created.
Refund a payment in full
TypeFunctionalPriorityHigh- Test data
- Completed order refunded from the admin side
- Expected result
- Provider refund succeeds, order status updates, stock is returned if that is the policy, and the customer is notified.
Refund partially, then attempt to over refund
TypeBoundaryPriorityHigh- Test data
- Refund half, then attempt to refund more than the remaining balance
- Expected result
- Partial refund succeeds, over refund is refused, and the running balance stays correct.
Capture after authorisation, including expiry
TypeStatePriorityHigh- Test data
- Authorise, wait beyond the authorisation validity window, then capture
- Expected result
- Expired authorisations are handled explicitly rather than failing silently at fulfilment, which is where orders go missing.
Process webhooks out of order and more than once
TypeStatePriorityHigh- Test data
- Deliver success twice, deliver failure after success, deliver an unknown event type
- Expected result
- Handlers are idempotent, ordering is not assumed, signatures are verified, and unknown events are logged rather than crashing the endpoint.
Behaviour when the payment provider is unavailable
TypeNegativePriorityHigh- Test data
- Provider returning errors, then timing out entirely
- Expected result
- Checkout degrades with an honest message, no order is created in a paid state, and the cart survives for a later attempt.
Verify currency handling and rounding
TypeBoundaryPriorityHigh- Test data
- Zero decimal currency, three decimal currency, and a converted amount
- Expected result
- Minor units are correct for the currency, the charged amount matches the display exactly, and the exchange rate used is recorded on the order.
Check what is written to logs and analytics
TypeSecurityPriorityHigh- Test data
- Complete a payment with logging at its most verbose
- Expected result
- No card number, security code or full token in logs, error trackers, analytics payloads or session recordings. This is a compliance requirement, not a preference.
Complete checkout by keyboard and screen reader
TypeAccessibilityPriorityHigh- Test data
- Keyboard only, then NVDA or VoiceOver, including the hosted card fields
- Expected result
- All fields reachable and labelled, errors announced, and the provider hosted iframe fields are operable. Payment forms are the highest cost accessibility failure in a product.
What goes in each field
ID
RequiredStable identifier, prefixed by module.
Test case
RequiredWhat is being verified, in one line.
Type
Functional, negative, boundary, security, state, performance, accessibility or compatibility. Use it to check coverage is spread rather than clustered on the happy path.
Priority
Risk based. Anything that can charge twice, charge the wrong amount, or take money without creating an order is High. There is no low priority defect on a payment path.
Test data
The specific values, including the invalid and boundary ones.
Expected result
RequiredThe precise observable outcome, including message text where the wording itself is the requirement.
Stub the provider and break it deliberately
A gateway will not decline, time out or duplicate on request, so the only way to cover these paths is to simulate them.
Kill the response, not the request
Authorise successfully, then drop the response. Money taken with no order created is the worst outcome on this page.
Retry everything twice
Resubmit, replay, double click. Without an idempotency key every one of those becomes a second charge.
Abandon the challenge
Close the 3D Secure window mid flow. The state left behind is wrong more often than it is right.
Read your own logs
Check logs, error trackers, analytics and session recordings for card data after a successful payment.
The four cases that cost the most
A lost provider response is the highest consequence defect in payments. The charge succeeds, your application never learns about it, and the customer has paid for nothing. Reconciliation through a verified webhook or a status poll, creating the order exactly once, is the only correct answer. Test it by dropping the response after authorisation, not by cancelling before it.
Duplicate charges are the same class of problem seen from the other side. Users retry when a page appears to hang, particularly on a slow connection, and without an idempotency key each retry is a fresh authorisation. Force a timeout, submit again, and assert one charge and one order.
Webhooks are where integrations quietly rot. They arrive twice, they arrive out of order, they arrive for event types that did not exist when the handler was written. Handlers must verify the signature, be idempotent, avoid assuming order, and log unknown events rather than failing. Test all four.
The logging case is the one nobody runs, and it is a compliance exposure rather than a bug. Complete a payment with verbose logging enabled and search every sink for card data, including error tracking payloads and session replay tools, which capture form fields far more often than teams realise.
Suggest an improvementPayments in scope?
QAble tests payment flows against provider sandboxes and stubbed failures, including duplicate charge prevention and webhook reconciliation.
E-commerce testing servicesMore test case sets
View allTest cases for a login page
Test cases25 cases across functional, negative, boundary, security, session and accessibility paths, including account enumeration and lockout.Test cases for a registration form
Test cases28 cases covering validation, duplicate accounts, email verification, password rules and the enumeration leak most signup forms ship with.Test cases for search functionality
Test cases28 cases across relevance, partial and fuzzy matching, filters, pagination, empty states, injection attempts and performance under load.Test cases for a shopping cart
Test cases27 cases on quantity limits, price recalculation, stock changes, coupon stacking, guest to account merge and cart persistence.Test cases for file upload
Test cases28 cases on size and type limits, spoofed content types, malicious filenames, progress, resume, virus scanning and storage limits.Test cases for forgot password
Test cases26 cases on reset token expiry, single use enforcement, session invalidation and the enumeration and rate limit gaps that are routine here.Test cases for OTP verification
Test cases26 cases on expiry, resend throttling, attempt limits, code reuse, delivery failure and the brute force window teams forget to close.Test cases for user roles and permissions
Test cases26 cases on horizontal and vertical privilege checks, direct object access, role changes mid-session and permission inheritance.Test cases for form validation
Test cases27 rules-based cases on required fields, length and numeric boundaries, client and server parity, hidden field tampering and error accessibility.Test cases for a date picker
Test cases26 cases on timezone shifts, ambiguous day and month order, impossible dates, min and max limits, leap years and keyboard operation.Test cases for pagination
Test cases24 cases on ordering stability, records changing mid-session, page size caps, deep offset cost, permission-filtered totals and state restore.Test cases for push notifications
Test cases26 cases on app states, deep link routing, token release on sign out, lock screen privacy, preferences, provider failures and platform differences.Test cases for reports and data export
Test cases25 cases on permission filtering in the file, spreadsheet formula injection, encoding, typed numbers and dates, row limits and audit logging.Test cases for a chatbot
Test cases28 cases on paraphrased intents, context, fallback loops, human handoff, policy grounding, prompt injection and data scoping.Sources
- EMVCo 3-D Secure the authentication flow the challenge cases exercise.
- PCI Security Standards the logging and storage rules behind the PCI cases.
- OWASP ASVS verification requirements for authentication, session and access control.
- WCAG 2.2 the success criteria behind the accessibility cases.
Want payment paths proven, not assumed?
QAble tests checkout and payment end to end with ISTQB-certified engineers. Start with a free QA audit of your product.