Reverse a payment
Why there is no reverse-payment command—posted payments unwind through the provider-driven return flow, and ledger corrections use specific governed commands.
There is no reversePayment command, and no staff-facing route that deletes or negates a posted payment. A posted payment reverses in exactly one way: the payment provider reports a return—an ACH return or card chargeback—and the payment return flow unwinds the posting. Everything else is a forward-posting correction through a specific governed command.
Why the command does not exist
A posted payment is settled money with a posted allocation. Letting an operator “reverse” it directly would fabricate a money movement the rails never saw, and the ledger would immediately disagree with the bank. The platform therefore splits the problem:
- The money genuinely came back → the provider return flow records it.
- The money stayed but the ledger effect is wrong → a governed adjustment or credit command corrects it.
Provider-driven returns
When a settled debit returns, the provider event moves the payment to RETURNED and the posting is unwound as a linked reversal—never a negative new payment. Return-code policy then decides the consequences: whether retry is allowed (a new intent linked by retryRootPaymentId), whether the instrument is invalidated, and how autopay reacts. An unfamiliar return code fails closed to review.
Suppose a $517.14 Harbor debit is returned for insufficient funds. The original payment and its receipt remain visible; the reversal restores the allocation components under the loan’s replay rules; delinquency recalculates from authoritative posted history. Nothing about that flow is operator-initiated—staff cannot call a return into existence, and a customer conversation (“I dispute that payment”) routes to the provider dispute process, not to an API mutation.
Correcting the ledger without a return
When money did not come back but the books are wrong, use the specific command whose economic meaning matches:
| Situation | Correct mechanism |
|---|---|
An externally recorded payment (record-external) was posted in error |
Raise it in reconciliation; the correction posts under a recon exception, not a payment mutation. |
| A fee that was paid must be returned | chargeRefund posts the credit. |
| The borrower overpaid and holds a credit balance | creditBalanceRefund with a REFUND funding. |
| The lender owes value for a service failure | goodwillCredit. |
| Money arrives on a charged-off loan | recoverypayment—not a repayment, not a reversal. |
Each command carries its own permission, writes a governance record, requires LendEasy-Case on human calls when case management is enabled, and can be parked by maker-checker. None of them edits the original payment.
A payment that has not posted yet
A payment still in flight is not reversed—it either completes or fails on its own lifecycle. There is no public cancel route; intervene through the case so the outcome is recorded, and let the status machine finish. Only the posted result is ever corrected, and only through the paths above.
What stays visible
However the correction happens, the original payment, its receipt, and its timeline remain readable. A return shows RETURNED with the provider reference; a correction shows its own governed transaction linked through the case. Reporting distinguishes money that bounced from books that were fixed—that distinction is the point.