Everyone is using AI to generate test cases now. That's table stakes in 2025.

The more interesting question is: what kind of test cases are they generating?

There's a difference between test cases that cover the happy path and obvious negatives — and test cases that catch the failure modes that only show up when real money moves between real systems under real load.

I spent time running the same payment API spec through four tools: ChatGPT, Cursor, Claude (free tier), and Vellix. Same input. Different outputs. The differences are more revealing than you'd expect.

The Setup

I used a standard payment initiation API — the kind any fintech or D2C platform with a payment gateway integration would have. The spec covers:

• Payment initiation (UPI, card, net banking)

• Webhook handling (success, failure, pending)

• Refund initiation

• Transaction status fetch

This is a real-world API surface. Every fintech team needs tests for this. The question is what "good tests" actually looks like for a payment flow.

Tool 1: ChatGPT

What it does well:

ChatGPT is genuinely impressive for getting started fast. Give it your API spec or a plain English description of your payment flow, and it will generate structured test cases in any format you want — Gherkin, JSON, a table, a Postman collection, whatever your team uses.

It handles the obvious cases cleanly:

• ✅ Valid UPI payment initiation with correct payload

• ✅ Missing required field returns 400

• ✅ Invalid card number format

• ✅ Webhook received after successful payment

• ✅ Refund initiated for completed transaction

It's fast. It's format-flexible. It's good at turning requirements into structured documentation.

Where it falls short:

ChatGPT has no knowledge of how payment systems actually fail in production. It generates the test cases a junior QA engineer would write on day one — correct, reasonable, and insufficient.

Ask it to test your UPI payment API and it will not, on its own, generate:

• What happens when the UPI app times out after 30 seconds but the payment is still in-flight at the PSP layer

• What happens when your webhook arrives before the payment status is settled at the PG

• What happens when the same txn_id is submitted twice due to a client retry — and one goes through

• What happens when net banking returns a "pending" status that your frontend treats as a failure and the user pays again

These are not edge cases. These are common production failure modes. ChatGPT doesn't generate them because it has no domain training on payment failure patterns. It generates test cases based on the surface of your API, not based on what breaks in production.

You still need a payment expert to tell it what to test. Then it helps you write the tests faster.

Verdict: Great test documentation assistant. Not a domain expert.

Tool 2: Cursor

What it does well:

Cursor is a different beast entirely. It's an IDE, not a chat interface. Its superpower is that it understands your existing codebase — not just the spec you paste into a prompt, but your actual implementation files, your page objects, your existing test structure, your framework conventions.

For unit test generation from existing code, it's excellent. If you have a payment service class written, Cursor can generate unit tests for it that match your testing framework, follow your patterns, and cover the branches in your code.

It's also good at test maintenance — when your API changes, Cursor can help update your existing tests to match.

Where it falls short:

Cursor is code-first. It generates tests based on what's in your code, not based on what happens in production payment infrastructure.

Real payment testing isn't about testing your code in isolation. It's about testing the interactions between your code, the payment gateway, the banking network, and the settlement system — under conditions your code has never seen.

Cursor will generate a test for your initiatePayment() function. It will not generate a test for what happens when Razorpay returns HTTP 200 but the payment is still in a "created" state instead of "authorized" — a real response pattern that causes double-payment bugs.

There's also a practical issue: for payment security tests specifically, engineers who've tried Cursor for this report still preferring manual creation. The domain knowledge gap is too wide for general code assistance to bridge.

Verdict: Exceptional for unit tests from existing code. Wrong tool for payment integration testing.

Tool 3: Claude

What it does well:

Claude's reasoning capability makes it noticeably better than ChatGPT at thinking through failure scenarios when you prompt it well. If you give it context — "we're testing a Razorpay integration, here are the known PG response codes, now generate edge cases" — it reasons through the problem more thoroughly.

It's also better at questioning assumptions. Ask Claude to generate test cases for your payment flow and it will sometimes ask: "What happens if the webhook is delayed? Should I include tests for idempotency?" ChatGPT tends to just generate.

It produces clean, well-structured output and understands testing concepts at a high level.

Where it falls short:

Claude is a general-purpose reasoning model. It knows about payment systems the way a smart generalist knows about any domain — enough to have a conversation, not enough to know what actually breaks.

The quality of output is highly dependent on how much domain context you provide in the prompt. With a minimal prompt ("generate test cases for my payment API"), the output is similar to ChatGPT — competent but generic. With a very detailed prompt including PG documentation and failure mode context, it does better — but now the work is on you, not the tool.

It also has no memory of the payment failure modes that surface from real transaction data. It can reason about failure modes you describe. It cannot surface failure modes you don't know about.

Verdict: The best general-purpose reasoner of the three. Still requires you to know what to ask for.

Tool 4: Vellix

What it does differently:

Vellix is not a general-purpose AI. It's trained specifically on payment API failure patterns — built from production failure data, not from the internet.

The difference shows immediately.

Give Vellix the same payment API spec and it generates test cases that none of the other three tools produce without extensive prompting:

• Idempotency under retry: Two identical payment requests arrive with the same order_id — does your system process them once or twice?

• Webhook race condition: Webhook arrives before your database write completes — does your system handle out-of-order events?

• Partial capture: Authorization succeeds but capture fails silently — does your reconciliation system catch this or does it report the payment as complete?

• Currency precision: ₹1,00,000.00 vs ₹100000 vs ₹100000.0 — does your system handle all three correctly across all modes?

• Net banking pending loop: User completes net banking on the bank side, PG is still processing, user hits back and retries — now you have two transactions in flight for the same order

• UPI timeout with in-flight payment: The 30-second UPI app timeout expires, your frontend shows failure — but the payment completes at the PSP 45 seconds later

• Refund against pending transaction: User requests refund before payment fully settles — what does your system do?

These are failure modes that come from production. Not from reading API documentation.

Vellix also generates directly into your framework — not a template you have to adapt, but actual test code in the language and framework your team uses, ready to run.

Time to output: 60 seconds from API spec to a complete test suite across all payment scenarios.

The Real Comparison

Here's the honest summary:

What This Means Practically

If you're building payment features and you're using ChatGPT or Claude to generate your test cases, you're probably getting 60–70% coverage of the obvious scenarios. That's genuinely useful. It's faster than writing from scratch.

What you're not getting is the 30% of scenarios that cause actual production incidents.

The UPI timeout that creates a double-payment.

The webhook that arrives out of order and marks a failed payment as success.

The refund that processes against a transaction that hasn't settled.

The retry that creates duplicate orders.

These are the failure modes that don't show up in documentation. They show up in production logs, in reconciliation mismatches, in customer complaints, in chargebacks.

General-purpose AI tools generate test cases from the surface of your system. Domain-specific tools generate test cases from knowledge of how the category of system actually fails.

For most software, the difference is acceptable. For payment systems, where every failure mode has a financial consequence, the difference is the whole point.

The Bottom Line

Use ChatGPT or Claude to accelerate your documentation, structure your test plans, and generate the obvious scenarios faster.

Use Cursor to write unit tests for your payment service classes while your code is open.

Use Vellix when you need to know what actually breaks in a payment integration — before it breaks in production.

The free audit is at vellix.io/audit. Paste your API spec and see what it surfaces. You'll know within 60 seconds whether there are gaps your current test suite isn't covering.

Abhijeet Batsa is the founder of Vellix and FuturestaQ. He has 16 years of payment reliability experience at Paytm Money, Snapdeal, Paytm Insurance, and Rakuten Viki.

Software testing has more categories, subcategories, and frameworks than most engineers care to learn. This post cuts through the noise: what each type of testing actually does, when to use it, and how AI-powered test generation fits into a modern QA strategy.

The Two Fundamental Divisions

Before the subcategories, there are two axes that define all software testing:

Functional vs Non-Functional

• Functional testing: Does the software do what it is supposed to do?

• Non-functional testing: How well does it do it? (speed, reliability, security, usability)

Manual vs Automated

• Manual testing: A human executes test cases

• Automated testing: A script or tool executes test cases

• AI-powered: An AI generates or executes test cases

Almost every type of testing can be performed manually or automated. The decision of which to automate depends on repeatability, volume, and criticality.

Functional Testing Types

Unit Testing

What it is: Testing individual functions, methods, or components in isolation.

Who does it: Developers, during development.

When to use it: Every time a function is written or modified.

Tools: Jest, JUnit, pytest, NUnit.

Where Vellix fits: Vellix can generate unit test scenarios for API functions — edge cases and boundary conditions that developers typically miss.

Integration Testing

What it is: Testing how different modules or services interact with each other.

Who does it: Developers or QA engineers.

When to use it: When multiple services or components need to work together — especially when integrating with third-party APIs.

Tools: Postman, REST Assured, Karate.

The fintech angle: Integration testing is where most fintech failures originate — the interface between your system and a payment gateway, bank API, or KYC vendor. This is where the "it works in isolation, breaks in combination" problem lives.

System Testing

What it is: Testing the entire application as a single integrated system.

Who does it: QA engineers.

When to use it: Before release, after major feature additions.

Tools: Selenium, Playwright, Cypress (for UI); Postman collections (for API).

End-to-End (E2E) Testing

What it is: Testing complete user journeys from start to finish, including all system components.

Who does it: QA engineers.

When to use it: For critical user flows — checkout, onboarding, authentication, payment. Tools: Playwright, Selenium, Cypress.

The fintech angle: E2E testing in fintech must include the full transaction lifecycle — not just "did the button work" but "did the money move correctly and did both systems agree on the state."

Regression Testing

What it is: Re-running existing tests after code changes to ensure nothing previously working has broken.

Who does it: QA engineers (automated, typically).

When to use it: After every deployment or significant code change.

Why it matters: In fast-moving fintech teams, regressions in payment flows are the most common source of production incidents. Automated regression on critical flows is non-negotiable.

Smoke Testing

What it is: A quick check of the most critical functions after a new build — "does the app start, can users log in, can a basic transaction complete?"

Who does it: QA engineers or automated pipeline.

When to use it: Immediately after every deployment, before deeper testing begins.

Sanity Testing

What it is: Focused testing on specific functionality after a bug fix or minor change.

Who does it: QA engineers.

When to use it: After a targeted fix, to verify the fix works without re-running the full regression suite.

User Acceptance Testing (UAT)

What it is: Testing by end users or business stakeholders to verify the product meets business requirements.

Who does it: Business users, product managers, clients.

When to use it: Before final release, especially for client-facing features.

The misconception: UAT is not a replacement for QA. It is the final gate, not the only gate. A product that reaches UAT with critical functional defects has failed QA — not UAT.

Non-Functional Testing Types

Performance Testing

What it is: Evaluating how the system behaves under various load conditions.

Subtypes:

• Load testing: Normal expected load

• Stress testing: Beyond normal capacity, to find the breaking point

• Spike testing: Sudden large increase in load

• Soak testing: Sustained load over a long period Tools: JMeter, k6, Gatling, Locust. The fintech angle: Payment systems face predictable peak loads — salary dates, festival seasons, IPO subscription windows. Stress testing these flows before the peak is essential.

Security Testing

What it is: Identifying vulnerabilities and security weaknesses.

Subtypes: Penetration testing, vulnerability scanning, authentication testing.

Tools: OWASP ZAP, Burp Suite.

The fintech angle: In regulated fintech products, security testing is not optional. PCI-DSS compliance, RBI guidelines, and SEBI regulations all require demonstrable security testing.

Exploratory Testing

What it is: Unscripted, human-driven testing where the tester simultaneously learns the product, designs tests, and executes them.

Who does it: Experienced QA engineers.

When to use it: For new features, edge case discovery, and finding issues that scripted tests miss.

Why it matters: This is the one type of testing that AI cannot replace. Real users behave unpredictably, and an experienced tester who thinks like a malicious or confused user will find things no automated suite will.

Usability Testing

What it is: Evaluating how easy and intuitive the product is to use.

Who does it: UX researchers, QA engineers, real users.

Tools: UserTesting, Hotjar, session recordings.

Accessibility Testing

What it is: Verifying the product is usable by people with disabilities.

Standards: WCAG 2.1 compliance.

Tools: Axe, WAVE, Lighthouse.

Testing Specific to Fintech

These testing types are standard across software but become critical in financial products:

API Contract Testing

Verifying that the API response matches the documented contract — data types, field names, required fields. Critical when integrating with banking partners where an undocumented field change can break a payment flow.

Financial Correctness Testing

The most important and least common type of testing in fintech. Verifying that amounts, calculations, and financial state are correct — not just that the API returned a 200 OK. This includes settlement reconciliation, ledger balance checks, and rounding validation.

Idempotency Testing

Verifying that duplicate requests (retry after timeout) produce the same result rather than creating duplicate transactions. One of the most common sources of real-money production bugs in payment systems.

State Machine Testing

Verifying that a transaction, order, or financial object transitions through allowed states correctly and cannot reach an invalid state. A payment that transitions from "pending" to "failed" to "completed" represents a corrupt state machine.

Where AI-Powered Test Generation Fits

Traditional test generation requires a QA engineer to manually think through each scenario. This works for obvious cases but systematically misses:

• Domain-specific edge cases requiring specialized knowledge

• Combination failures (three things going wrong simultaneously)

• Scenarios that only occur at scale or under specific timing conditions

AI-powered test generation — specifically Vellix for fintech — addresses this by producing test scenarios from a domain knowledge base rather than from the tester's individual expertise.

What AI does well:

• Generating comprehensive scenario coverage from an API specification

• Producing fintech-specific failure modes (payment edge cases, financial calculation boundaries)

• Scaling test coverage without scaling headcount

What AI does not do:

• Replace exploratory testing — human creativity and malicious thinking are still essential

• Run the tests — AI generates scenarios; your existing framework executes them

• Monitor production — generation is not monitoring

The modern QA strategy uses all three:

• Manual / exploratory: Human testers for new features, UX validation, creative edge case discovery

• Automated: Scripts for regression, performance, and critical path validation

• AI-generated: Scenario expansion for domain-specific coverage, edge case discovery, test case generation at scale

Each plays a different role. None replaces the others.

A Practical Testing Pyramid for Fintech Teams

For a fintech team with limited QA resources, here is the priority order:

1. Automated smoke tests on all critical flows — runs on every deployment

2. AI-generated API tests for payment, KYC, and settlement endpoints — run on every PR

3. Manual exploratory testing of new features before release

4. Performance tests for payment flows before peak seasons

5. UAT with product team before major releases

6. Security testing on a quarterly cadence

This covers the most critical bases with the least overhead.

Abhijeet Batsa is the founder of Vellix.io and FuturestaQ. He spent 16 years building payment and investment infrastructure at Paytm Money, Snapdeal, and Rakuten Viki.

Every fintech engineering team I've worked with has a version of the same story.

A transaction fails in production. A customer complains or — worse — doesn't complain and just leaves. The team scrambles, finds the cause, ships a hotfix at 11pm, writes a postmortem, and promises to do better.

Three months later, a different bug. Same scramble. Same postmortem.

The problem is not that these teams are bad engineers. The problem is that they are optimising for the wrong thing. They are getting very good at fixing production bugs. They should be getting good at preventing them.

The Cost of Finding Bugs in Production

There is a well-established principle in software engineering called the cost of defects curve: the later in the development cycle a bug is found, the more expensive it is to fix.

A bug caught during development costs 1 unit to fix. A bug caught in QA costs 10 units. A bug caught in production costs 100 units.

In fintech, the multiplier is higher. A production bug doesn't just cost engineering time — it costs:

• Revenue: Transactions that fail silently don't generate fees, and in lending or investment products, incorrect calculations directly affect P&L.

• Trust: A user who experiences a payment failure has a 60-70% churn probability, even if the failure is resolved quickly. Trust in financial products is earned slowly and lost instantly.

• Compliance: Incorrect financial outcomes in regulated markets — incorrect KYC data, wrong settlement amounts, missed audit trails — are not just product bugs. They are regulatory incidents.

• Team velocity: Every hour spent firefighting a production incident is an hour not spent building the next feature. At a 10-person fintech startup, two production incidents a month can consume 20-30% of an engineering team's productive capacity.

Why Production Bugs Keep Happening

If teams know all of this, why do production bugs keep happening?

Three reasons.

1. Testing the happy path, not the failure path

Most test suites are written by developers who just built the feature. They test the scenario they had in mind when writing the code — the path where everything works. Edge cases, failure modes, and the scenarios that require two or three things to go wrong simultaneously are rarely covered.

In fintech, the happy path is not where the money is lost. It's in the retry logic after a timeout, the race condition when two requests arrive 50ms apart, the reconciliation gap when a payment gateway callback is delayed by four hours.

2. No domain model for failure

Writing good test cases for financial flows requires knowing how financial systems fail. This is not general software engineering knowledge — it is domain knowledge accumulated through experience.

A QA engineer who has spent three years testing ecommerce applications doesn't automatically know the specific failure modes of a UPI payment flow, an AEPS transaction, or a WealthTech portfolio rebalancing engine. That knowledge comes from exposure, and most teams don't have enough of it.

3. Time pressure collapses testing

In a startup with two-week sprints, testing is typically the last activity before release and the first one to be compressed when a sprint runs long. The result is that QA coverage is inversely correlated with development velocity — the faster you ship, the less you test. This is exactly backwards.

What "Finding Bugs First" Actually Looks Like

Preventing production bugs is not about testing more. It's about testing the right things — specifically the failure modes that cause production incidents.

Here is the framework that has worked across fintech products I have built and tested at scale:

Step 1: Map your critical flows and their failure modes

For every flow in your product that touches money or customer trust, document:

• What are the external dependencies? (payment gateways, bank APIs, KYC vendors)

• What happens if each dependency is slow, returns an unexpected response, or fails entirely?

• What happens if two operations happen simultaneously that your system assumes will be sequential?

• What happens at the boundary conditions — minimum amounts, maximum amounts, zero amounts, negative amounts?

This mapping exercise typically takes 2–4 hours per critical flow. Most teams have never done it.

Step 2: Test failure paths explicitly

Once you have the failure mode map, write test cases that deliberately trigger each failure mode. Don't just test "what happens when it works" — test "what happens when it breaks in each specific way."

For a payment API, this means test cases for:

• Timeout with retry (does the system handle idempotency correctly?)

• Partial success (payment initiated, confirmation not received)

• Delayed callback (what state is the transaction in after 30 minutes with no callback?)

• Concurrent requests (two requests for the same transaction ID within 100ms)

• Invalid amount edge cases (₹0.00, negative amount, amount exceeding configured limits)

Step 3: Automate the regression layer for these scenarios

Manual testing of failure paths is valuable but not repeatable. Once you've identified and tested the critical failure modes, automate those specific scenarios so they run on every deployment.

This is the opposite of how most teams build automation — they automate the happy path first and add edge cases later (if ever). The edge cases should be automated first because they are the ones most likely to regress.

Step 4: Monitor for financial correctness, not just uptime

Most monitoring is infrastructure monitoring — CPU usage, error rates, response times. These metrics tell you when your system is down or slow.

They don't tell you when your system is producing incorrect financial outcomes while appearing healthy. A payment gateway that processes transactions but silently miscalculates settlement amounts will show green on every standard monitoring dashboard.

Financial correctness monitoring means comparing what your system recorded against what it should have recorded: initiated amount vs settled amount, order state vs payment state, ledger balance vs actual movement. These checks should run continuously, not just in testing.

The Shift in Mindset

Preventing production bugs requires a shift from reactive to proactive quality engineering.

Reactive: We test what we built, ship it, and fix what breaks.

Proactive: We map how it can fail, test those failures first, and monitor for them continuously.

The reactive approach produces postmortems. The proactive approach produces reliability.

In a fintech product, reliability is not a technical metric. It is the reason customers stay, the reason enterprise clients sign contracts, and the reason investors have confidence in your infrastructure.

Where AI-Powered Test Generation Fits In

The largest barrier to proactive quality engineering is the domain knowledge required to map failure modes. Not every QA team has engineers who know the specific ways UPI transactions fail, or how stablecoin reserve mechanics break under stress, or where KYC onboarding flows drop users silently.

This is the problem Vellix was built to solve. By providing AI-generated test scenarios trained on domain-specific failure patterns across fintech systems, Vellix gives teams access to the failure mode knowledge that previously required years of production experience to accumulate.

It doesn't replace the QA engineer. It gives the QA engineer the map.

Try it at app.vellix.io.

Abhijeet Batsa is the founder of Vellix.io and FuturestaQ. He spent 16 years building software products, payment, transactional flows and investment infrastructure at Paytm Money, Snapdeal, and Rakuten Viki.

There's a difference between a fraud detection system and fraud-resilient product logic.

A fraud detection system watches live transactions and flags suspicious patterns. You probably have one, or you use your payment processor's.

Fraud-resilient product logic means your API endpoints, state machines, and business rules are built in a way that doesn't create exploitable gaps — even before a transaction reaches the fraud detection layer.

Most fintech test suites test the former (does fraud detection fire?) and not the latter (are there flows in our product that bypass or exploit our own logic?). The result: fraud vectors that are invisible to detection systems because they don't look like fraud from the outside — they look like legitimate transactions that happen to exploit a product logic gap.

This is the class of vulnerability that Vellix's Fintech Fraud Scan checks for. Here are 23 of the most common vectors we find in real payment and WealthTech codebases.

Section A: Payment Flow Fraud Vectors (9 vectors)

1. Retry Loop Exploitation

What it is: A user initiates a payment, receives an error (network timeout, processing failure), and retries. If your idempotency implementation is incomplete, the retry can process as a new transaction while the original is still in Processing state — resulting in a duplicate charge that looks like two separate legitimate payments.

What to test: Multiple concurrent requests with identical parameters. Requests with the same idempotency key submitted within the deduplication window. Out-of-order webhook delivery after retry.

Why it matters: Legitimate users experiencing network issues will retry. If your retry handling has gaps, this becomes exploitable — intentionally or not.

2. Race Condition in Wallet/Balance Deduction

What it is: A user initiates two transactions simultaneously from the same wallet or account. Both pass the balance check before either deduction is processed. Both succeed. The user has effectively paid with the same balance twice.

What to test: Concurrent transaction initiation for the same user/account. Verify that the balance check and deduction are atomic — or that the second concurrent transaction fails with the correct error after the first deduction.

Why it matters: Not always malicious — happens legitimately with slow network conditions. But it's exploitable once users learn about the gap.

3. Negative Amount Submission

What it is: Submitting a negative transaction amount to trigger a credit rather than a debit. Most payment APIs reject this at input validation, but edge cases exist — especially in refund APIs, partial settlement APIs, and split payment flows where the sign of amounts is computed rather than directly inputted.

What to test: Negative values, zero values, and values that compute to negative through fee subtraction or split calculation. Test at every layer that accepts or computes amounts.

4. Amount Manipulation via Fee Exemption Abuse

What it is: Fee exemption conditions (promotional, tiered, first-transaction) have boundary conditions. If the fee calculation queries the exemption table after the transaction amount is set but before final processing, a race condition can allow a transaction to be processed at a fee tier it shouldn't qualify for.

What to test: Transactions submitted at exact tier boundaries with simultaneous exemption queries. Transaction amount modifications after fee calculation but before settlement.

5. Partial Refund Overflow

What it is: Successive partial refunds that cumulatively exceed the original transaction amount. If the refund system checks each refund against the original amount independently rather than tracking cumulative refunds, this is exploitable.

What to test: Submit 5 partial refunds of 25% each against a single original transaction. Verify that the total refunded amount is capped at 100% of the original.

6. Split Payment Manipulation

What it is: In split payment systems (card + wallet, card + loyalty points), the amounts from each payment source must sum to the transaction total. If they don't, the difference goes somewhere — sometimes into a float that can be exploited.

What to test: Split payments where source amounts sum to less than the transaction total. Split payments where source amounts sum to more. Concurrent modification of split amounts after initiation.

7. Chargeback Abuse via Timing

What it is: A user initiates a refund through your platform while simultaneously initiating a chargeback through their card issuer. If your system processes both, the user receives double the original transaction amount.

What to test: Simultaneous refund API call and chargeback webhook delivery for the same transaction. Verify that your system handles the double-credit scenario correctly — that the refund is reversed when the chargeback is confirmed, or vice versa.

8. Expired Session Token Replay

What it is: A payment session token captured during a legitimate transaction is replayed after its nominal expiry. If token validation uses server time but the token expiry check has a grace period or timezone inconsistency, the window can be extended.

What to test: Session token replay at T+expiry, T+expiry+1s, T+expiry+grace_period, T+expiry+grace_period+1s. Verify that tokens are definitively invalid after the grace period regardless of server time zone.

9. Webhook Endpoint Spoofing

What it is: If your webhook endpoint doesn't validate the source of incoming webhooks (via signature verification), an attacker can send fake settlement webhooks that trigger your system to mark transactions as settled before they actually are.

What to test: Webhooks with invalid signatures, missing signatures, signatures generated with incorrect keys. Webhooks claiming settlement for transaction IDs that don't exist. Webhooks in unexpected sequence order.

Section B: WealthTech and Investment Platform Fraud Vectors (7 vectors)

10. Risk Profile Manipulation via Re-KYC

What it is: A user with a high-risk profile (restricted investments, lower limits) fails a re-KYC attempt and re-submits. If the re-submission flow resets the risk profile to a default "moderate" before the re-evaluation completes, there's a window where the user has more permissions than their assessed profile allows.

What to test: Re-KYC submission timing — what is the risk profile at T+0 after submission, T+submission processing time, T+approval? Verify no expansion of permissions during the re-evaluation window.

11. Portfolio Calculation Race Condition

What it is: In real-time portfolio valuation, a user initiates a transaction based on a displayed portfolio value. Between the display and the transaction processing, the value changes. If the transaction is processed against the displayed (stale) value rather than the current value, the settlement amount is incorrect.

What to test: Transaction initiation after an artificial delay (simulate network latency) against a volatile asset. Verify that the settlement uses the price at transaction processing time, not at display time.

12. AML Threshold Calculation Gaps

What it is: AML reporting thresholds often apply to cumulative transaction amounts within a period. If the threshold calculation doesn't correctly aggregate across transaction types (purchases, redemptions, SIP instalments) or across accounts linked to the same user, the threshold can be approached without triggering the required reporting.

What to test: A series of transactions that approach the reporting threshold across different transaction types. A transaction that would push a user over the threshold if all transaction types are counted. Verify that the threshold calculation is comprehensive.

13. SIP/Recurring Payment Exploits

What it is: Systematic Investment Plans and recurring payments have specific rules: minimum amount, maximum frequency, mandate limits. If the mandate amount is validated at setup but not at each execution (e.g., post-split, post-fee calculation), individual executions can exceed the mandate limit.

What to test: SIP execution amounts including fees vs. mandate amount. Split SIP scenarios where individual instalments are below the mandate limit but accumulate beyond it within the validation period.

14. Redemption Before Settlement

What it is: A user purchases a mutual fund unit. Before the purchase settles (T+1 or T+2), they initiate a redemption. Depending on your state machine implementation, the redemption might be processed against units that don't yet exist in a settled state.

What to test: Redemption initiated within the T+0 to T+settlement window. Verify that the system correctly blocks, queues, or errors on redemptions against unsettled positions.

15. Tax Calculation at LTCG/STCG Boundary

What it is: Long-term vs short-term capital gains tax applies based on holding period. A transaction that occurs at exactly the holding period boundary (1 year for equity in India) can be misclassified as STCG when it should be LTCG (or vice versa), resulting in incorrect tax calculation.

What to test: Redemption transactions at exactly 365 days, 364 days, and 366 days from purchase date. Verify correct LTCG/STCG classification and tax calculation for each.

16. Nominee Account Routing

What it is: In estate or nomination scenarios, payment routing to nominee accounts has specific rules. If the nomination validation is incomplete — particularly for accounts where nomination was set up before a product update — payments can be routed to incorrect destinations.

What to test: Nomination scenario edge cases: nominee set before product update, incomplete nomination record, simultaneous nomination update and transaction processing.

Section C: API-Level Structural Vectors (7 vectors)

17. Parameter Pollution

What it is: Submitting duplicate parameters in a single API request — particularly in query strings or form data. If your parser takes the first occurrence and your validation takes the last (or vice versa), a gap exists where the validated value differs from the processed value.

What to test: API requests with duplicate parameter keys carrying different values. Verify that the parameter your business logic processes is the same parameter your validation checked.

18. Type Coercion Exploits

What it is: Sending a string where an integer is expected, a float where an integer is expected, or a boolean where a string is expected. Depending on your language and framework, type coercion can produce unexpected comparison outcomes (e.g., "0" == false in PHP-style loose comparison).

What to test: All API parameters with their wrong type. Amounts as strings, strings as integers, null where a value is required. Verify that type validation is strict and that coercion doesn't produce exploitable comparison results.

19. Pagination Boundary Exploitation

What it is: In APIs that return paginated transaction lists, the boundary between pages can be inconsistent if a new transaction is added between page 1 and page 2 requests. This is exploitable if the total count or aggregate value is computed from paginated responses rather than from a consistent snapshot.

What to test: Paginated list requests with concurrent transaction insertion between page requests. Verify that aggregates computed from paginated responses are consistent with direct aggregation.

20. JWT/Token Scope Boundary

What it is: A user authenticated for Account A uses their token to access endpoints that should be scoped to their account but has a parameter that accepts Account B's identifier. If the scope check validates the token but not the resource ownership, cross-account access is possible.

What to test: Authenticated requests where the token belongs to User A but the resource ID in the request belongs to User B. Verify that authorisation checks resource ownership, not just authentication.

21. Timestamp Manipulation

What it is: APIs that accept client-supplied timestamps for transaction dating can be exploited if the server doesn't validate that the timestamp is within an acceptable window of the current time. This is particularly relevant for backdating transactions for tax purposes or exploiting time-bound promotions.

What to test: API requests with timestamps in the past (1 hour, 24 hours, 1 week, 1 year). Timestamps in the future. Timestamps at promotion or period boundaries. Verify that server-side timestamp validation rejects out-of-window values.

22. Batch Request Atomicity

What it is: APIs that accept batch requests (process multiple transactions in one call) may not implement atomicity correctly. If 5 of 10 transactions in a batch succeed before one fails, does the system roll back the successful 5? Or are they committed while the remaining 5 are failed?

What to test: Batch requests where one element is intentionally invalid. Verify the atomicity contract — either all succeed, or all fail. Verify the error response correctly identifies which element failed.

23. Error Response Information Leakage

What it is: Error responses that include internal state information — account balance in an insufficient funds error, user details in an authentication failure, internal transaction IDs in a processing error — give an attacker information they can use to map your system.

What to test: Deliberate error-triggering requests (wrong credentials, invalid amounts, non-existent IDs). Verify that error responses contain only the information a legitimate user needs to correct their request — not internal system state.

How to Prioritise These 23 Vectors

Not all 23 require immediate attention. Prioritise by:

1. Transaction volume on the affected flow: A race condition in a flow that handles 10,000 transactions/day is more urgent than one in a flow that handles 10/day.

2. Financial exposure per incident: Partial refund overflow on a ₹10,000 average transaction is higher priority than parameter pollution on an informational endpoint.

3. Exploitability: Some of these require sophisticated timing or tooling. Others (negative amounts, parameter pollution) require nothing more than a modified API request.

4. Current coverage: Run your existing test suite against this list. The vectors you have zero tests for are your priority list.

Running a Fraud Vector Scan

If you want to check your current coverage against these vectors systematically, Vellix's Fintech Fraud Scan validates your API test coverage against the full vector set — including these 23 and the additional vectors we've identified from real fintech codebases.

Free tier at vellix.io includes a Fraud Scan credit. No card required.

Abhijeet Batsa is the founder of Vellix.io — AI test generation and fraud scan for fintech teams — and FuturestaQ, a fintech reliability consulting firm. 16 years at Paytm Money ($4B AUM), Snapdeal, Rakuten Viki Singapore. vellix.io | futurestaq.com

A payments platform I worked with had 99.9% uptime for eight consecutive months. Their SLA was met. Their monitoring dashboards were green. Their P0 incident count was zero.

In month nine, they discovered that 7.1% of their transactions had been producing incorrect outcomes for eleven weeks.

Not system failures. The infrastructure was running fine. Payments were processing and completing. But 7 in every 100 transactions had product logic errors: wrong fee tiers applied, incorrect state transitions recorded, settlement amounts that didn't match initiated amounts by small but real margins.

The system was up. The product was wrong.

This distinction — between a system being available and a system being correct — is what financial correctness monitoring addresses. And it's a gap that standard reliability engineering completely misses.

What Uptime Monitoring Measures (and What It Doesn't)

Traditional reliability monitoring — whether you call it SRE, observability, or just DevOps monitoring — focuses on a specific set of signals:

• Availability: Is the system responding to requests?

• Latency: How fast is it responding?

• Error rate: What percentage of requests are returning errors?

• Throughput: How many requests is it handling?

These are the "four golden signals" of SRE, and they are genuinely important for operational reliability. But they answer the question "is the system up?" They don't answer "is the system right?"

A payment that processes at the wrong fee tier doesn't produce an error. It produces a 200 OK. Latency is normal. Throughput is normal. All four golden signals are green.

The product is wrong. Your monitoring doesn't see it.

The Financial Correctness Gap

Financial products have a property that most software doesn't: their correctness is measurable in money. A wrong outcome isn't just a degraded user experience — it's a specific rupee amount that went somewhere it shouldn't have, or didn't go somewhere it should have.

This creates a class of bugs unique to fintech:

Silent incorrect outcomes: The transaction completes. The user receives a confirmation. But the underlying amounts, fees, or routing are wrong. Nobody knows until a user complains, a reconciliation report flags it, or an audit finds it.

Accumulating small errors: A rounding error of ₹0.01 per transaction sounds trivial. At 100,000 transactions per day, it's ₹1,000 per day, ₹30,000 per month, ₹3.6L per year — and it's showing up somewhere in your books as an unreconciled difference.

Compliance-relevant logic failures: A KYC edge case that assigns the wrong risk profile. An AML threshold that triggers (or doesn't trigger) based on a miscalculated running total. A regulatory reporting flag that fires on incorrect criteria. These aren't just product bugs — they're regulatory exposure.

Cascading state errors: A transaction that gets recorded in the wrong state creates downstream consequences. Settlement fails. Reconciliation mismatches. Customer service escalations. The original 200 OK was the start of a problem that took three teams two days to unwind.

What Financial Correctness Monitoring Actually Is

Financial correctness monitoring is the practice of continuously validating that the outcomes your financial system produces match the outcomes it was designed to produce.

In practice, it has three layers:

Layer 1: Transaction Outcome Validation

At the transaction level: does the settled amount match the initiated amount (after applying the correct fees, exchange rates, and rules)?

This isn't the same as a settlement report. A settlement report tells you what happened. Transaction outcome validation tells you whether what happened was correct.

Implementation: for every completed transaction, automated logic checks that:

• Fee applied = fee rule for this transaction type and amount tier

• Settlement currency and amount = expected amount after conversion at the recorded rate

• State machine final state = expected state given the transaction path taken

• Idempotency key was honoured (no duplicate processing)

Layer 2: Product Logic Regression Monitoring

At the product rule level: as your codebase changes, are your business rules still being applied correctly?

Every code deployment is a potential introduction of product logic regression. A fee calculation function refactored for performance might produce different results at edge amounts. A KYC flow updated for a new compliance requirement might break the re-attempt path. A payment routing rule change might affect transactions that weren't in the intended scope.

Product logic regression monitoring runs your core business rule assertions against production data after each deployment. Not synthetic tests — real transaction data. It surfaces when a deployment caused a product logic change that wasn't intended.

Layer 3: Reconciliation-Layer Monitoring

At the financial record level: do your internal records match the payment processor records, bank records, and ledger?

Reconciliation at most fintech companies is a manual, periodic process — often done by a finance team member running a report once per day or once per week. By the time a discrepancy is found, it's been compounding for 24–168 hours.

Automated reconciliation-layer monitoring closes this window. It runs the reconciliation check continuously — or at minimum, after every batch of settlements — and alerts immediately when internal records diverge from external records.

Why This Is a Product Engineering Problem, Not a Finance Problem

The instinct is to assign financial correctness to the finance team. They do reconciliation. They check the numbers. They file the reports.

The problem: by the time finance finds a discrepancy, the product has already caused it. The engineering decisions that produced the incorrect outcome — the fee calculation logic, the state machine implementation, the refund routing rules — were made months ago. The finance team is discovering symptoms; the cause is in the code.

Financial correctness monitoring belongs in the engineering layer because that's where the outcomes are produced. Finance reconciliation is a lagging indicator. Product logic monitoring is a leading one.

In practice, this means:

• Engineering owns the automated transaction outcome validation

• QA engineers include financial correctness assertions in their test suites (not just functional correctness)

• Deployments are gated on product logic regression checks, not just unit test pass rates

• Monitoring dashboards show financial correctness metrics alongside uptime metrics

The Metrics That Actually Matter for Financial Products

If you're measuring the right things, your monitoring dashboard for a fintech product should include:

Standard reliability metrics (already exist):

• Uptime / availability

• API latency (p50, p95, p99)

• Error rate by endpoint

Financial correctness metrics (usually missing):

• Incorrect outcome rate: % of completed transactions where the outcome differed from the expected outcome based on business rules

• Reconciliation mismatch rate: % of transactions where internal records don't match processor records within the settlement window

• Rule regression count: number of business rule assertions that failed after the last deployment

• Mean time to detection (MTTD) for product logic errors: how long between a logic error being introduced and being detected

The 7.1% incorrect outcome rate from the example above? It was invisible on their uptime dashboard. It would have been the headline metric on a financial correctness dashboard.

How to Start: A Practical 3-Step Implementation

You don't need to build a full financial correctness monitoring system overnight. Three steps, in order:

Step 1: Instrument your reconciliation layer. Before anything else, add automated settlement reconciliation that runs daily. Compare your internal transaction records against your payment processor settlement files. Log every discrepancy. Alert if the discrepancy rate exceeds a threshold. This alone will surface most production financial errors within 24 hours instead of weeks.

Step 2: Add business rule assertions to your test suite. For your top three revenue-critical flows, write explicit test assertions for the financial outcomes — not just the API responses. "Fee applied to a ₹500 transaction should be ₹12.50, not ₹12.49 or ₹12.51." These assertions catch logic regressions during development, before they reach production.

Step 3: Add post-deployment validation. After each production deployment, run a automated check that replays recent real transactions against the expected business rules. If the rule application changes after a deployment, surface it immediately.

The Question That Drives This

The right question for a fintech engineering team isn't "is the system up?"

It's "is the system right?"

A system that's up but wrong is worse than a system that's down. Downtime is visible. Incorrect outcomes are silent. Downtime is measured in minutes. Incorrect outcomes accumulate in rupees.

Financial correctness monitoring is the discipline of measuring the right question.

Vellix provides financial correctness monitoring as part of its AI reliability platform for fintech — including automated reconciliation-layer validation, product logic regression monitoring, and RCA report generation. vellix.io | support@vellix.io

Abhijeet Batsa is the founder of Vellix.io and FuturestaQ. 16 years at Paytm Money ($4B AUM), Snapdeal, Rakuten Viki Singapore.

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