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 needscase: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 externalyour_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 isdraft,
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: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
The201 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:
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 stilldraft, the claim-scoped payment may be deleted:
204 with no body. After finalization, deletion returns 409.
Mandate payments are never deletable through the API.
Representative response
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’stotal_amount; correct the amount or the claim.409 duplicate_payment(draft claim) or409 duplicate_payment_report(accepted case, withexisting_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 sameyour_referenceis a duplicate too. Reconcile against the existing payment ID; if you lost the original response, replay that request with its originalIdempotency-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 lackscase:payments:write(orcase:payments:readfor the list); use a key with the payment permissions.409 conflicton create: the target is dead — the claim was rejected or cancelled, or the mandate is closed. A mandate whosestate.processing.codeisended,canceled_by_client, orcanceled_by_service_provider, or whosearchivedflag istrue, answersCannot report a payment on a closed mandate.Do not retry against another target; queue the payment for manual reconciliation.409on delete: the order finalized while the command was in flight; the payment stands. Do not attempt a negative compensating payment.- Timeout,
500, or503: repeat the same target, body, and idempotency key. 429: wait forRetry-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.
Verify
claim and mandate identifies the intended
target.
