Fintech and banking application testing

In sandboxes first — Open Banking providers, card processors and core banking platforms all offer them — with scripted scenarios for declines, timeouts, reversals and duplicate submissions. The bug class that matters most in fintech is the ambiguous state: money debited but not credited, a transfer that timed out after the money moved. We design tests to force those states deliberately, because production will find them otherwise.

Yes, including the paths vendors demo least: the user whose identity check fails, the document photo taken in bad light, the applicant stuck between 'pending' and 'rejected' with no way forward. Onboarding is where fintechs lose the customers they paid to acquire, and abandoned-at-KYC is usually a testable, fixable defect rather than a fact of life.

We produce the artefacts your compliance function needs to point at: traceable test cases, recorded results with versions and environments, and defect reports with severity rationale. What we are not is a compliance consultancy — your regulatory obligations need their own advice, and we work alongside it. In our experience auditors respond better to genuine, dated test evidence than to any amount of process description.

We test money as money, not as floating point. Currency conversion, interest accrual, fee calculation and split payments all have rounding rules that must agree across your app, your statements and your ledger; a penny of drift multiplied by thousands of transactions is a reconciliation incident and, eventually, a trust incident. Boundary values, negative amounts and maximum-precision cases are all in the pack.

Duplicate payments almost always come from retries: a timeout or gateway error triggers a second attempt that also succeeds. We test idempotency deliberately, by replaying requests, killing processes mid-payment, forcing gateway errors that still capture funds, and double-firing scheduled jobs. We then reconcile the ledger against processor settlement reports, because a payment system that looks fine in the app can still be charging customers twice underneath.

Treat the sandbox as a starting point, not a sign-off. Bank sandboxes often lack realistic consent flows, error codes and payment statuses, which is why apps pass in sandbox and break live. We push sandboxes to their limits, add contract tests for each bank's quirks, and run controlled small live payments with immediate refunds before go-live, backed by per-bank regression packs for the error cases sandboxes never simulate.

Not raw. Under GDPR, copying live customer data into test environments breaches purpose limitation and data minimisation, and non-production systems are usually less secure. The workable options are masked production copies, synthetic data, or anonymised subsets that keep the messy realism of real accounts. Good fintech test data also covers what production data won't: extreme balances, failed payments, chargebacks and clock-change edge cases.