A commerce platform threat-models its checkout flow. Which threats are usually missed, and what makes a threat model useful rather than ceremonial?

What makes it useful rather than ceremonial

1. It produces decisions, not a document. The output should be specific changes with owners — a control added, a design altered, a risk explicitly accepted by someone with authority to accept it. A threat model producing only a list is an artefact nobody revisits.

2. It is done at design time, when changing the design is cheap. Threat modelling a shipped system produces findings that compete with the roadmap and usually lose.

3. It covers the abuse cases, not only the attack cases. This is where most commerce threat models are incomplete.

4. It includes the operator and the insider, not just the external attacker.

The threats usually missed

Business logic abuse rather than technical exploitation:

• Discount and promotion abuse — stacking codes, generating codes, using a one-time code many times through concurrent requests. The concurrency case is a genuine race condition with financial consequences and it is rarely tested.
• Inventory manipulation — adding scarce items to carts to deny them to others, or holding reservations to manipulate scarcity signals.
• Price manipulation through client-supplied values. Any price, discount or tax computed client-side and trusted server-side is an obvious flaw that nonetheless recurs, usually through a new endpoint that bypasses the validated path.
• Refund and return abuse, which is a fraud vector that no technical control addresses.
• Card testing — using the checkout to validate stolen card numbers, which is expensive in processor fees and damages the platform's standing with payment networks even though no money is lost to the merchant.

Threats involving the platform's own operators: support staff with the ability to modify orders, apply credits or view payment details. This needs segregation of duties and audit rather than access control alone.

Threats to availability as a business attack — deliberately exhausting inventory reservation capacity, or driving up costs.

The structure that finds these

Walk the flow as an adversary with a goal rather than a technique: get the item free, get it before others, get someone else's data, make it unavailable to others, make the merchant lose money. Goal-oriented analysis finds business logic abuse that a technique-oriented checklist misses entirely.

Then, for each threat: is it prevented, detected, or accepted — and if detected, by what, and who acts on it? A threat with no detection and no prevention is an accepted risk whether or not anyone accepted it.