Member Status

Emitted when a member is successfully registered or their merchant-level suspension status changes.

Event Types

Event	When Emitted
`member.created`	Member record created successfully
`member.suspended`	Merchant-level suspension state changed; suspension and restoration share this event

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

member.created Member record created successfully

When Emitted

Emitted when POST /v1/members actually creates a member row and returns 201. An idempotent hit, where the same external_member_id already exists and the response is 200, does not emit it; otherwise every registration retry would generate another “new member” notification. ⚠ status_version is always 0: member rows have no state-machine version. This event is emitted once per member, so there is no second occurrence to arrive out of order.

Payload

{
  "event_id": "evt_2f1c8a9b4d7e4c1fa0b3e5d6c7a8b901",
  "event_type": "member.created",
  "created_at": "2026-08-12T09:30:00Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "member",
    "id": "4b7c1e02-9a3d-4f18-8c55-2d61ab0f9e77",
    "external_member_id": "u_88123",
    "status": "normal",
    "status_version": 0
  }
}

member.suspended Merchant-level suspension state changed; suspension and restoration share this event

When Emitted

Emitted after POST /v1/members/{id}/suspend actually changes merchant_status. Restoration emits the same event, with status: normal; status identifies the direction. A separate restoration event would require examining two event streams to answer whether the member can currently use the service. This flag only controls availability for the member under your merchant. Platform-level blocking is separate and not visible to you. ⚠ status_version is always 0, and this event can recur: suspend → restore → suspend again. This is therefore the one place among these events where ordering by created_at is genuinely necessary. Do not skip equal versions, or the restoration event will be discarded and the member will remain blocked on your side.

Payload

{
  "event_id": "evt_7c93a1d05e6b4a2f9d81c4e0f2a37b56",
  "event_type": "member.suspended",
  "created_at": "2026-08-12T10:02:11Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "member",
    "id": "4b7c1e02-9a3d-4f18-8c55-2d61ab0f9e77",
    "external_member_id": "u_88123",
    "status": "suspended",
    "status_version": 0
  }
}

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.