Most fintech teams have good test coverage on their happy path. The payment initiates, processes, and settles. Tests pass. CI is green. Deployment proceeds.
The problem is what happens in the other 40%.
Payment APIs are state machines. A transaction doesn't just succeed or fail — it moves through states: Initiated, Processing, Pending, Settlement Queued, Settled, Failed, Reversed, Disputed, Refunded, Partially Refunded, Expired. Each state transition has conditions. Each condition has edge cases. And most fintech test suites cover three or four states and call it done.
This guide covers the payment edge cases that consistently go untested — and how to build coverage for each.
Why Payment Edge Cases Are Different From Standard API Edge Cases
In a standard web API, an edge case might be: null input, oversized payload, malformed JSON, concurrent requests. The failure mode is usually a 4xx or 5xx error — loud, obvious, logged.
In a payment API, the failure modes are quieter:
A transaction that returns a 200 OK but processes at the wrong fee tier
A refund that initiates to the correct account but settles to a secondary account due to a routing rule edge case
A payment that transitions to "Settled" in your system but "Pending" at the payment processor — and reconciliation doesn't catch the mismatch for 48 hours
A retry logic edge case where a failed transaction gets retried three times, each retry succeeds at the processor level, and the user gets charged three times
None of these produce 5xx errors. All of them produce incorrect financial outcomes. That's what makes payment edge case testing fundamentally different: the failure is in the business logic, not the system behaviour.
The 8 Payment Edge Case Categories Every Fintech Team Must Cover
1. State Transition Edge Cases
The full payment state machine is larger than most teams model. Beyond the obvious Initiated → Settled and Initiated → Failed paths:
Partial settlement: Payment partially settles due to insufficient merchant balance or split payment logic. What happens to the unsettled portion? Is it queued, returned, or silently abandoned?
Settlement reversal after success: A transaction shows as Settled in your system, then gets reversed by the payment network 24–72 hours later. Does your system handle this state correctly?
Timeout during processing: What happens when a transaction times out while in Processing state? Is it marked Failed? Is it left in a zombie Processing state? Can it be re-initiated?
Duplicate detection window: If a user submits the same payment twice within your duplicate detection window, what exactly happens? Does the second attempt get rejected with the right error code? Does it get silently deduplicated?
Coverage test to write: For each state in your payment state machine, write a test that forces an entry into that state and verifies the correct next-state transition for every possible trigger.
2. Concurrency and Race Condition Cases
Payment systems operate under concurrency. Two events happening simultaneously produce edge cases that sequential testing never surfaces:
Refund initiated at the same moment the original transaction is settling
Two simultaneous payment attempts for the same user account — do both succeed? Does one fail? Does the idempotency key handle this correctly?
Webhook delivery and API response arriving out of order — your system receives the settlement webhook before it receives the API response to the initiation call
Balance deduction and payment processing running concurrently — the balance check passes, then a concurrent transaction reduces the balance below the required amount before the payment processes
Coverage test to write: Simulate concurrent requests against the same transaction ID or user ID. Verify that idempotency keys work correctly. Verify that webhook out-of-order delivery produces the correct final state.
3. Retry and Idempotency Cases
Retry logic is one of the most common sources of duplicate charges in fintech systems:
Client retries a payment request after a network timeout — does your server correctly identify and deduplicate the retry?
Idempotency key collision — two different transactions submitted with the same idempotency key (due to a client-side bug). Which one wins? Is the error surfaced correctly?
Webhook retry after your endpoint returns 5xx — does processing the same webhook twice produce duplicate state updates?
Payment processor retry (not client retry) — the processor retries a failed submission that was actually received and processed. Does your system handle this as a duplicate?
Coverage test to write: Replay the same API call with identical parameters multiple times. Verify idempotency. Verify that the final state is correct regardless of how many times the request was processed.
4. Refund and Reversal Cases
Refunds have more edge cases than initial payments because they operate against existing transaction state:
Partial refund on a partially settled transaction
Refund initiated after the merchant has initiated their own reversal — two refund mechanisms in flight simultaneously
Refund to an expired card — where does the money go? Is the user notified correctly?
Refund on a transaction that was funded by a split payment method (card + wallet) — is the refund split proportionally? Does it go entirely to one method?
Refund after a chargeback is already in progress — are both the chargeback and refund processed? Is the user refunded twice?
Coverage test to write: For each refund scenario, verify the correct amount, destination, and final state for both the original transaction and the refund.
5. Fee Calculation Edge Cases
Fee calculation bugs are particularly damaging because they produce incorrect financial outcomes that are hard to detect without reconciliation:
Tiered fee structures where a transaction amount sits exactly on a tier boundary
Fee calculations involving currency conversion with mid-calculation rounding
GST/tax application edge cases — should the fee be taxed? Is the tax calculation correct for the specific transaction type?
Promotional fee waiver conditions — fee is waived for the first N transactions, or for transactions above a threshold. What happens at exactly N transactions or exactly the threshold amount?
Fee on refund — does your system correctly handle whether the original processing fee is refunded? Is the refund fee applied?
Coverage test to write: For every fee calculation rule in your system, test the exact boundary conditions — amounts at, above, and below each tier, threshold, or waiver condition.
6. KYC and Compliance Path Cases
KYC failures compound: a user who fails KYC and re-attempts may be in a different compliance state than a first-time applicant, and your test suite often doesn't model this:
Re-submission after document rejection — is the user assigned the correct risk profile? Is the previous submission's data overwritten, appended, or preserved?
Partial verification state — user completed step 1 of a 3-step KYC but abandoned step 2. What transaction limits apply? What happens when they return to complete step 2?
KYC expiry — user was verified 18 months ago and their KYC has expired. Are they blocked from transactions? Notified? Partially restricted?
AML threshold triggering — a series of transactions brings a user to the AML reporting threshold. Is the threshold correctly calculated across transaction types? Is the reporting triggered correctly?
Coverage test to write: Model every KYC state a user can be in. For each state, test what transactions are permitted, what limits apply, and what happens when limits are exceeded.
7. Webhook and Async Delivery Cases
Payment APIs are event-driven. Webhooks carry critical state updates. Webhook reliability edge cases are consistently undertested:
Webhook delivery failure — your endpoint is down. How many retries? At what intervals? What happens to the transaction state if all retries fail?
Webhook received out of sequence — settlement webhook arrives before the payment confirmation webhook
Duplicate webhook delivery — the same event is delivered twice (common with most payment processors). Is the second delivery idempotent?
Webhook signature validation failure — what happens when a webhook with an invalid signature arrives? Is it rejected silently? Logged? Alerted?
Coverage test to write: Build a test harness that delivers webhooks out of order, delays delivery, sends duplicates, and sends invalid signatures. Verify correct system state after each scenario.
8. Currency and Localisation Cases
For cross-border payments or multi-currency platforms:
Exchange rate applied at transaction creation vs settlement — what happens when the rate moves significantly between the two?
Rounding in currency conversion — do fractional cents/paise accumulate correctly across multiple transactions?
Currency mismatch between payment initiation and settlement currency
INR-specific: amounts involving paise, UPI round-trip edge cases, IMPS vs NEFT vs RTGS routing for the same transaction type
Coverage test to write: Test the same transaction amount at multiple exchange rates. Verify that the settled amount matches the agreed amount within acceptable tolerance.
How to Build This Coverage Without Tripling Your Sprint Time
The honest problem with the above list: writing all of these tests manually for a complex payment API is a 3–4 sprint project. Most fintech teams don't have that runway.
Two practical approaches:
Approach 1: Risk-ranked coverage sprints. Prioritise by financial impact. The edge cases most likely to produce incorrect money movement (concurrency, fee calculation, refund logic) get covered first. State transition edge cases and webhook reliability come second. KYC compliance paths third. This gets you from 40% to 75% coverage in one sprint instead of trying to get to 100%.
Approach 2: AI-assisted test generation. Tools like Vellix generate fintech-specific edge case tests from your API specification or code. The key word is fintech-specific — a generic AI test tool will generate syntactically valid tests that miss payment state machine logic entirely. The right tool knows what a partial refund on a split-payment transaction looks like and generates the appropriate test cases.
Either approach beats the status quo of shipping with known coverage gaps and discovering edge cases in production.
The Reconciliation Check: Your Last Line of Defence
Even with strong edge case coverage, reconciliation is the safety net that catches what tests miss. A daily automated check that settled amounts match initiated amounts — across transaction type, fee structure, and currency — will surface the silent incorrect-outcome bugs that no test suite catches 100% of the time.
This isn't a replacement for test coverage. It's the layer below it. Build both.
Summary: The Payment Edge Case Coverage Checklist
For each of your core payment flows, verify coverage for:
[ ] All state transitions, including timeout and zombie states
[ ] Concurrent initiation, refund, and webhook scenarios
[ ] Idempotency and retry logic — including processor-side retries
[ ] Partial and full refunds across all payment methods
[ ] Fee calculation at every boundary condition
[ ] KYC states: partial, re-attempt, expired, AML threshold
[ ] Webhook out-of-order, duplicate, and signature-invalid scenarios
[ ] Currency conversion rounding and exchange rate edge cases
If you can answer "yes, we have a test for that" to each row above — your payment API coverage is better than 90% of fintech teams in production today.
Abhijeet Batsa is the founder of Vellix.io — AI test generation for Fintech & Software teams — and FuturestaQ, a fintech reliability consulting firm. He spent 16 years building and stabilising payment and investment products at Paytm Money, Snapdeal, and Rakuten Viki Singapore. vellix.io | futurestaq.com
