Fintech QA
High-stakes testing for payments, reconciliation, compliance, and financial data accuracy.
// OVERVIEW
In fintech, money must be exactly correct — not approximately correct, not eventually correct. Every state change is immutable and auditable. Provider confirmation lag creates premature-success bugs, rounding errors compound at scale across millions of transactions, and reconciliation against external provider statements is a daily correctness gate, not an optional report.
// What makes Fintech QA different
- Every transaction must be logged whether it succeeds or fails — partial writes and silent failures create reconciliation drift that compounds daily
- Provider confirmation lag: a payment can be marked 'success' internally before the external provider confirms, creating a window where the internal state is wrong
- Rounding errors compound: fee percentages applied to fractional currency amounts, combined with FX conversion and tax, accumulate across millions of transactions
- KYC/AML compliance creates hard-fail conditions that are legally mandated — bypassing them, even in test data, is a compliance risk
- Daily reconciliation against provider statements is a first-class test, not optional reporting: discrepancies are bugs
// Core user journeys
| Journey | What to cover |
|---|---|
| Payment initiation to ledger update | Payment submitted → provider authorisation → webhook confirmation → ledger entry written → balance updated |
| KYC / identity verification | Document submission, KYC provider response handling, hard-fail on unverified status |
| Refund / reversal | Refund initiated → provider processes → webhook received → ledger debited → balance updated → customer notified |
| Transaction limit enforcement | Transfer attempted above single-transaction limit, daily limit, and cumulative limit — assert each returns the correct error at the API layer |
| Reconciliation report generation | End-of-day reconciliation: internal ledger compared against provider statement, discrepancies flagged |
// RISKS & TEST AREAS
// Main risk areas
| Risk | Why it matters |
|---|---|
| Reconciliation drift | Internal ledger balance diverges from provider statement; can compound silently for days before detection |
| Duplicate transaction on retry | Client retries a timed-out payment request without an idempotency key; server creates two charge records |
| Premature success status | Payment status set to 'success' before provider webhook arrives; provider later declines, leaving the customer with access to funds that were never confirmed |
| Currency rounding error | 2.9% fee on a $0.01 transaction rounds to $0.00 instead of the minimum-fee floor; error accumulates across millions of transactions |
| Transaction limit not enforced at API | Limit is enforced in the UI but not at the API layer; a direct API call bypasses the check and submits an over-limit transaction |
| Interest accrual error | Wrong day-count convention (ACT/360 vs 30/360), a missed leap-year day, or compounding applied to the wrong base produces a balance that drifts a little every day and grows over the term — distinct from fee rounding, which is a separate per-transaction risk above |
| Posting to a closed or dormant account | A credit or debit lands on an account that should be closed or dormant and is applied instead of being rejected or routed to a suspense account, leaving funds stranded or a closed account silently reactivated |
// Functional areas to test
- Payment initiation and status: submit, confirm, fail, cancel, pending states
- Ledger and balance display: balance accuracy, transaction history, ordering
- Refund and reversal: full, partial, provider-initiated chargeback
- KYC flow: document upload, status polling, hard-fail on unverified
- Transaction limits: per-transaction, daily, cumulative — enforced at API layer
- Reconciliation and statement generation: end-of-day, multi-day, discrepancy flagging
- Account lifecycle: open → active → dormant → frozen → closed, with reactivation and residual-balance handling
- Loan servicing: amortisation schedule generation, repayment allocation (principal vs interest), and early-settlement recalculation
- Recurring mandates: direct debits and standing orders — schedule, retry on failure, mandate cancellation, and insufficient-funds handling
// API & integration areas
- Payment provider webhook idempotency: assert a replayed webhook with the same event ID does not create a duplicate transaction
- Provider status polling vs push: assert the system correctly handles both polling fallback and push webhook delivery
- FX rate API: assert the rate used at transfer time is locked and not silently re-fetched at settlement time
- KYC provider response mapping: assert all status codes (approved, pending, rejected, expired) map to the correct internal state
- Reconciliation file ingestion: assert the parser handles malformed lines, missing fields, and currency-code mismatches without silent data loss
// Data testing
- Never use real financial data or real payment credentials in test environments — use provider sandbox accounts with test card numbers only
- Seed ledger with known starting balances to make reconciliation assertions deterministic
- Test borderline currency amounts: $0.01, $0.001, amounts just above and just below transaction limits
- Seed failed transactions to verify partial-debit edge case: assert a failed transaction does not decrement the balance but does write an audit log entry
// CROSS-CUTTING CONCERNS
// Security & privacy
- PCI-DSS scope: card numbers, CVVs, and full PANs must never appear in application logs, error messages, or analytics payloads
- Financial data encrypted at rest and in transit — assert data is not readable in plaintext at the database or in transit captures
- KYC document access audited: assert every read of a user's identity document creates an audit log entry with actor and timestamp
- AML flag not bypassable via API: assert a flagged account cannot initiate a transfer even via a direct API call with a valid auth token
// Accessibility
- Screen reader on currency-formatted amounts: assert dynamic balance updates are announced, not silently replaced in the DOM
- Focus management on 2FA/OTP challenge dialogs: assert focus moves to the OTP input when the dialog opens
- Keyboard navigation on transaction history tables: sortable columns and row actions must be reachable and operable via keyboard
// Performance
- Transaction throughput at month-end batch: ledger write performance must not degrade under end-of-month high-volume conditions
- Reconciliation file processing latency: assert the end-of-day reconciliation completes within the defined window before the next business day starts
- Real-time balance update under concurrent transfers: assert balance is accurate and consistent under parallel inbound and outbound transfers
// Mobile & responsive
- Mobile payment confirmation flow and OTP entry: assert the OTP input is auto-focused, numeric keyboard is triggered, and the flow completes without layout breaks
- Transaction history pagination on small screen: assert infinite scroll or pagination controls are usable and that all transaction fields are visible without horizontal scrolling
// BUGS & SCENARIOS
// Common bugs
| Bug | Scenario / repro |
|---|---|
| Ledger not updated on success | Transaction completes at the provider; webhook is received and acknowledged; but the ledger write fails silently — transaction history shows success, balance is not updated |
| Duplicate charge on retry | Client submits a payment; request times out at the network layer; client retries; server creates two charge records because no idempotency key was enforced — customer is charged twice |
| Premature success status | Payment status is set to 'success' immediately on submission; provider webhook arrives 3 seconds later with a decline; customer has already been shown a success confirmation and given access |
| Rounding error on fee calculation | 2.9% processing fee applied to a $0.01 transaction rounds to $0.00; the minimum-fee floor ($0.30) is not applied; transaction is processed at a net loss |
| Refund status updates, ledger does not | Refund is issued via the admin API; provider processes and confirms; but the webhook updates the order status and not the ledger — customer balance is not restored |
// Example test scenarios
- 01Submit a payment and delay the provider webhook by 5 seconds using WireMock — assert the payment status stays 'pending' until the webhook arrives and does not transition to 'success' prematurely
- 02Submit the same payment twice with identical request body and the same idempotency key — assert exactly one charge is created at the provider and one ledger entry is written
- 03Initiate a full refund via the admin API — assert the order status, the ledger entry, and the customer-facing balance all update atomically within the defined window
- 04Submit a transfer of $0.01 — assert the minimum-fee floor is applied and the fee is not rounded to $0.00
- 05Attempt a transfer just above the single-transaction limit via a direct API call without going through the UI — assert a 422 is returned with a limit-exceeded error code, not a 500
// Edge cases
- FX payment: the exchange rate at transfer time differs from the rate at settlement time — assert the locked transfer-time rate is used for the customer record
- Provider webhook arrives after the daily reconciliation window has already closed — assert it is queued and applied to the next reconciliation cycle, not silently dropped
- Transaction fails but a fee is still deducted — assert the fee deduction is reversed or logged as a reconciliation item
- KYC document expires mid-transaction flow: document was valid when the flow started but the KYC provider marks it expired before the final confirmation step
- Month-end statement: closing balance timezone mismatch — assert the statement cutoff uses UTC, not the server's local timezone
- Interest accrual spanning a leap year with a mid-cycle rate change: accrual must split at the rate-change date and apply the correct day-count convention on each side of the boundary
- Value-dating and batch posting order: a backdated transaction posts with the correct value date and the overnight batch applies transactions in the correct sequence — distinct from end-of-day reconciliation latency, which is a performance concern
- Legacy core-banking integration: the real-time channel (app) and the overnight batch (core) show divergent balances mid-cycle until the batch reconciles — assert the intra-day divergence window behaves per spec and resolves on batch completion
// AUTOMATION & TOOLS
// What to automate
- Parallel payment with same idempotency key: fire two simultaneous requests with identical idempotency keys and assert exactly one charge is created
- Reconciliation diff: at end of each test run, compare the internal ledger total against the provider sandbox statement and assert zero discrepancy
- Currency rounding matrix: parametrised tests across a set of fractional amounts and fee percentages, asserting the minimum-fee floor is always applied
- Transaction limit boundary: automated tests at exactly the limit, one unit below, and one unit above — for per-transaction, daily, and cumulative limits
// Useful tools
PostmanPayment API collections, webhook simulation, idempotency testingWireMockStub provider webhooks — simulate delay, retry, and failure scenariosPactContract testing between payment service and provider APIWebhook payload testerInspect and replay provider webhook payloads during developmentAPI testing checklistStructured checklist covering status codes, error bodies, and edge casesAPI testing masterclassEnd-to-end API testing course covering contract, integration, and security testing
// SHIP & LEARN
// Release readiness checklist
- Idempotency test green — duplicate webhook and duplicate request both create exactly one record
- Reconciliation diff clean — internal ledger matches provider sandbox statement after all test transactions
- Rounding matrix passed — minimum-fee floor applied on all sub-cent transaction amounts
- Premature-success scenario covered — status stays pending until webhook, not set on submission
- Refund ledger-sync verified — order status and balance both update atomically on refund confirmation
- Transaction limit enforced at API layer — direct API call over limit returns 422, not 200
- PCI log scan clean — no card numbers or CVVs appear in any log output
- Provider sandbox smoke test passed — full payment → webhook → ledger → balance flow completes correctly
- Interest accrual matrix reconciles to expected: day-count conventions × leap-year × mid-cycle rate change all match the golden accrual table