Test cases for a payment gateway integration
Updated 2026-11-13 · 6 min read
Thirty merchant integration cases that separate authorisation, capture and refund states. Focuses on server verification, event races and recovery without duplicate fulfilment.
How to answer in an interview
Ask which provider, methods and capture policy are in scope, then identify the server evidence that makes an order paid. Cover successful payment, definitive failure and unknown outcome separately. Explain why a return URL alone cannot authorise fulfilment, and why retrying an unknown payment needs care.
Scope and test data
Assume a merchant order for ₹1,030 INR, server-side payment verification and fulfilment only after capture. Use the selected provider’s sandbox instruments and event fixtures, never real card details. Razorpay documents server-side order creation, signature verification and capture checks; its webhook guidance warns of duplicate and out-of-order deliveries. The cases are merchant integration requirements, not a promise that every provider exposes the same states or retry controls. Confirm the adapter’s state mapping before execution.
The 30 cases below are a test design, not an execution report. Replace the example rules with approved requirements before recording pass or fail. Performance budgets and supported device versions must be agreed before execution.
Creation and normal outcomes
| ID | Category | Test case | Expected result |
|---|---|---|---|
| P01 | Functional | Create a sandbox payment for the ₹1,030 order | Provider order is linked to merchant order with the exact amount and INR currency |
| P02 | Security | Modify browser amount or currency before payment creation | Server uses the stored order amount and currency or rejects the mismatch |
| P03 | Functional | Complete a sandbox payment through capture | Merchant order becomes paid with one linked captured payment |
| P04 | Functional | Receive authorisation while capture is still pending | Order is not fulfilled and payment remains awaiting capture |
| P05 | Negative | Simulate capture failure after authorisation | Order remains unfulfilled and capture recovery is visible to operations |
| P06 | Negative | Use the provider definitive-decline fixture | Attempt is marked failed with retry guidance; order is unpaid |
| P07 | Negative | Cancel the payment dialog before approving | UI returns to the order without marking it paid |
| P08 | Functional | Switch a supported payment method before approval | New method retains the same approved order amount |
Callback and event trust
| ID | Category | Test case | Expected result |
|---|---|---|---|
| P09 | Security | Forge a success callback without a valid signature | Merchant rejects confirmation and does not mark the order paid |
| P10 | Security | Submit a genuine payment identifier linked to a different order | Order binding check rejects it |
| P11 | Security | Submit a signed test event with an amount mismatch | Mismatch is recorded and fulfilment is withheld |
| P12 | Security | Submit a signed test event with a currency mismatch | Event does not pay the INR order |
| P13 | Security | Alter a webhook payload while keeping its old signature | Signature validation fails and no business state changes |
| P14 | Functional | Deliver the same valid capture event twice | One paid transition and one fulfilment action occur |
| P15 | Functional | Deliver authorisation after the capture event | Captured state does not regress to awaiting capture |
| P16 | Functional | Race callback processing against a capture webhook | Both resolve to the same payment with one fulfilment action |
| P17 | Negative | Fail event storage before acknowledging delivery | Failure remains retryable and no event is silently acknowledged as processed |
| P18 | Functional | Recover and redeliver the event after storage failure | Event is processed once and the order reaches the correct state |
Unknown outcomes and refunds
| ID | Category | Test case | Expected result |
|---|---|---|---|
| P19 | Negative | Lose the create-payment response after provider acceptance | Recovery finds the existing attempt before creating a potentially duplicate payment |
| P20 | Negative | Lose browser connectivity immediately after approval | UI reports an unresolved state until server verification resolves it |
| P21 | Functional | Deliver verified capture after the browser has closed | Order becomes paid without needing the return page |
| P22 | Negative | Time out a status lookup while payment is pending | UI does not label the transaction definitively failed or invite an unsafe blind retry |
| P23 | Functional | Retry after a confirmed failed attempt | New attempt is traceable and the failed attempt cannot fulfil the order |
| P24 | Functional | Request a full refund of a captured sandbox payment | Refund is linked to that payment and shown as pending until confirmed |
| P25 | Functional | Confirm a partial refund of ₹100 | Refunded total becomes ₹100 and remaining refundable amount is ₹930 |
| P26 | Boundary | Request another refund exceeding the remaining amount | Request is rejected without increasing the refunded total |
| P27 | Functional | Deliver the same successful refund event twice | Refunded total is updated once, not doubled |
Usability and operations
| ID | Category | Test case | Expected result |
|---|---|---|---|
| P28 | UI | Open, cancel and recover the payment dialog using keyboard and zoom | Controls remain reachable and focus returns to a meaningful merchant control |
| P29 | Performance | Deliver the agreed peak event volume including duplicates | Processing meets the agreed backlog budget without duplicate fulfilment |
| P30 | Compatibility | Complete sandbox return and recovery on supported desktop and mobile browsers | Browser differences do not alter the server-confirmed order state |
Evidence and prioritisation
Prioritise P03, P09, P14, P16 and P20. Keep merchant order ID, provider order/payment IDs, event IDs and state timestamps, with sensitive fields redacted. A common mistake is asserting only a green success message. Check fulfilment count and the durable payment record too. For a follow-up on settlements, explain that capture, customer refunds and merchant settlement need different assertions; this suite does not test bank settlement.
Downloads
Quick answers
Can a success callback prove payment?
It must be validated and bound to the server order. Apply the provider capture and verification requirements before fulfilment.
Should every timeout trigger a fresh payment?
No. A timeout may hide a completed payment. Reconcile the existing attempt before allowing a new one.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.