Skip to main content

Payment lifecycle

Two journeys, from the caller's perspective: the immediate payment flow (validate → initiate) and the scheduled payment flow (create → list → cancel). How to call each step is in endpoints → payments.

Payees (create → read → delete) have no lifecycle state machine — a payee exists or it does not. See endpoints → payees.

Journey 1 — immediate payment (validate → initiate)​

Key invariants:

  • Both requests must carry the same debtor account id (paymentInformation[0].debtorAccount.identification.other.identification). That is how the platform pins both calls to the same backing provider, so any pre-flight state from validate applies to initiate.
  • Validate persists nothing — it is a pure pre-flight check.
  • The platform does not require validate to precede initiate; you may initiate directly, and the request is rejected downstream if the pre-flight is mandatory for that payment type.
  • After initiate succeeds, follow-up reads of the payment are consistent, and a duplicate initiate (idempotent retry) is handled gracefully.

Journey 2 — scheduled payment (create → list → cancel)​

State​

The platform holds no scheduled-payment state of its own; the states above are what you observe across the create / list / cancel calls.

Sequence​

Key constraints:

  • Scheduled payments are created through POST /v1/payments (the standard initiate route) with a future requestedExecutionDate — there is no separate create route.
  • Cancel requires a prior list. DELETE /v1/parties/scheduled/{id} only works after the scheduled payment has been returned by GET /v1/parties/scheduled (in this session or an earlier one); cancelling one that was never listed fails with 404 PAR004007. The fix is to list first.
  • Execution on the due date is transparent — there is no platform-side event or status change when a scheduled payment runs.