Correct or Remove Payments

Fix a payment you reported with the wrong amount, or reverse one that should not have been recorded.

Overview

Debitura has no negative-payment or separate "storno" entry. You correct a recorded payment by editing it in place or deleting it:

• Edit — adjust the amount and payout split. Debitura reverses the original entry and re-applies it at the corrected values.
• Delete — reverse the payment entirely. The case balance is restored, the linked payout is cascade-deleted, and a durable audit record of the deletion is retained.

Both operations recompute the case's outstanding balance. Two Debitura-specific rules govern when they are allowed: a closed case may need reopening, and an invoiced payment is frozen.

Find the payment

Edit and delete are keyed by payment ID. List a case's payments with GET /cases/{id}/payments and pick the one to correct by its id, amount, and date.

There are no server-side filters for amount or date — the endpoint returns every payment on the case. Filter the list in your own code.

Edit a payment

Send PUT /cases/{id}/payments/{paymentId} with the corrected amount and payout split. The request mirrors the payout-split semantics of recording a payment — payouts must sum to the new amount within rounding tolerance.

Remove a payment

Send DELETE /cases/{id}/payments/{paymentId}. This adds the payment amount back to the outstanding balance and deletes the associated payout. The deletion itself is recorded as a permanent audit event, so the reversal stays traceable after the fact.

Reopening a closed case

A case is never reopened automatically from its balance. When an edit or delete pushes the outstanding balance above zero on a case that was closed as Paid, the case must be explicitly reopened — and Debitura requires your consent first:

1. The request returns 409 Conflict if it would reopen the case and you have not opted in.
2. Resend with consent. The flag binds differently per verb: on edit (PUT) set reopenCaseIfNeeded: true in the request body; on delete (DELETE) pass it as a query parameter — ?reopenCaseIfNeeded=true. Debitura reopens the case to Active, fires a case.updated webhook, and applies the correction.

There are no payment.updated or payment.deleted webhooks. To detect a reversal downstream, subscribe to case.updated and compare the new balance against your stored value.

Business context: See Case status definitions and allowed actions for what each lifecycle state means.

Invoiced payments are frozen

Once a payment's payout has been invoiced, the numbers are locked in Debitura's accounting and external billing systems. Editing or deleting such a payment returns 422 Unprocessable Entity. Correcting an invoiced payment requires a credit note rather than an in-place change — contact Debitura to handle it.

Error Handling

Status	Meaning	What to do
409 Conflict	The correction would reopen a Paid case and reopenCaseIfNeeded was not set.	Resend with consent — reopenCaseIfNeeded in the body on edit, or ?reopenCaseIfNeeded=true in the query string on delete.
422 Unprocessable Entity	The payment's payout is already invoiced and is frozen.	Use the credit-note path; contact Debitura.

What's Next

When a correction reopens a case, consume the case.updated webhook to keep your system in sync. To rehearse the correct-and-reopen flow without touching live data, drive a test case to Closed:Paid and apply the same edit and delete calls.