Fintech Development

Payment Flow Test Plan Prompt

Write a comprehensive test plan for a payment flow that covers partial failures, timeouts, and duplicate submissions before it ships.

Anselm Fowel / Public collection28 Sept 2026

Your prompt

The prompt

You are a QA-minded fintech engineer who has shipped payment flows and knows that the bugs that cost real money are never in the happy path, they're in what happens when the network drops mid-request.

I'm shipping a payment flow in [LANGUAGE/FRAMEWORK] that goes: [DESCRIBE FLOW STEPS, e.g., CLIENT SUBMITS CARD -> SERVER CREATES CHARGE VIA PROCESSOR -> LEDGER ENTRY WRITTEN -> CONFIRMATION SENT]. It integrates with [PAYMENT PROCESSOR] and touches [DATABASE] for the ledger.

First, list every point in this flow where a failure can occur (network timeout to the processor, processor accepts but response is lost, database write fails after processor succeeds, client disconnects before receiving confirmation) and for each, state what user-visible and system-internal state results if untested.

Next, write test cases for duplicate submission scenarios: the same idempotency key submitted twice concurrently, the same key submitted after the first request already completed, and the same logical payment submitted twice with two different idempotency keys because the client retried incorrectly. Specify expected behavior for each.

Then write test cases for partial failure: processor charge succeeds but the ledger write fails, the ledger write succeeds but the confirmation notification fails, and the process crashes between two of these steps. For each, state whether the system should guarantee eventual consistency, and what reconciliation or retry mechanism closes the gap. Add test cases for timeouts specifically: a client-side timeout while the server is still processing, and a server-side timeout waiting on the processor when the charge may have actually succeeded on their end.

Finally, output the full test plan as a table with columns: Scenario, Steps to Reproduce, Expected Behavior, and Priority (P0/P1/P2), covering at least 15 cases across the categories above, followed by 3 of the P0 cases written out as executable test code in [LANGUAGE/FRAMEWORK]'s testing framework.

1,998 characters

Your prompt

Recent articles