A threat model for a payments API, in an afternoon

6 October 2026 · 6 min read

A threat model is not a document. It is a list of the things that would hurt most, written before anyone tests anything.

Every testing engagement starts with a threat model, and most of them take an afternoon. The point is not ceremony. The point is to decide where the testing time goes before the clock starts, because two weeks of testing spread evenly across an API finds less than two weeks aimed at the five places that matter.

Draw what exists

One diagram, on a whiteboard or in a text file: the clients, the API, the services behind it, the database, the payment provider, the queues, the admin tools. Every arrow is data moving and every arrow gets a label: what moves, who is allowed to move it, how that is enforced. If nobody in the room can say how an arrow is authorised, that arrow is already a finding.

Ask where the value sits

Money: anything that creates, changes or refunds a payment, and anything that decides an amount.
Identity: tokens, sessions, password reset, the admin login, the service-to-service credentials.
Personal data: names, phone numbers, addresses, cards even when tokenised. Under the DPDP Act this is where the reporting duties live.
Trust: webhooks from the provider, callbacks, anything that says "the payment succeeded" and is believed.

Think like three attackers

An outsider with no account, a customer with one, and an insider or a compromised service with a key. For each, we walk the diagram and ask what they want and what is in the way. The customer-with-an-account is the one teams underestimate: most of the authorisation bugs we find need nothing more than a login and a changed id.

Rank, then test in that order

List the attacks that would hurt most, in one line each: "a customer reads another customer’s order", "a replayed webhook marks an unpaid order as paid".
Mark the ones the design already prevents, and how. Those still get a quick check.
Everything else is the test plan, top first. The report later refers back to this list, so you can see what was covered and what was not.