X-Grid-Signature) and
retry behavior are identical to the rest of Grid — see
Authentication and
Webhooks for the underlying mechanics.
Card-transaction lifecycle events are not card-specific webhooks —
they ride on the generic transaction webhook stream (a follow-up
extends the Transaction model with a card destination type).
Event types
All card webhooks carry the standard envelope:
id is unique per delivery and safe to use for idempotency.
CARD.STATE_CHANGE
Thedata payload is the post-change Card resource. Example —
activation after issuance:
state: "ACTIVE"afterPROCESSING— the card is live. To reveal the full card details, request a reveal withPOST /cards/{id}/revealright before rendering its short-livedpanEmbedUrlin an iframe — webhook payloads never carry a reveal URL.state: "CLOSED",stateReason: "ISSUER_REJECTED"— the issuer rejected provisioning; offer to issue a new card.state: "FROZEN"/state: "ACTIVE"— reflect the freeze toggle in your UI.state: "CLOSED",stateReason: "CLOSED_BY_PLATFORM"— close confirmed; stop showing the card.
CARD.FUNDING_SOURCE_CHANGE
Fires whenever aPATCH /cards/{id} call changes the fundingSources
array. The data payload is the full Card resource with the
post-change fundingSources, so a consumer that only cares about the
current set of bindings can replace state wholesale.
CARD_TRANSACTION.*
Card-transaction lifecycle events fire on every state transition of aCardTransaction. The data payload is the full CardTransaction
resource after the transition.
See Reconciliation for the
underlying event model and the over-auth and exception paths.
Idempotency & retries
Webhook deliveries are at-least-once. Track processedid values and
return 200 on duplicates, or return 409 and let Grid stop
retrying. Both shapes are accepted by Grid’s webhook infrastructure.