Anti-duplicate payments: protection in two layers

In PDP, we ran into a classic production edge case: the user clicked pay twice, the bank didn’t respond right away, and the system was already getting nervous. To avoid ending up with “oops, we have two deals for one unit,” we added two levels of protection.

The first layer is business logic in the application: we check that there isn’t already an active deal for the unit. The second is a database-level constraint that physically prevents overlapping bookings from being created. So even if a race condition happens somewhere, the database says: not today.

The hard rule is simple: one unit — one active deal.

And yes, as always, reality is more complicated than the diagram: sometimes the bank considers the payment successful, while our system does not. For these cases, we introduced the paid with error status so we don’t lose money and can reconcile discrepancies without manual magic at 2 a.m.

Reliability is no longer a feature; it’s a must-have.