Remittance Order Status

Emitted when a remittance reaches a terminal state: completed, failed or refunded.

Event Types

Event	When Emitted
`remittance.order.completed`	Remittance received by the payee
`remittance.order.failed`	Remittance unsuccessful; all locked funds returned
`remittance.order.refunded`	Remittance returned by the receiving bank after completion; funds returned to the member balance

Delivery Contract

We send a POST request with application/json to your configured endpoint, with a 10-second timeout.
Any 2xx response acknowledges receipt. Non-2xx responses and timeouts trigger retries with backoff.
Four request headers: content-type · z-signature · z-event-id · z-event-type。
Deduplicate by z-event-id — the same event may be delivered more than once.

Event payloads contain only IDs and status

There are no amounts, asset codes, card number fragments or risk-control reasons. This is a security boundary: the webhook endpoint is your service, whose transport and storage we cannot guarantee. The GET /v1/<resource>/{id} endpoint applies API key, scope and on-behalf-of checks. Fetch details using data.id; do not use webhook payloads as the source of amounts for your ledger.

Event Details

remittance.order.completed Remittance received by the payee

When Emitted

Emitted when the upstream reports that the payout is complete and our settlement journal posts. This is a terminal state.

Payload

{
  "event_id": "evt_3ad9165e7b0c4f82a91d64c05e73b8f1",
  "event_type": "remittance.order.completed",
  "created_at": "2026-08-12T14:20:08Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "remittance",
    "id": "1c0e8a37-45bd-4f6a-b2e1-90a7d3f5c862",
    "external_member_id": "u_88123",
    "status": "completed",
    "status_version": 6
  }
}

remittance.order.failed Remittance unsuccessful; all locked funds returned

When Emitted

An upstream payment rejection, compliance rejection, or payee-creation failure prevents the order from proceeding. The money has already returned to the member’s available balance. Make this explicit in support messages; saying only “failed” immediately prompts the question of where the money is.

Payload

{
  "event_id": "evt_86f4c1097d2b4e35a8c0136be59d7f20",
  "event_type": "remittance.order.failed",
  "created_at": "2026-08-12T14:31:44Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "remittance",
    "id": "1c0e8a37-45bd-4f6a-b2e1-90a7d3f5c862",
    "external_member_id": "u_88123",
    "status": "failed",
    "status_version": 5
  }
}

remittance.order.refunded Remittance returned by the receiving bank after completion; funds returned to the member balance

When Emitted

Deliberately separate from failed: this order previously emitted completed, and your user saw “received”. Collapsing it into failed would suggest that the earlier confirmation was incorrect.

Payload

{
  "event_id": "evt_e29a704c6b3d418f95720ad3c8f16b54",
  "event_type": "remittance.order.refunded",
  "created_at": "2026-08-13T09:02:31Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "remittance",
    "id": "1c0e8a37-45bd-4f6a-b2e1-90a7d3f5c862",
    "external_member_id": "u_88123",
    "status": "refunded",
    "status_version": 8
  }
}

Signature Verification

The signature verification procedure is the same for all events. See Webhook Overview; use the Signature Debugger to compare signing strings character by character.