Chapter 3: Threat Modeling on Paper

3.4 A payment gateway on paper

By Ravindra Bagale · Last updated: 3 October 2026

Draw four parts. No more, for this lesson.

1. External entity: the mobile app user. A person outside your system, holding a phone.
2. Process: the payment API. The box that decides what to do with a payment request.
3. Data store: a Postgres database of balances. The memory of who has what.
4. Data flow: the request travels over HTTPS from the phone to the payment API.

Read the picture in order.

1. The user starts on the phone, outside the API.
2. The phone sends a payment request.
3. The arrow is HTTPS. That means the lesson expects encryption in transit. A team that allows a plain, unprotected request has already dropped a fix.
4. The payment API is the only process in this small picture.
5. The API reads and writes balances in Postgres.
6. The database is a data store, not a person. It does not "decide." The API decides.

What is deliberately missing: card-network internals, bank cores, and admin tools. Scope from PASTA step 2 says we do not pretend those boxes are ours today. You can write "neighbor" in the margin and leave them undrawn.

Suppose we are looking at an Indian payment API. The user owes Rs 5000. The phone should ask the API to collect that order's amount. The API should look up the order in its own data, not accept a random total from the device. The database stores balances. It should change only after the API has agreed the amount.

A tiny number on the picture, still a teaching example: the order total is 5000. A wrong body says 1. Those two integers are the whole drama. 5000 − 1 = 4999. That gap is the money the merchant would lose if the server believed the phone. You do not need a larger formula.