Every shop that has run for more than a month has seen it. One customer, one intention, two orders. The picking list says two, the customer says one, and whoever is standing between them has to decide which is true.
It is almost never the customer being careless. A payment page that takes eight seconds on a bad connection looks broken. People do the sensible thing with anything that looks broken: they try again.
The request is not the event
The mistake underneath a duplicate order is treating the arrival of a request as the thing that happened. It is not. The thing that happened is a customer deciding to buy. The request is one attempt to tell you about it, and attempts can repeat.
So the order needs an identity before it is sent, not after it is received. The checkout page carries a key that belongs to that attempt at buying — generated once, when the basket is turned into an order, and sent with every submission of it. The second request arrives carrying the same key, the server recognises it, and returns the result of the first one instead of doing the work again.
The customer sees a confirmation either way. They never learn there was a problem, which is the point.
The same rule, one level down
Payment gateways send the same webhook more than once on purpose. That is not a defect: it is how they guarantee delivery when your server was briefly unreachable. If a payment webhook marks an order paid by adding to a total, a retry adds twice. If it marks the order paid by recording this particular payment reference, a retry changes nothing, because the reference is already there.
The pattern is the same in both places. Do not ask “have I seen this request?” Ask “do I already know about this event?” One is about the network, which you do not control. The other is about your own records, which you do.
What it costs
Not much, if it is decided early. A key on the order, a unique index behind it, and a rule that says a webhook writes a row rather than incrementing a number.
Retrofitting it after the shop is live is a different job — reconciling the duplicates that already exist usually takes longer than the code. That is why it belongs in the first version, even though on the first day, with no traffic, it looks like solving a problem nobody has.