Source: https://docs.debitura.com/collection-partners/integration-guides/correct-or-remove-payments
# 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](https://docs.debitura.com/collection-partners/integration-guides/record-payments.md) 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](https://docs.debitura.com/collection-partners/integration-guides/correct-or-remove-payments.md#reopening-a-closed-case), and an [invoiced payment is frozen](https://docs.debitura.com/collection-partners/integration-guides/correct-or-remove-payments.md#invoiced-payments-are-frozen).
## Find the payment
Edit and delete are keyed by payment ID. List a case's payments with [`GET /cases/{id}/payments`](https://docs.debitura.com/api/collection-partner-api/cases.md#fetch-case-payments) and pick the one to correct by its `id`, `grossAmount`, 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}`](https://docs.debitura.com/api/collection-partner-api/cases.md#edit-a-payment-on-a-case) with the corrected `paymentAmount` and payout split. The request mirrors the payout-split semantics of [recording a payment](https://docs.debitura.com/collection-partners/integration-guides/record-payments.md) — payouts must sum to the new amount within rounding tolerance.
## Remove a payment
Send [`DELETE /cases/{id}/payments/{paymentId}`](https://docs.debitura.com/api/collection-partner-api/cases.md#delete-a-payment-on-a-case). 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. The reopen step applies **only** to a case closed as `Paid`: a fully-paid case has a zero remainder, so lowering or removing one of its payments newly leaves money outstanding and the case has to go back to `Active`. Cases closed in any other state — for example `PartiallyPaid`, `GivenUp`, `Disputed`, or `DebtorInsolventBankrupt` — already carry a positive remainder by design, so editing or deleting a payment on them never triggers the reopen step or the `409`. When an edit or delete pushes the outstanding balance above zero on a `Paid` case, 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`](https://docs.debitura.com/collection-partners/integration-guides/webhooks.md) webhook, and applies the correction. The reopen and the balance change are one atomic unit: the webhook is only ever sent once both have durably saved, so you will never receive a `case.updated` event for a correction that did not actually take effect.
Deleting a payment fires a [`payment.deleted`](https://docs.debitura.com/collection-partners/integration-guides/webhooks.md#paymentdeleted) webhook to your agency — with the same payload shape as `payment.created` — so you can react to a reversal directly instead of polling or diffing balances. There is still no `payment.updated` webhook: an edit does not publish an event of its own, so to detect an edit-driven reversal, subscribe to [`case.updated`](https://docs.debitura.com/collection-partners/integration-guides/webhooks.md) (fired only when the edit also reopens a closed case) or compare the new balance against your stored value.
**Business context:** See [Case status definitions and allowed actions](https://support.debitura.com/en/articles/13910011-collection-partners-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`](https://docs.debitura.com/collection-partners/integration-guides/webhooks.md) webhook to keep your system in sync. To rehearse the correct-and-reopen flow without touching live data, drive a [test case](https://docs.debitura.com/developer-concepts/test-cases.md) to `Closed:Paid` and apply the same edit and delete calls.