High-risk business workflows must be scoped as systems of value, authority and state—not as a list of pages or endpoints. A payment can begin in a mobile app, cross several APIs, depend on a provider callback and finish in an internal ledger or support console.

The scope should let the tester prove whether approved value, beneficiary and state remain consistent across happy paths, failures, retries, concurrency and human intervention. It must also prevent the assessment itself from creating uncontrolled financial or customer impact.

Every scoped journey needs a named business owner and authoritative evidence source.

Name the business journeys in scope

List payment, authorization, capture, transfer, wallet top-up, withdrawal, refund, void, payout, dispute and adjustment journeys that the product supports. Separate materially different channels or providers.

Prioritize by value, customer impact and authority. A single checkout label can hide several state machines with different trust boundaries.

  • Customer purchase and recurring charge.
  • Peer or merchant transfer.
  • Wallet funding and withdrawal.
  • Refund, reversal and dispute.

Map every actor and role

Document payer, payee, merchant, support, finance, administrator, processor, bank and service identities. Include maker-checker and delegated roles.

For each action, state who may initiate, approve, cancel, inspect and override. This forms the authorization matrix and the accounts required for testing.

  • Customer and beneficiary.
  • Merchant or tenant operator.
  • Support and finance roles.
  • Automated service and provider actors.

Identify value and binding fields

Record amount, currency, fee, discount, instrument, source, destination, beneficiary, order and transaction references. State where each value becomes authoritative.

Scope tests that change values across quotation, confirmation, authorization, capture and settlement. Client display and server execution must remain bound to the same approved transaction.

  • Amount and currency.
  • Funding source and beneficiary.
  • Fee, tax and discount.
  • Order, provider and ledger identifiers.

Draw the state machine

List valid states and transitions, including pending, authorised, captured, settled, failed, expired, cancelled, refunded and disputed as applicable.

Document which component owns each transition and what evidence confirms it. Invalid, repeated or out-of-order transitions should become explicit test hypotheses.

  • Entry and terminal states.
  • Permitted actor per transition.
  • Timeout and expiry.
  • Compensation and recovery paths.

Connect channels and operations

Map web, mobile, public API, partner, webhook, worker and administrative routes that reach the same effect. A strong control should not depend on the easiest client path.

Assign operation ownership to avoid gaps between separate web, API and mobile scopes. The workflow remains one assurance object even when testing is divided.

  • Customer clients.
  • Direct and partner APIs.
  • Provider callbacks and webhooks.
  • Back-office and batch operations.

Scope authorization and ownership comparisons

Provide multiple customers, merchants and tenants with known objects. Test whether another identity can view, approve, cancel, redirect, refund or export a transaction.

Include support impersonation, custom roles and service credentials. Function authority and object ownership often fail in different layers.

  • Owner versus peer.
  • Same-tenant versus cross-tenant.
  • Customer versus privileged role.
  • User versus workload identity.

Include replay and idempotency

Document idempotency keys, uniqueness rules, retry windows and duplicate callback handling. Scope the same action through every channel that can retry.

Evidence should reconcile response, provider record, internal transaction and ledger effect. One successful response is not proof of one financial effect.

  • Duplicate submission.
  • Reused key with changed parameters.
  • Delayed or repeated callback.
  • Manual and automated retry collision.

Include concurrency and ordering

Identify balance, inventory, coupon, limit and approval decisions susceptible to races. Define bounded concurrency tests and monitoring.

Include asynchronous ordering, worker retries and eventual consistency. The goal is to test invariants safely, not stress production indiscriminately.

  • Double spend or double benefit.
  • Limit bypass across simultaneous actions.
  • Approve-versus-cancel race.
  • Compensation duplication or overcorrection.

Cover refunds, disputes and exceptional paths

Scope partial and full refunds, voids, chargebacks, reversals, failed settlement, account closure and manual adjustments. These paths often have different roles and services from the initial payment.

Define cumulative limits and destination rules. Returned value should follow policy and never exceed captured value or move to an unauthorised instrument.

  • Partial and cumulative refund.
  • Refund after transfer or settlement.
  • Dispute and chargeback state.
  • Administrative correction and write-off.

Map provider callbacks and trust

Document callback authentication, signature coverage, event identity, ordering and server-to-server verification. Record test facilities and provider restrictions.

Scope genuine-event misbinding as well as forged events. A valid provider success applied to the wrong order or amount is still a business-logic failure.

  • Authenticity and replay.
  • Amount and currency binding.
  • Order and tenant binding.
  • Out-of-order event convergence.

Identify authoritative records

Name the transaction database, ledger, balance, provider record and reconciliation output that prove the final effect. Define who can observe them during testing.

Customer-visible status may lag or be cosmetic. Findings and retests should rely on the record that actually controls value and obligation.

  • Internal double-entry or balance record.
  • External processor status.
  • Order and entitlement state.
  • Reconciliation and exception queue.

Set financial and operational guardrails

Use designated accounts, instruments, merchants and low values. Define aggregate exposure, prohibited networks, monitoring, stop contacts and cleanup.

Production tests require explicit authorization for irreversible or third-party effects. Coordinate refunds and reconciliation after the test window.

  • Per-test and total value cap.
  • Approved test instruments.
  • Concurrency and rate ceiling.
  • Immediate stop and incident path.

Define evidence and closure

Findings should record actors, initial state, action sequence, control case, authoritative result and financial consequence with safe redaction.

Retesting must cover the repaired transition and representative replay, concurrency or alternate-channel variants. Reconcile all test transactions before closure.

  1. Approve actor and state matrices.
  2. Validate test accounts and records.
  3. Execute within financial guardrails.
  4. Retest invariants and reconcile value.

Use the OWASP Web Security Testing Guide for business-logic testing context, the OWASP API Security Top 10 2023 for API authorization and resource risks and NIST SP 800-115 for rules and execution planning.

Scope the invariant, not only the interface

The strongest workflow scope states what must always remain true: value is conserved, authority is respected and one approved action produces the intended effect.

WIMD turns those invariants into actor, state, channel and evidence matrices so testing can be deep without becoming financially unsafe.