Event catalog
Every event type you can subscribe to, and what triggers it.
Each event type is separate, so you can choose to subscribe to only the events you want. The name in the first column appears in the webhook portal and in the payload's event.type field.
Full payload schemas for every event are in the API reference under Webhook events.
Transaction and token events are delivered on both delivery methods, legacy and Svix. Merchant lifecycle events are delivered on Svix webhooks only, and Svix is invite only - see Webhooks.
Transaction events
| Event type | Triggered when |
|---|---|
sale.completed |
A financial transaction is processed and completed. |
auth.completed |
A transaction authorization is completed. |
capture.completed |
A transaction capture for a previously authorized transaction is completed. |
refund.completed |
A transaction void or refund for a previously completed transaction is completed. |
void.completed |
A transaction void for a previously completed transaction is completed. |
chargeback.completed |
The payer's bank returned an ACH payment after the funds reached the merchant. The payload is a new Chargeback transaction; see Chargebacks. |
sale.completed fires for declines as well as approvals - "completed" describes the processing of the request, not the approval of the payment. Read resultCode and the transactionResponses entries to determine the outcome. A 3D Secure failure also produces a declined transaction and fires this event.
For ACH, sale.completed carries the bank outcome. Its originalResponse.status is Completed for both approval and decline; inspect originalResponse.transactionResponses[].responseCode. An ACH resubmission sends its own sale.completed for a new Sale transaction, linked to the first sale by originalResponse.originalTransactionId.
chargeback.completed is a separate event type. An endpoint receives it only when it subscribes to it: add it to a Svix endpoint that is filtered to specific event types, and ask support to add it to a legacy endpoint.
A hosted payment form or Payment SDK payment that the customer canceled can still reach the gateway. When the gateway reports the payment later, the same trx_ transaction changes from the canceled record to the real outcome, and sale.completed or auth.completed is sent then, with token.created if the session stored a new token. The cancel itself sends no webhook, so the event can arrive after your return URL or callback reported a cancellation. Trust the webhook.
Because a refund automatically voids a transaction still in the current batch, a refund request can result in a void.completed event rather than refund.completed. Subscribe to both.
Token events
| Event type | Triggered when |
|---|---|
token.created |
A card or bank account is tokenized and stored as a payment method. |
token.removed |
A previously tokenized card is removed from the system. |
See Tokenization.
Merchant lifecycle events
Merchant onboarding lifecycle events cover merchant application progress, merchant approval decisions, and pricing template review decisions.
Beta. Merchant lifecycle events are in beta: the set of events and the payload can still change, and breaking changes are announced with a deprecation period. They are delivered on Svix webhooks only, which are invite only. They are not available on legacy webhooks.
| Event type | Triggered when |
|---|---|
merchant.application.started |
A merchant begins filling out their onboarding application. |
merchant.application.submitted |
A merchant submits their onboarding application for review. |
merchant.application.status_changed |
A merchant application moves between review stages (for example into Underwriting or Onboarding). |
merchant.application.requires_action |
A merchant application needs more information or documents from the merchant before review can continue. |
merchant.application.info_uploaded |
A merchant provides the requested information or documents on an application that required action. |
merchant.approved |
A merchant application is approved and the merchant account is created. |
merchant.rejected |
A merchant application is rejected during review. |
pricing_template.approved |
A submitted pricing template is approved from review and its onboarding links become active. |
pricing_template.rejected |
A submitted pricing template is declined during review. |
One shared payload shape
All merchant lifecycle events share one payload shape:
- An
eventenvelope - id, type, timestamp, and the related merchant id once one exists - A
datasection with the application, status transition, and pricing template details that apply to the event type
Fields that do not apply to a given event type are null, so write your handler against the envelope's type rather than against the presence of a field.
Merchant lifecycle payloads are PII-safe by design - they never carry underwriting documents, bank details, or tax identifiers. If you need that data, fetch it through an authenticated API call rather than expecting it in the event.
Related
- Configuring endpoints on legacy webhooks, or in the webhook portal on Svix - choosing which of these each endpoint receives
- Verifying the checksum on legacy webhooks, or Verifying signatures on Svix