Skip to main content

Outcome

A positive EUR payment you received directly from a debtor is reported against the intended claim or mandate. You can reconcile your report through the top-level read-only payment collection. Payments received by paywise are reflected in the mandate’s balance, published status updates, and statements. See Payments for how to follow those receipts.

Prerequisites

  • A Bearer key with case:payments:write (listing a claim’s payments needs case:payments:read); the default * grant includes both.
  • The exact claim UUID before acceptance, or the exact mandate or subcase UUID after acceptance. Keep the claim UUID even if review changes its order.
  • A non-future value_date, positive decimal amount, and stable external your_reference.
  • A stable idempotency key per payment-report command.

Lifecycle context

During order creation and submission, use claim payments to record partial payments (Teilzahlungen) you received before handing the case over to paywise. Include them inline when creating the claim or add them to the draft through the claim-scoped endpoint below. See Partial payments before handover for how to preserve the original invoice amount and record receipts separately. Before acceptance, report against the claim. While the order is draft, submitted, or awaiting_client_response, the payment is recorded on that claim, reduces its total, and is visible to the review team; it is deletable only while the order is still draft. After acceptance, report against the exact mandate or subcase. The accepted-claim route remains supported for compatibility: it delegates to accepted-case reporting, preserves exact claim attribution, and returns 201. A rejected or cancelled claim, or a mandate whose processing has ended, returns 409 conflict. Payment reported below an accepted claim, mandate, or subcase is immediately immutable. Top-level payments are read-only and there is no reversal or negative-payment operation. While the order is still draft, a payment that would exceed the claim’s open value is rejected with 400 overpayment; on an accepted case overpayment is accepted and reconciled by paywise. See Payments for the duplicate guards on both routes.

1. Choose exactly one target

Generate one per-command business reference and body before choosing a target branch:
For a claim before acceptance (or the supported accepted-claim compatibility route):
For an accepted mandate or subcase, use the same body on that target with its one stable logical command key:
Execute one target branch, not both. The URL supplies the target; never send claim or mandate IDs in the body. Retain the generated PAYMENT_REFERENCE, target kind, target ID, body, and command key together until the outcome is known. You can add payment-specific metadata to either creation body, for example [{"type": "transaction:reference", "value": "BANK-TX-0042"}]. Include it in the persisted body and keep it identical on same-key retries. The payment read returns this context; existing v1 reports expose their stored metadata without being reported again. See Payment metadata.

2. Resolve the canonical payment

The 201 body is the payment read resource, including its id and a Location header — store that id directly. Use the collection lookup below only to recover when the response was lost (timeout, crash) before the id was persisted: filter by the selected claim or mandate and the generated reference, then follow every exact next URL before selecting a match:
The runnable workflow below follows each opaque next URL, validates every candidate’s exact target shape, and then switches to the server id for all later reads or deletion. It accepts only relative or absolute pagination links on the exact API HTTPS origin and stops after 50 pages.

3. Delete a mistaken draft payment only

If the order is still draft, the claim-scoped payment may be deleted:
Success is 204 with no body. After finalization, deletion returns 409. Mandate payments are never deletable through the API.

Representative response

This is a complete response matching the PaginatedPaymentReadList schema.

Runnable Python workflow

Python workflow

Failure and recovery

  • 400: reject zero, negative, non-EUR, malformed, or future-dated input; correct it before starting a new logical command.
  • 400 overpayment (draft claim only): the payment exceeds the claim’s open value. Check the claim’s total_amount; correct the amount or the claim.
  • 409 duplicate_payment (draft claim) or 409 duplicate_payment_report (accepted case, with existing_payment_id): the same payment was already reported. The 24-hour window covers the one mandate you report against, so the same payment on a main case and on one of its subcases is two separate reports. A repeat with the same your_reference is a duplicate too. Reconcile against the existing payment ID; if you lost the original response, replay that request with its original Idempotency-Key.
  • 409 order_expired: the draft order expired; it accepts no payment report or deletion any more, and the daily cleanup deletes it.
  • 403 permission_denied: the key lacks case:payments:write (or case:payments:read for the list); use a key with the payment permissions.
  • 409 conflict on create: the target is dead — the claim was rejected or cancelled, or the mandate is closed. A mandate whose state.processing.code is ended, canceled_by_client, or canceled_by_service_provider, or whose archived flag is true, answers Cannot report a payment on a closed mandate. Do not retry against another target; queue the payment for manual reconciliation. 409 on delete: the order finalized while the command was in flight; the payment stands. Do not attempt a negative compensating payment.
  • Timeout, 500, or 503: repeat the same target, body, and idempotency key.
  • 429: wait for Retry-After, then retry with the same key.
  • Duplicate webhook or replayed command: upsert by server payment id. The generated reference, target, amount, and date help reconcile one ambiguous retry outcome, but are not a uniqueness key. If multiple server IDs share a business tuple, preserve every ID and investigate; never collapse them.
For an incorrect immutable payment, retain the payment ID and request ID and contact paywise support; payment reversal is outside the contract.

Verify

Also confirm exactly one of claim and mandate identifies the intended target.