Payment flow testing

What payment flow testing covers

We model each payment method as a state machine and test every transition and failure path between authorisation and payout. The sources below were checked on 2026-09-16.

Authorisation, capture, void, and reversal

• Authorisation outcomes. Approval, hard decline, soft decline, partial approval, and issuer timeout, each mapped to the order state the payer sees.
• Capture. Full capture, one partial capture, and several partial captures up to the authorised amount. A capture above the authorised amount is rejected. A capture after the authorisation expires follows your re-authorisation rule.
• Void and reversal. A void before capture and a reversal of the uncaptured remainder after a partial capture. PSD2 Article 75(2) requires the payer's provider to release blocked funds without undue delay after it receives the exact amount, so a missing reversal message can keep the remainder of a hold on the payer's account.
• Card-present. EMV chip and contactless authorisations, and a reversal when the terminal loses the authorisation response.

Refunds and partial refunds

The sum of partial refunds never exceeds the captured amount. A refund on a voided or uncaptured payment is rejected. A refund goes to the original payment method in the original currency, and a refund that the receiving account rejects returns to a queue with an owner. For debits from a US consumer account, Regulation E section 1005.11(a)(1)(ii) treats an incorrect electronic fund transfer as an error, and section 1005.11(c)(1) gives the financial institution 10 business days after a notice of error to determine whether the error occurred, or up to 45 days when it meets the provisional credit and notice conditions of section 1005.11(c)(2). A duplicated debit that the consumer reports starts that investigation clock; see the Regulation E testing requirements.

Retries, idempotency, and duplicate requests

RFC 9110 section 9.2.2 lists PUT, DELETE, and safe methods as idempotent. POST is not among them, so a client that retries a payment POST after a timeout creates a second charge unless the API deduplicates the request. The tests cover:

• the same idempotency key with the same body, which returns the first response and creates one charge;
• the same key with a different amount, which is rejected;
• concurrent requests with one key, which produce one payment record;
• a retry after the key expires, and a retry across a service restart;
• a mobile client that resends after a network loss.

The payment idempotency testing guide shows the requests.

Webhooks and asynchronous state

Tests send duplicate events, out-of-order events (a refund event before its capture event), events delayed past an order cancellation, events with invalid signatures, and replays of old events. The state machine refuses illegal transitions, such as a refunded payment that returns to captured. Delivery infrastructure, retry schedules, and signing are covered in depth by API and webhook testing.

3-D Secure and strong customer authentication

EMV 3-D Secure tests cover the frictionless result (transStatus Y in the ARes), the challenge (transStatus C, then CReq and CRes, then the result in the RReq), attempts (A), rejection (R), and an unavailable service (U), plus the authorisation that follows each result. Delegated Regulation (EU) 2018/389 Article 5(1)(d) requires that any change to the amount or the payee invalidates the authentication code, so tests change the amount between authentication and authorisation. For a card payment with blocked funds, Article 5(3) makes the code specific to the amount the payer consented to block. PSD2 Article 74(2) states that when the payer's provider does not require strong customer authentication, the payer bears no financial loss unless the payer acted fraudulently, and a payee or payee's provider that fails to accept strong customer authentication refunds the financial damage caused to the payer's provider. See the PSD2 SCA and EMV 3DS requirements.

Settlement and payout checks

Captured and refunded amounts per business day match the processor settlement file lines and the payout amount, with tests for missing, duplicate, and late lines. Ledger-wide matching and break investigation belong to ledger reconciliation testing.