Skip to main content
This quickstart is designed for the sandbox and uses a direct Case key. The Python examples use https://api-sandbox.paywise.de directly; replace the inline PAYWISE_API_KEY placeholder with a sandbox key (pw_sbx_…) created in the developer portal. Other language tabs read the matching environment variables. A Partner key must add X-On-Behalf-Of-Company: <company-uuid> to every Case request instead. Use the documented trailing slash on /v2/ roots and resource routes. Slashless requests such as /v2/info return JSON 404 for every method, including GET, HEAD, OPTIONS, and writes, with no redirect or Location header. Request /v2/info/ directly. See canonical URLs. The request tabs below are complete, copyable examples for individual operations. The final section runs the whole flow end to end once in Python. This shortest path uses the default invoice order type. For subtype-specific data and validation, follow Submit a rental order or Submit a titled order.

1. Create the debtor record

Use a fresh DEBTOR_REFERENCE and DEBTOR_COMMAND_ID for a new logical write. Keep the same body and idempotency key when retrying an ambiguous result.
The create response returns the debtor’s id directly. Every language tab above parses and retains that exact UUID; reuse it as DEBTOR_ID in step 2:
If you lose the id, GET /v2/debtors/?your_reference=<reference> finds the debtor again. The reference is not enforced unique and the filter is a case-insensitive substring match, so compare your_reference exactly on the results and treat more than one match as a reconciliation task.

2. Create the order draft

This is a ReceivableClaim in an invoice order, so the claim declares "type": "receivable" (required on every claim). Omitting the order-level type defaults the order to invoice; no rental-agreement or enforceable-title fields belong in this payload. Choose legal_basis.claim_type_code from the complete German code catalog; this example uses H05 for a service contract.
A draft stays fully editable until it is finalized — PATCH /v2/orders/{id}/ corrects any field; omitted fields and arrays stay unchanged.

3. Finalize exactly once

Finalize accepts an empty body or exactly {}; any member is 400 validation_error with unknown_field. The examples send an empty body, so they do not need a Content-Type header.

4. Accept the order in the sandbox

In production, paywise reviews and accepts a submitted order. The sandbox never accepts one on its own, and there is no API call for it: you accept the order in the sandbox portal. From the production portal, follow this path: Für Entwickler → Zur Sandbox → Mandate & Aufträge → Aufträge in Prüfung → open the order finalized in step 3 → open the sandbox drawer (the amber Sandbox-Tools button at the lower right, or Alt+S) → Kontext → Auftrag annehmen → Bestätigen Your first Zur Sandbox entry activates the sandbox automatically. The portal opens the newly created mandate. Later, the same drawer simulates the debtor paying that mandate — Zahlung des Schuldners an paywise, in full or as a partial amount — and every other counterparty step; see the sandbox drawer.

5. Verify acceptance and find the mandate

Acceptance freezes the order’s claim set into exactly one mandate, and the order names it: once status is accepted, the order’s read-only mandate field carries the mandate UUID. The production pattern is push, not poll: subscribe a webhook to order.accepted (see Consume Case webhooks for subscription creation, signature verification, and deduplication). The event payload names both sides of the boundary: the order (order_id, order_url) and the mandate its claims were frozen into (mandate_id, mandate_url). Fetch mandate_url on your configured API host directly; mandate_id equals the accepted order’s mandate field:
order.accepted payload (data)
Webhook delivery is at least once. Match the stored claim UUID against claim_ids, then refetch /v2/claims/{claim_id}/. Trust that response’s current order_id and nullable mandate_id, even when the event’s order_id differs from the order where you originally submitted the claim. Do not follow an order merge chain to locate it. In this quickstart no webhook endpoint is needed: the sandbox simulation in step 4 accepts the order synchronously. Read the order once and take the mandate UUID from the response:
Fetch the mandate by the exact UUID in the order response’s mandate field:

6. Runnable end-to-end workflow

Install requests, replace the inline PAYWISE_API_KEY placeholder, then run this program. The API URL is already set to the Sandbox host. Every id it needs comes straight from a command response. Before writing, it checks HTTPS and confirms the authenticated API reports the sandbox environment. After finalizing the order it pauses: accept the order in the sandbox portal as in step 4, and the program picks the acceptance up on its next poll.
Python workflow
The accepted order names its mandate directly, so no list reconciliation is needed: the program reads mandate from the accepted order, verifies that the fetched mandate holds this run’s exact claim, and never prints credentials. Unexpected order states stop the program for inspection.