Design a test strategy for a payments service

Payments are a domain where a single defect means real money is lost or customers are charged twice, so I would frame the strategy around money-correctness risks first, then layer the usual functional and non-functional testing around it.

Clarify scope

• Which payment methods (cards, wallets, bank transfers) and which provider or providers?
• Does the service authorise and capture separately? Does it handle refunds, partial refunds, chargebacks, subscriptions?
• Which currencies and regions? Are there strong customer authentication requirements such as 3-D Secure?
• Is card data handled directly, or is it tokenised by the provider (which keeps most systems out of the heaviest PCI DSS scope)?
• What are the latency and availability targets, and peak volumes (sales events)?

Top risks

1. Duplicate charges from client retries, network timeouts or double clicks.
2. Incorrect state (an order marked paid when the capture failed, or vice versa).
3. Wrong amounts through rounding, currency conversion or floating-point errors.
4. Unknown outcomes when the provider times out mid-request.
5. Data exposure: card data or tokens in logs, authorization flaws between merchants or customers.
6. Reconciliation gaps: our ledger disagrees with the provider’s settlement reports.

Test layers

Unit and component tests

• Amount calculation in integer minor units or a decimal type, never binary floating point. Cover currencies with different minor units (for example JPY has none, while most others have two), rounding on tax and discounts, and partial refunds summing exactly to the original.
• State machine tests: enumerate allowed transitions (created to authorised to captured to refunded, authorised to voided, failed) and assert that illegal ones (refund before capture, capture twice) are rejected. A transition table works well as parameterized test data.

API and integration tests with a stubbed provider

Use WireMock or a similar stub to simulate the provider deterministically:

• success, decline with each relevant decline reason, insufficient funds
• timeout after the provider accepted the charge, then verify the service queries status or reconciles instead of charging again
• slow responses, 5xx errors, malformed responses
• webhooks arriving late, out of order, duplicated, or with an invalid signature

Idempotency tests

@Test
void sameIdempotencyKeyDoesNotChargeTwice() {
    String key = UUID.randomUUID().toString();
    String body = """
        {"orderId":"%s","amount":{"value":4999,"currency":"GBP"}}
        """.formatted(orderId);

    String first = given().header("Idempotency-Key", key).contentType("application/json").body(body)
        .when().post("/payments")
        .then().statusCode(201).extract().path("paymentId");

    String second = given().header("Idempotency-Key", key).contentType("application/json").body(body)
        .when().post("/payments")
        .then().statusCode(anyOf(is(200), is(201))).extract().path("paymentId");

    assertEquals(first, second);
    assertEquals(1, providerStub.chargeRequestsFor(orderId));
}

Also fire the same request concurrently from several threads, and check that the same key with a different body is rejected.

Contract tests

Between checkout, the payments service and downstream consumers (orders, ledger, notifications), so field renames or enum changes are caught before deploy.

Provider sandbox tests

A small suite against the provider’s sandbox with their documented test cards, covering 3-D Secure challenges and declines. Sandboxes can be slow and rate-limited, so keep this suite small and outside the PR gate.

End-to-end

A few journeys only: pay successfully, pay with challenge, decline and retry with another card, full refund.

Non-functional

• Performance at expected peak plus headroom, with p95 and p99 targets, including provider latency simulated by stubs.
• Resilience: provider outage, circuit breaker behaviour, queue backlog recovery.
• Security: authorization matrix (customer A cannot refund customer B’s payment), log scanning to prove no card numbers or CVV appear, secrets management, dependency scanning. Formal PCI DSS assessment is a compliance activity, but tests should support its controls.

Production safeguards

• Daily reconciliation between internal ledger and provider settlement files, alerting on any mismatch. This is a test that runs in production.
• Dashboards on authorisation rate, decline reasons, error rates and latency; alerts on sudden changes.
• Feature flags and canary releases for changes to payment flows.
• Synthetic transactions with test accounts where the provider supports it.

What interviewers look for

• Idempotency and duplicate-charge prevention raised early, unprompted.
• Explicit handling of the “unknown outcome” timeout case.
• Money represented safely, with currency-aware rounding tests.
• Heavy use of stubs for determinism, with a small real-sandbox suite.
• Reconciliation and monitoring as part of the strategy.

Common mistakes

• Designing only happy-path UI tests through checkout.
• Assuming the provider sandbox behaves exactly like production in all failure modes.