🔵 Fintech QA

Model answer

Authorisation is the provider confirming and reserving the funds; capture is the later step that actually settles them. They're separate calls that can fail independently, so I test them separately. For authorisation: a valid auth places a hold, a declined card returns the right error, and an auth that's never captured eventually expires and releases the hold. For capture: capturing a valid auth settles the correct amount, a partial capture settles less than authorised (e.g. a partial shipment), capturing more than authorised is rejected, and a capture attempted after the auth expired fails cleanly. The interesting state is auth-succeeded, capture-failed — the customer sees a hold but no completed transaction — so I assert the system surfaces and reconciles that rather than stranding a phantom hold. Throughout, I use only sandbox test cards, never real credentials.

Model answer

A network timeout is ambiguous — the charge may have gone through — so the client must retry safely, and the mechanism is an idempotency key. I'd send the same payment body twice with the same key and assert exactly one charge at the provider and one ledger entry, with the second call returning the original result rather than creating a new one. I'd test the timing race: two requests with the same key arriving nearly simultaneously must still produce one charge, so I fire them in parallel. I'd test that different payments with different keys both go through, and that a reused key with a different amount is rejected rather than silently returning the old charge. This is specifically about the money side effect and the ledger write being deduplicated; it's distinct from webhook idempotency, which is about inbound event delivery. Sandbox provider only, no real cards.

Model answer

The trap is that 2.9% of $0.01 rounds to $0.00, so I assert the minimum-fee floor (say $0.30) is applied instead — the transaction either carries the floor fee or is rejected per the product rule, never processed at a loss. I'd build a small matrix of fractional amounts and fee percentages and check each against the documented rounding rule, watching for the boundaries where rounding flips a cent. Because these errors compound, I'd also run an aggregate check: process a large batch and reconcile that the summed fees match the expected total to the cent, catching drift that's invisible per-transaction. I'd cover currency-specific rules — currencies with no minor unit, three-decimal currencies — and FX-converted amounts where rounding happens twice. The distinction from a generic boundary question is that the domain rules (minimum floor, compounding, reconciliation to the cent) drive the cases, not just min/max inputs.

Model answer

I treat reconciliation as a first-class test: at the end of a run, the internal ledger must match the provider's statement exactly, and any difference is a defect. To make it deterministic I seed known starting balances and run a controlled set of transactions — successes, failures, refunds, fees — then pull the provider sandbox statement and diff line by line and on the total. I specifically test the edge cases that cause real drift: a failed transaction that still deducted a fee, a webhook that arrived after the reconciliation window closed (it must queue to the next cycle, not vanish), a refund that updated order status but not the ledger, and timezone/cutoff mismatches where a transaction lands in the wrong day. I'd automate the diff in CI so any drift fails the build with the offending entries surfaced. The mindset is that the ledger is the source of truth and reconciliation is how we prove it, every day.

Model answer

I model the account as a state machine — open, active, dormant, frozen, closed — and test the posting rules at each state plus the transitions between them, because each state has different correct behaviour. For dormant: an account with no activity past the dormancy threshold should be marked dormant, and an inbound posting should follow the defined path — typically reactivation, where I assert the account flips back to active, the transaction applies, and an audit entry records the reactivation. For closed: a posting must not silently succeed; per policy it's either rejected with a clear error or routed to a suspense account so the funds stay traceable, and I assert one of those happens, never a silent apply to a closed balance. Closure itself needs the residual-balance test: closing an account with a non-zero balance must sweep or refund the residual per policy rather than orphaning it, and a closure attempt with funds still present behaves deterministically. I cover the transition races too — a transaction in flight when the account is closed or marked dormant, and a reactivation that coincides with an incoming batch posting. I deliberately keep this separate from the AML-frozen case, which is a compliance hard-fail on an otherwise-live account; here the concern is the lifecycle of the account itself and where money goes when the account is not in a normal state. Synthetic accounts only, seeded directly into each state so I don't have to wait out real dormancy windows.

Model answer

The bug is the internal state getting ahead of the provider's truth. I'd stub the provider to delay the confirmation webhook by a few seconds and assert that during that window the payment is 'pending' — not 'success' — and the customer doesn't yet get access to funds or fulfilment. When the webhook arrives as a decline, the state must resolve to failed and any provisional access is revoked; when it arrives as success, it resolves to success. I'd test the opposite ordering too: a webhook that arrives before the synchronous response completes. The anti-pattern I'm hunting is optimistic success on submit done for UI responsiveness, because in fintech that means showing money the provider never confirmed. So I assert the system models an explicit pending state and only transitions on the authoritative event, with WireMock giving me deterministic control over the lag.

Model answer

UI validation is a convenience; the enforcement boundary is the API, so I call the transfer endpoint directly with a valid token and skip the front-end entirely. For each limit dimension — single-transaction, daily aggregate, cumulative — I test the boundary triple: one below (allowed), exactly at (per the inclusive/exclusive rule), and one above (rejected). An over-limit call must return a precise error like 422 with a limit-exceeded code, never a 200 or a 500. The aggregate limits need stateful setup: I seed prior transactions so the next one crosses the daily or cumulative threshold, and I check the window boundary — does 'daily' reset at UTC midnight or local, and what happens to an in-flight transaction across the reset. It's structurally like proving RBAC at the API, but here the gate is a monetary ceiling rather than a role, and the failure is regulatory/financial rather than access-control.

Model answer

I'd seed synthetic accounts representing each state: verified, pending, rejected, expired KYC, and AML-flagged — all with fabricated identifiers, because using real PII or credentials in a test environment is itself a breach. Then I assert the hard-fail holds at the data/API layer: a flagged or unverified account cannot initiate a transfer even through a direct API call with a valid auth token, returning a clear blocked status. I'd test the lifecycle transitions: a document that expires mid-flow, a verification that flips from pending to rejected, and a flag applied to an account with an in-flight transaction. I'd confirm every access to an identity document writes an audit entry. The two things I'm signalling are that compliance gates are non-negotiable server-side fails, not UI hints, and that regulated test data must be synthetic by construction.

Model answer

Interest accrual is a per-day calculation, so I test it day by day against a golden table rather than checking one end balance. I seed a known principal, a documented day-count convention (say ACT/360), and a rate schedule with a defined change date, then compute the expected accrual for each day independently and assert the system matches to the minor unit. The convention is the first trap: ACT/360 divides actual days by 360, 30/360 normalises every month to 30 days, ACT/365 uses the real year length — each gives a different daily figure, so I parametrise the suite over the conventions the product supports. The leap year is the second: across a period containing Feb 29 I assert the extra day accrues under ACT conventions and is handled per spec under 30/360. The mid-cycle rate change is the third: accrual must split at the change date, the old rate applying up to the boundary per the inclusive/exclusive rule and the new rate after, so I place rate changes on a month boundary, on Feb 28→29, and on the compounding date to catch off-by-one-day errors. I also assert the compounding base — does interest compound on principal only or on principal-plus-accrued — and reconcile the summed daily accruals against the posted interest at cycle close. This is explicitly not fee rounding; the cases are driven by calendar and rate-schedule mechanics, not by min/max input values.

Model answer

In fintech the release question is 'can we prove money is exactly right', so I'd define hard gates that block shipping: reconciliation diff is clean against the sandbox statement; idempotency holds (duplicate request and duplicate webhook each produce one record); the rounding matrix passes including the minimum-fee floor; audit-log completeness is verified for every financial and permission event; and a PCI log scan finds no card data. I'd layer these for feedback speed — unit/property tests for rounding and fee math, contract tests at the provider boundary for idempotency and status mapping, integration tests for ledger writes and limits, and a thin E2E that runs the full payment → webhook → ledger → balance path in sandbox. Compliance is designed in: synthetic-only data, audit assertions in the suite, limits tested at the API. Every gate has an unambiguous pass/fail, and any red gate stops the release — correctness outranks velocity here.

Model answer

FX adds a time axis to correctness, so the core assertion is that the rate quoted and locked at transfer time is the rate used at settlement, even if settlement happens hours or days later when the market rate has moved. I'd capture the locked rate, move the simulated clock and market rate forward, settle, and assert the customer's amount matches the original quote — no silent re-fetch. I'd test the rounding carefully because conversion plus fee plus reconciliation can round more than once; I assert the documented order of operations and reconcile to the cent. Day-boundary cases matter: a transfer quoted just before the rate-day cutoff settling after it, and timezone mismatches between the quote service and the ledger (UTC vs local). I'd also cover an expired quote — if the lock window lapses before settlement, the system must re-quote explicitly, not quietly apply a new rate. The signal is that in cross-currency flows, 'when' is as load-bearing as 'how much'.