The repayment endpoint returned an error after the database had already committed. The client retried the request. Both requests carried the same payment, but the system treated the second one as new.
The database was consistent: it contained two valid rows. The workflow was not. A network failure had separated the response from the transaction that produced it.
We added a stable reference to the repayment command and made that reference unique. On a retry, the handler now returns the result of the first transaction instead of recording another payment.
Without that rule, the loan balance, receipt history and accounting entries could disagree even though every insert succeeded. Retries are now part of the payment flow, not an exceptional case around it.