Payment security is a problem of value, authority and state. A transaction can be exploitable if an attacker changes an amount, repeats a callback, races a refund or causes the customer view and authoritative ledger to disagree. Vendor evaluation must reveal whether testers can reason about those outcomes.

Use a realistic fictional transaction during selection. Provide actors, instruments, states and a workflow, then ask candidates to construct abuse cases and safe proof.

Describe the money movement before the test

Give all candidates the same transaction map: payer, payee, merchant, operator, payment service, bank or network, internal ledger and reconciliation process. Mark where amount, currency, beneficiary, fee, status and reference are created or trusted.

Ask the vendor to restate the system in its own model. It should separate customer-visible state from provider status and internal accounting. If the team cannot explain which record authoritatively represents value, it cannot prove the impact of a business-logic weakness.

  • Actors and roles allowed to initiate, approve, reverse or inspect.
  • Transaction states and permitted transitions.
  • External callbacks, queues, retries and reconciliation jobs.
  • Authoritative ledgers, balances and settlement records.

Test invariants, not isolated screens

A capable provider converts business rules into invariants: value is neither created nor lost; each debit has the intended credit; one authorization produces at most one effect; currency and fee rules remain consistent; and a user cannot move another party’s funds.

  • The final amount equals the approved amount and currency.
  • The beneficiary and funding source remain bound through completion.
  • Cancellation or failure cannot coexist with a settled benefit.
  • Limits apply across channels, accounts and concurrent attempts.

Exercise role and ownership abuse

Require tests that compare customer, merchant, support, finance and administrator identities. The vendor should inspect object access and function authority, then combine them with transaction state. A valid refund function can still be unsafe when invoked for another merchant or after settlement.

  • Another customer cannot view, approve, cancel or redirect the transaction.
  • Support roles cannot exceed documented monetary powers.
  • Merchant identities cannot operate on a different merchant’s orders.
  • Service credentials are limited to intended functions and tenants.

Validate server-side amount and beneficiary binding

Ask how the team detects parameter substitution across quotation, authorization, confirmation and capture. Values may move through browser fields, app requests, tokens, metadata, webhooks and internal events. The provider should identify where each value becomes authoritative and whether it can change later.

The test must compare what the user approved with what the system executed. A modified response or cosmetic display is not sufficient evidence, while a small controlled ledger discrepancy may be enough if coordinated and reversible.

  • Amount, currency, fee and discount are recalculated or protected server-side.
  • Beneficiary and destination cannot change after authorization unnoticed.
  • References cannot be reused to bind a new transaction.
  • Partial capture and partial refund obey cumulative limits.

Probe replay and idempotency across channels

Payment flows retry by design. Ask how the vendor distinguishes safe retry from duplicate financial effect across UI submissions, APIs, mobile clients, webhooks, workers and operator tools. It should understand idempotency scope, key ownership, expiry and parameter consistency.

A mature approach observes all effects: response, order state, provider record, internal ledger and notifications. It does not flood a production processor to prove a race.

  • Identical requests cannot create unintended duplicate debits or credits.
  • An idempotency key cannot be reused across users or different parameters.
  • Delayed callbacks do not resurrect cancelled or replaced transactions.
  • Manual and automated retry paths converge on one outcome.

Assess concurrency and time-of-check gaps

Ask candidates to design a bounded concurrency test for balance checks, inventory, coupon use, withdrawal limits or approval thresholds. They should state request count, test value, accounts, monitoring, abort conditions and cleanup.

Strong testers look beyond simultaneous HTTP calls. Queues, batch settlement, optimistic updates and eventual consistency can create ordering gaps. The evidence should include timestamps and authoritative postconditions without relying on an unstable screen response.

  • Concurrent debits cannot spend the same available value twice.
  • Approval and execution use consistent role and limit state.
  • Reservation expiry cannot release value that has already settled.
  • Compensation jobs cannot repeat or over-correct the financial effect.

Test callback and provider trust boundaries

External payment status often arrives asynchronously. Ask how the vendor verifies callback authentication, source assumptions, event identity, amount binding, ordering and replay handling. IP allowlisting alone should not be treated as message authenticity.

The team should also test server-to-server verification and ambiguous provider states. A forged success is one risk; accepting a genuine success for the wrong order, user or amount is another.

  • Signature or equivalent authenticity is verified over the right message.
  • Event and transaction identifiers are bound to the internal order.
  • Out-of-order success, failure and refund events converge safely.
  • Duplicate delivery is expected and idempotent.

Include refunds, disputes and administrative paths

Primary checkout is only part of the lifecycle. Require coverage of voids, partial and full refunds, chargebacks, payouts, withdrawal, account closure, reconciliation adjustments and support interventions relevant to the product.

Ask who can perform each action, at what state, within which amount and with what approval. The vendor should test the same rule through all channels, including less visible operator APIs and batch jobs.

  • Cumulative refunds cannot exceed captured value.
  • A refund returns value to the correct source or authorised destination.
  • Maker-checker and step-up requirements cannot be bypassed through another route.
  • Closed, disputed or sanctioned accounts follow explicit handling rules.

Demand safe evidence and financial guardrails

Before appointment, ask the vendor to write the safety section it would place in the rules of engagement. It should specify test accounts, value ceilings, processor coordination, prohibited instruments, monitoring contacts, stop authority and recovery.

Evidence should minimize cardholder and personal data. Tokens, account identifiers and payloads must be redacted consistently, and artefacts encrypted with named retention and deletion rules. A good finding proves impact without creating a real customer loss.

  • Only designated test identities and instruments are used.
  • Per-test and aggregate financial exposure have hard limits.
  • Critical or irreversible effects require explicit approval.
  • Ledger and provider records are reconciled after testing.

Use a scored live case

Give each candidate the same case: two customers, one merchant, asynchronous provider callbacks, wallet balance, refund and a support role. Ask the proposed lead tester to identify invariants, highest-risk hypotheses, access needs, first five tests and proof.

Score whether the candidate reasons from business outcomes, identifies authoritative records, handles concurrency safely and states uncertainty. Deduct for simply listing SQL injection, XSS and generic API categories.

  1. Score state modelling and invariant quality.
  2. Score identity, role and tenant coverage.
  3. Score replay, race and asynchronous reasoning.
  4. Score evidence, safety and retest clarity.

Set report and retest acceptance criteria

A payment finding must describe actors, preconditions, initial state, action sequence, authoritative result and financial consequence. Severity should reflect reachable value, scale, detectability and recovery—not merely the name of a technique.

Retesting should cover the repaired transition and relevant variants, including duplicate, delayed and concurrent events. Require evidence that accounting and customer-visible state reconcile after the fix.

Use the official OWASP Web Security Testing Guide business-logic section to structure abuse testing and the OWASP API Security Top 10 for API authorization and resource-consumption risks. Where payment-card data is involved, align handling with the current PCI Security Standards Council document library and the organisation’s assessed scope.

Select for transactional reasoning, not checklist coverage

Payment testing needs technical depth and disciplined restraint. The provider must understand protocols and APIs, but it must also reason about accounting, timing, role, recovery and human operations.

WIMD evaluates payment-testing capability with state models, invariant-based abuse cases, controlled transaction values, multi-role evidence and ledger-aware retesting. That makes the procurement decision defensible before any real system is placed at risk.