The bugs that scare me in a payment system are not the ones that fail: they are the ones that succeed twice.
A unique constraint on a nullable column is the cleanest example I know. In Postgres, NULL is not equal to NULL, so uniqueness quietly stops applying to exactly the rows where the external reference is missing. The schema passes review. The constraint sits right there in the migration. It just does not cover the case it was written for.
Then a retry arrives from a channel that sent no reference that day, and the ledger takes a second credit for the same obligation. Nothing throws. No alert fires, because every component did what it was told. The balance is wrong and the logs look healthy.
A bigger constraint does not fix that. Refusing to write a row without a usable key does. I keep the dedup key non-nullable and derive it deterministically from normalized requisites when the provider hands me nothing. Anything that cannot be normalized goes to an unmatched queue where a human sees it, instead of landing in the ledger with a NULL that silently opts out of every guarantee.
Severity has little to do with the size of a bug. It has everything to do with whether the system can tell it happened. The cheap bugs raise exceptions. The expensive ones produce plausible writes.
I write up more of these constraint-level failure modes here: https://polycratia.com/c/ad3da1d6
Probably worth checking which nullable column in your schema is load-bearing for uniqueness right now...