QA audit and test strategy

What a fintech QA audit covers

Payment states and failure paths

We map every state that a payment, payout, refund, and dispute can reach, from provider event types, webhook handlers, and the state machine in code. Each transition is marked as automated, manual, or untested. The gaps that cost money are usually off the main path:

• Timeout after the provider accepted the request. The client retries without an idempotency key, and the customer is charged twice. The payment idempotency guide shows the test.
• Webhooks out of order or delivered twice. A refund event processed before its capture event leaves the payment stuck, and a repeated payout event moves a balance twice.
• Returns after funds are available. An ACH debit comes back as returned after the platform has let the user spend the pay-in, and the negative balance becomes a loss for the business.
• Partial operations. A partial capture followed by a partial refund, or a BNPL instalment schedule recalculated after a partial refund, produces amounts that single-step tests never check.

Where a flow has no usable suite, the roadmap points to the scope of payment flow testing.

Reconciliation checks

We check whether reconciliation logic is tested before release or only runs in production under the operations team. The assessment answers three questions from evidence:

• Does CI fail when a journal does not balance per currency, or when a stored balance differs from the sum of its postings?
• Do test bank statements and processor settlement files contain injected breaks, such as duplicates, missing lines, reversals, and entries booked on the next business day?
• Does a parser change or a new partner bank trigger a replay of the reconciliation scenarios?

Without these tests, a break first appears in the finance team's month-end close, after payouts calculated from a wrong balance have left. Ledger and reconciliation testing is the follow-on scope for these gaps.

Regulatory requirement traceability

We take the requirements that your compliance team maps to the product, such as disclosure timing, dispute and error resolution deadlines, fee caps, and authentication rules. Each requirement is traced to its test cases, the last run result, and the stored evidence. Typical findings:

• a requirement in a policy document with no test case behind it;
• a test case whose only evidence is an undated screenshot with no build or environment named;
• a requirement tested once at launch and never rerun after the flow changed.

When a partner bank or an examiner asks for evidence of a control, each of these gaps forces the team to rebuild evidence under a deadline. Segment pages list the evidence requested per jurisdiction, for example Banking-as-a-Service and card issuing.

Release gates for ledger and money logic changes

We read the change history for posting rules, fee and interest calculations, rounding, the chart of accounts, and balance migrations, and record which gate each change passed. Failure patterns we look for:

• a fee rounding hotfix released with unit tests only, which leaves a residue on every transaction until finance sees the drift;
• an interest accrual change in a lending product deployed without comparing accrued amounts per loan before and after the change;
• a migration that rewrites balances, run without count and sum comparisons between the old and new tables and without a rollback plan;
• a feature flag that sends some customers to new posting logic while reconciliation still expects the old entries.

Environments, test data, and automation

We check whether the test environment can produce events that a provider sandbox does not send on demand, such as returns, chargebacks, and late or repeated webhooks. We also list the regression suites that fail intermittently or run too long to gate each release, since a suite that is skipped before a release blocks no defect.

Technical due diligence before funding or acquisition

An investor, acquirer, or partner bank asks which money flows have automated coverage, how a ledger change is approved, which money-affecting defects reached production, and what remains open. The due diligence summary answers from the evidence gathered in the assessment. The technical due diligence scenario sets out the sequence.

Inputs and duration

We need read access to repositories and CI configuration, exports from the test management tool and defect tracker, the incident list, and the compliance requirement register. We interview the engineering lead, the QA lead, finance operations, and compliance, and sample recent releases that changed money logic. As an engineering estimate, one product with card and bank transfer flows needs two to four elapsed weeks from access to readout. Each added provider, rail, or jurisdiction extends that range. A due diligence summary on an investor deadline can be limited to the flows the investor names.