# 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](https://doura.ca/docs/webhooks/legacy.md) and [Svix](https://doura.ca/docs/webhooks/svix.md). Merchant lifecycle events are delivered on Svix webhooks only, and Svix is invite only - see [Webhooks](https://doura.ca/docs/webhooks.md#two-delivery-methods).

## 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](https://doura.ca/docs/payments/ach.md#chargebacks). |

> **Note:**
>
> `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](https://doura.ca/docs/hosted-payment-form/3d-secure.md) failure also produces a declined transaction and fires this event.

For [ACH](https://doura.ca/docs/payments/ach.md), `sale.completed` carries the bank outcome. Its `originalResponse.status` is `Completed` for both approval and decline; inspect `originalResponse.transactionResponses[].responseCode`. An ACH [resubmission](https://doura.ca/docs/payments/ach.md#resubmissions) 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](https://doura.ca/docs/payments/tokenization.md).

## Merchant lifecycle events

Merchant onboarding lifecycle events cover merchant application progress, merchant approval decisions, and pricing template review decisions.

> **Warning:**
>
> **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](https://doura.ca/docs/webhooks/svix.md) 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 `event` envelope - id, type, timestamp, and the related merchant id once one exists
* A `data` section 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.

> **Tip:**
>
> 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](https://doura.ca/docs/webhooks/legacy/configuration.md) on legacy webhooks, or [in the webhook portal](https://doura.ca/docs/webhooks/svix/configuration.md) on Svix - choosing which of these each endpoint receives
* [Verifying the checksum](https://doura.ca/docs/webhooks/legacy/verifying-the-checksum.md) on legacy webhooks, or [Verifying signatures](https://doura.ca/docs/webhooks/svix/verifying-signatures.md) on Svix