Card Issuance › Webhook

Card Issuance Results

Emitted when issuance succeeds, execution fails, the cardholder is approved or a physical card becomes ready to bind. Cardholder approval or readiness to bind does not mean the card is ready to use.

Event Types

Event	When Emitted
`card.application.approved`	Card issued successfully and available for use
`card.application.rejected`	Card application execution failed
`card.application.submitted`	Review status synchronized for an associated cardholder
`card.application.awaiting_bind`	Physical card ready to bind

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

card.application.approved Card issued successfully and available for use

When Emitted

Emitted after the issuer successfully issues the card and the card record is stored. data.id is the public card application ID, already prefixed with cap_; retrieve it through GET /v1/cards/applications/{data.id}. To retrieve the card itself, use GET /v1/cards with x-on-behalf-of: <external_member_id>. ⚠ Before 2026-08-13 this event contained the internal member ID, despite data.object being card_application; retrieval inevitably returned 404. This is fixed. Follow the convention above. Execution failure or cardholder rejection that fails the application emits card.application.rejected.

Payload

{
  "event_id": "evt_2e6c98a04f1b47d3850ac7e195b3d602",
  "event_type": "card.application.approved",
  "created_at": "2026-08-12T16:03:27Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "card_application",
    "id": "cap_9c41f0a8-27d5-4e63-b0a9-1f7c85d2e340",
    "external_member_id": "u_88123",
    "status": "approved",
    "status_version": 5
  }
}

card.application.rejected Card application execution failed

When Emitted

Triggered after execution failure or an explicit cardholder rejection causes the application to become failed. It does not depend on the member’s email address; repeated execution is deduplicated by application ID and status version. The notification status is rejected, while the application detail status is failed. Raw upstream reasons are not published. Retrieve failure_code from the details to determine how to handle the failure.

Payload

{
  "event_id": "evt_491ad542803841bca106f69ae28a3c14",
  "event_type": "card.application.rejected",
  "created_at": "2026-09-15T08:00:00Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "card_application",
    "id": "cap_9c41f0a8-27d5-4e63-b0a9-1f7c85d2e340",
    "external_member_id": "u_88123",
    "status": "rejected",
    "status_version": 4
  }
}

card.application.submitted Review status synchronized for an associated cardholder

When Emitted

When a channel supporting cardholder retrieval confirms approval, associated applications still in fulfillment are notified. data.status is the application’s actual progress, and cardholder_review_status is approved. This is not a successful card issuance event; do not resubmit the application or display the card as available because of it. Retrieve GET /v1/cards/applications/{data.id} after receiving it.

Payload

{
  "event_id": "evt_d9f5b7057f6a40d99f05d7631255b888",
  "event_type": "card.application.submitted",
  "created_at": "2026-09-15T08:00:00Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "card_application",
    "id": "cap_9c41f0a8-27d5-4e63-b0a9-1f7c85d2e340",
    "external_member_id": "u_88123",
    "status": "picking",
    "status_version": 3,
    "cardholder_review_status": "approved"
  }
}

card.application.awaiting_bind Physical card ready to bind

When Emitted

Emitted after the physical card reaches the user and the application enters awaiting_bind. Standard applications under downstream inventory mode automatically move to this state through an in-person handover after approval and entry into the fulfillment queue. Platform-direct fulfillment requires confirmation of an offline handover or a shipment marked as received by the user. data.id is the public card application ID, already prefixed with cap_. Retrieve GET /v1/cards/applications/{data.id}, then call POST /v1/cards/bind → POST /v1/cards/{id}/activate. This does not mean issuance is complete: the card is not activated, so do not present it as available. Neither shipped alone, while the card is in transit, nor pending_activation after binding emits this event. Successful activation still uses card.application.approved and card.status.updated. ⚠ Not emitted for platform-direct members.

Payload

{
  "event_id": "evt_b7c1e02a9d3f4e18ac552d61ab0f9e77",
  "event_type": "card.application.awaiting_bind",
  "created_at": "2026-09-21T06:37:35Z",
  "merchant_id": "acme",
  "livemode": true,
  "data": {
    "object": "card_application",
    "id": "cap_9c41f0a8-27d5-4e63-b0a9-1f7c85d2e340",
    "external_member_id": "u_88123",
    "status": "awaiting_bind",
    "status_version": 5
  }
}

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.