ITShield Insights

Re-check a payment limit at the moment you pay

Estimated Reading Time =

2 minutes

Technical Level =

Expert

Threat Level =

High

Attack Type =

Other

Editorial illustration for re-check a payment limit at the moment you pay

What you will learn

What you will learn

A limit checked before a payment can become stale while other requests are processed. Enforce the business rule at the transaction boundary, including concurrent actions and retries.

A payment limit can be checked correctly and still fail if the situation changes before money is committed. This is a timing problem: two actions may each pass a check based on the same earlier state. The business rule must remain true at the point where the transaction takes effect.

Understand the idea

Review concurrent requests, retries, and the operation that records the final result. A system may need a protected transaction or another suitable control so checking and committing cannot conflict. A disabled button or a preliminary balance check does not enforce the complete rule on the server.

A simple way to follow the process
  1. Check

    A request appears valid against the current allowance.

  2. Race

    Another request can change that allowance before commitment.

  3. Commit

    Enforce the invariant consistently when the payment takes effect.

A practical example

Imagine an account with enough remaining allowance for one payment. Two payment requests arrive together, and both see that allowance before either records its result. The team tests a corrected process that allows only the valid combined outcome, even under concurrent requests.

Visual guide: Re-check a payment limit at the moment you pay
A request appears valid against the current allowance. Another request can change that allowance before commitment. Enforce the invariant consistently when the payment takes effect.

What to do next

  1. Calculate the decision from trusted server-side records, not client-provided balances or totals.
  2. Bind approval to the material transaction details and invalidate it when those details change.
  3. Enforce the invariant through suitable transactions, constraints, locking, version checks, or reservation semantics.
  4. Handle retries with scoped idempotency and reject reuse for different transaction details.
  5. Reconcile outcomes with the external payment provider, including timeouts, failures, and delayed responses.

How to check the result

Use controlled transaction data to test simultaneous requests and retries. Confirm that the recorded state, payment outcome, and user message agree, including when a request is interrupted.

Both payment requests passed their initial checks. Why was the limit exceeded?

Test concurrent outcomes and the transaction’s final state. Two individually valid checks do not guarantee that both commitments can be allowed together.

Sources and useful guides

The following resources provide background and more detailed guidance. Use the sections that match your service and situation.

Scroll to Top