Payments Testing

1 The Hook

A fictional NZ retailer, Kauri & Co, took a $120 EFTPOS card payment at the counter on a Friday afternoon. The terminal beeped, the screen said approved, the customer walked out with their goods. The shop assumed it had its money.

On Monday the retailer’s bank statement did not show the $120. The payment had been authorised — the customer’s bank had confirmed the funds and placed a hold — but it had never been settled. A defect in the terminal’s end-of-day batch meant the day’s authorised transactions were never sent for settlement. The hold on the customer’s account quietly expired a few days later, and the money simply never moved. The shop had goods out the door and nothing in the bank.

To the cashier, the customer, and the shop owner, the payment had “gone through.” The approval beep was real. But approval is not money. The payment had completed the first half of its life — authorisation — and silently failed the second half — settlement. The two are separate steps that can succeed or fail independently, and most people, including many testers, treat them as one.

Here is the lesson hidden in that story. The team had tested that a card payment got approved. They had a green path that ended at the approval screen. No test followed the payment all the way to settled funds and reconciled them against what the terminal reported. The gap between “approved” and “settled and reconciled” is exactly where payments testing lives.

2 The Rule

3 The Analogy

4 The NZ Payment Rails

A “rail” is a path money travels along. NZ has several, and they behave differently enough that a tester must know which one a payment uses.

Card and EFTPOS. When a customer taps or inserts a card, the payment runs through a scheme — the EFTPOS network for domestic debit, or an international scheme for credit and contactless. The defining feature is the two-step nature: an authorisation in real time, then settlement later in a batch. The Kauri & Co case is a card-rail failure between those two steps.

Direct debit. Here the customer gives a biller standing authority to pull money from their account — a gym, a power company, an insurer. The biller initiates; the customer’s bank honours it against the authority on file. The risks are different: a debit pulled without valid authority, a debit for the wrong amount, or a debit the customer is entitled to dispute and have reversed.

Bill payment and bank transfer. A customer pushes money from their account to a payee — paying a bill, sending money to a friend. Traditionally these moved between NZ banks in scheduled interbank exchanges through the day, so a payment made late in the evening might not land in the payee’s account until the next business day. This is the “7-day” world many people still picture.

Real-time / faster payments. NZ is moving toward payments that clear in seconds, any time, including weekends. The principle a tester holds onto is that real-time changes the timing and irrevocability but not the obligations: the right amount must reach the right payee, and the movement must still reconcile. Real-time payments are often final the instant they land, which raises the stakes on getting the payee and amount right the first time, because there is no comfortable settlement window to catch an error in.

5 Authorisation versus Settlement

This distinction is the spine of card payments testing, so it is worth being precise.

Authorisation is the real-time check. The merchant’s system asks the customer’s bank: is this card valid, and are these funds available? The bank answers approve or decline, and on approval it places a hold — the customer’s available balance drops by the amount, but the money has not actually left. No funds have moved yet. The hold is a promise, with an expiry.

Settlement is the later movement of the actual money, usually in an end-of-day batch. The merchant submits the day’s authorised transactions, and funds move from the customers’ banks to the merchant’s bank. Only now has money truly changed hands.

Several things can go wrong in the gap, and each is a test:

• Authorised, never settled: the Kauri & Co failure — the hold expires and the money never moves.
• Settled amount differs from authorised amount: common and legitimate for tips or fuel, where the final charge differs from the hold — but it must be within the allowed rules and tracked.
• Double settlement: the same authorisation is submitted twice, charging the customer twice.
• Hold not released on decline or cancellation: the transaction is abandoned but the customer’s funds stay locked, so they cannot spend their own money.

For a tester, the rule is simple: never stop at the approval screen. Follow every payment to settled funds, and confirm the settled amount, the settlement timing, and that any hold was correctly released or converted.

6 The Payment Lifecycle and Chargebacks

A card payment has a longer life than authorise-then-settle. After settlement comes the possibility of a dispute.

A chargeback is a customer-initiated reversal of a settled card payment, raised through their bank — the goods never arrived, the charge was fraudulent, the amount was wrong. The money flows back from the merchant to the customer, and the merchant may be asked to provide evidence to contest it. For NZ debit and many everyday payments there are also dispute and reversal paths, and persistent unresolved disputes can end up at the Banking Ombudsman.

A refund is different and worth not confusing with a chargeback. A refund is initiated by the merchant — a willing return of money — and it is a fresh payment in the opposite direction, with its own authorisation and settlement. A chargeback is forced by the customer’s bank; a refund is given by the merchant. Both must reconcile, and a tester checks that a refund moves the right amount, that it cannot exceed the original payment, and that a refunded transaction cannot also be charged back for the same money.

So the full lifecycle a tester reasons about is: authorise → settle → reconcile → (possibly) refund or chargeback → reconcile again. Each transition is a place where money can be duplicated, lost, or moved by the wrong amount. The test job is to prove that at every stage the books on both sides still agree.

7 What to Test in a Payment

The practical checklist for a payments tester:

• Authorisation paths: approve, decline (insufficient funds, invalid card, limit exceeded), and timeout. A timeout is not an approval — test that an unanswered authorisation is treated as not authorised.
• Settlement completeness: every authorised transaction that should settle does settle, and the settled total equals the authorised total, accounting for legitimate adjustments.
• Hold lifecycle: a hold is placed on authorisation, released on decline or cancellation, and converted — not duplicated — on settlement.
• Idempotency: resubmitting the same payment (a retry after a dropped connection) must not charge the customer twice. This is critical for real-time rails where the client cannot tell if the first attempt landed.
• Direct debit authority: a debit only succeeds against a valid authority, for an amount within its terms, and a disputed debit can be reversed.
• Reconciliation: the merchant’s records, the scheme’s settlement report, and the bank’s ledger all agree, with breaks flagged.
• Refunds and chargebacks: a refund cannot exceed the original; a transaction cannot be both refunded and charged back for the same amount.

8 Building Payment Test Cases

A strong payment test case states which rail it is on, follows the payment past approval, and asserts on settled funds and reconciliation — not just the approval response.

Here is a worked test case for the Kauri & Co card scenario, written to catch the exact bug that hurt them:

Notice what makes this catch the Hook bug: the expected result has three numbered stages, not one, and stage 2 (settlement) is asserted explicitly. The reconciliation line demands that the settled total equals the authorised total with zero missing items — precisely the check that was absent at Kauri & Co. And the rail is named at the top, so the reviewer knows it is two-step.

9 Common Mistakes

10 Now You Try

Three graded exercises across the payment lifecycle. Write your answer, run it for AI feedback, then compare to the model answer.

There are at least four real risks here; any three well-explained earns full marks.

1. No idempotency on retry — Pressing "Pay now" again sends a second authorisation, so a dropped connection can charge the customer twice. Lifecycle part: idempotency / authorisation. Impact: double charge. Fix: an idempotency key so a retry maps to the same single payment.

2. Hold not released on cancellation — An order cancelled after approval but before settlement leaves the authorisation hold in place, so the customer's funds stay locked until the hold expires on its own. Lifecycle part: hold. Impact: customer cannot spend their own money. Fix: release the hold on cancellation.

3. Refund with no already-refunded check — Re-using the original authorisation reference for refunds with no check means the same order can be refunded more than once. Lifecycle part: refund. Impact: the merchant pays out the same money twice. Fix: check refund status and that total refunded cannot exceed the original.

Bonus: success page on approval only — like Kauri & Co, the customer is told it succeeded at authorisation, before settlement is confirmed, so an authorised-but-never-settled order looks complete to everyone.

The trap: every one of these passes a "the payment was approved" test, because approval is the one thing that does work.

Test ID: PAY-EFT-015

Rail: Card / EFTPOS (two-step: authorise then settle)

Risk category: Authorised-but-never-settled / hold not converted

Pre-conditions: Test card with sufficient funds; ANZ merchant account; settlement batch scheduled; card available balance captured as baseline.

Action: Tap the card for $50.00; allow the end-of-day settlement batch to run.

Expected result: 1) Authorisation approved and a $50.00 hold placed (available balance drops by $50.00, ledger balance unchanged). 2) After the batch, $50.00 settles to the merchant account and the customer's ledger balance drops by $50.00. 3) The hold is converted to a settled charge, not duplicated or left to expire.

Reconciliation: Settled total for the batch equals the authorised total; this transaction appears exactly once in the settlement report; 0 authorised items missing from settlement.

Evidence required: Authorisation response; before/after available and ledger balances on the card; settlement batch report line for this payment; merchant ledger credit; authorised-vs-settled reconciliation showing this item once.

Traceability: Risk register R-03 (approved transactions not settled) and R-05 (hold not converted).

What makes it strong: the rail is named, the expected result has distinct authorise/settle/hold stages instead of one "approved", it asserts on settled funds and the hold conversion, and reconciliation demands the settled total tie to the authorised total with the item appearing exactly once. The original asserted none of this.

DD-01 | Verifies: a debit succeeds only against a valid authority on file | Acceptance criteria: debit with a valid authority posts the correct amount; debit with no/invalid authority is rejected | Evidence required: authority record; posted debit; rejection log for the no-authority case

DD-02 | Verifies: a debit for the wrong amount is handled per the authority terms | Acceptance criteria: an amount outside the authority's agreed terms is rejected or flagged, not silently posted | Evidence required: authority amount terms; the attempted amount; the reject/flag outcome

DD-03 | Verifies: an expired or cancelled authority cannot be debited | Acceptance criteria: a debit against a cancelled/expired authority is rejected; 0 funds move | Evidence required: authority status (cancelled/expired) with date; rejection record; account balance unchanged

DD-04 | Verifies: insufficient funds is handled correctly | Acceptance criteria: the debit is declined (or handled per policy), no partial posting, customer balance not driven below limits incorrectly | Evidence required: balance before; decline response; balance after (unchanged)

DD-05 | Verifies: a disputed debit can be reversed | Acceptance criteria: a valid dispute reverses the debit, returning the exact amount to the customer; the reversal reconciles | Evidence required: dispute record; reversal posting equal to the original; before/after balances; reconciliation of the reversal

Strong plans: each case is specific, has a measurable criterion, names concrete evidence, and together they cover valid authority (DD-01), wrong amount (DD-02), expired/cancelled authority (DD-03), insufficient funds (DD-04), and dispute/reversal (DD-05). Weak plans say "check the direct debit works" five times — that is the difference being marked.

11 Self-Check

Click each question to reveal the answer.

12 Interview Prep

Real questions asked in NZ QA interviews for payments roles. Read the model answers, then practise your own version.