> ## Documentation Index
> Fetch the complete documentation index at: https://docs.y.uno/llms.txt
> Use this file to discover all available pages before exploring further.

# Events and Triggers

> The full catalog of events a webhook can subscribe to, organized by domain, and the trigger field that selects each one

A webhook subscribes to events through trigger fields, one per domain, and needs at least one trigger. Set these from the [dashboard](/docs/webhooks/configure-webhooks) or the [Webhooks API](/reference/webhooks). The catalog below is the same either way. Each event's payload is documented in [Payloads and Examples](/docs/webhooks/object-and-examples).

## Enrollment

`enrollment_triggers`

| Trigger | Event | Description |
| :- | :- | :- |
| `ENROLL` | `enrollment.enroll` | Sent when a payment method is successfully enrolled. |
| `UNENROLL` | `enrollment.unenroll` | Sent when an enrolled payment method is unenrolled. |

<Note>
  `enrollment.expiration` exists but isn't currently offered as an option in the dashboard.
</Note>

## Payment

`payment_triggers`

| Trigger | Event | Description |
| :- | :- | :- |
| `AUTHORIZE` | `payment.authorize` | Sent when a payment is authorized. |
| `CANCEL` | `payment.cancel` | Sent when a payment is canceled. |
| `CAPTURE` | `payment.capture` | Sent when a payment is captured. |
| `CHARGEBACK` | `payment.chargeback` | Sent when a chargeback or inquiry is received for a payment. |
| `PURCHASE` | `payment.purchase` | Sent when a payment is created or its status changes during a purchase flow. |
| `REFUND` | `payment.refund` | Sent when a refund is processed for a payment. |
| `VERIFY` | `payment.verify` | Sent when a payment method verification completes. |
| `PRECHARGEBACK` | `payment.pre_chargeback` | Sent when a pre-chargeback notice or fraud alert is received for a payment, ahead of a full chargeback. |

<Note>
  **Fraud screening:** when a transaction is declined by fraud screening and doesn't proceed to processing, no transactions are created. Only the `fraud_screening` object is populated, and Yuno sends `payment.fraud_screening`. If the transaction proceeds to processing despite the decline (per your routing configuration), the event sent is `payment.purchase` instead.
</Note>

<Note>
  `payment.fraud_screening` and `payment.pre_chargeback` are currently sent to any webhook with at least one `payment_triggers` value, regardless of whether `PRECHARGEBACK` is selected. A dedicated trigger gate for `payment.pre_chargeback` is planned for a future release.
</Note>

## Subscription

`subscription_triggers`

| Trigger | Event | Description |
| :- | :- | :- |
| `CREATE` | `subscription.create` | Sent when a subscription is first created. |
| `ACTIVE` | `subscription.active` | Sent once, when the subscription first becomes active. Not re-sent on subsequent renewal cycles. |
| `PAUSE` | `subscription.pause` | Sent when a subscription is paused. |
| `RESUME` | `subscription.resume` | Sent when a paused subscription is resumed. |
| `CANCEL` | `subscription.cancel` | Sent when a subscription is canceled. Once canceled it is terminated and cannot be reactivated. |
| `COMPLETE` | `subscription.complete` | Sent when a subscription reaches its end date or total billing cycles and transitions to `COMPLETED`. |
| `CLOSE_TO_RENEWAL` | `subscription.close_to_renewal` | Sent ahead of an upcoming renewal. Timing is controlled by `renewal_days` when set via the [API](/reference/webhooks#triggers), reflected on the subscription as `renewal_notification_days`. |
| `PLAN_CHANGE_SCHEDULED` | `subscription.plan_change_scheduled` | Sent when a plan change is scheduled for the next billing cycle. |
| `PLAN_CHANGE_CANCELED` | `subscription.plan_change_canceled` | Sent when a pending plan change is undone by the merchant or aborted because the target plan was canceled. Not sent when the subscription itself is canceled — only `subscription.cancel` fires then. |
| `PLAN_CHANGED` | `subscription.plan_changed` | Sent when a plan change takes effect. |

<Note>
  Each renewal charge is delivered as a `payment.purchase` webhook tied to the subscription, with the outcome (success or decline) carried in the `status`/`sub_status` fields. `$0`/trial cycles emit no payment webhook, and there is currently no `subscription.error` event. For plan-based subscriptions, a `$0`/trial cycle is instead reported as `subscription.cycle_executed` (see below).
</Note>

The following subscription events aren't gated by a trigger value of their own; they're sent automatically to any webhook with at least one `subscription_triggers` value.

| Event | Description |
| :- | :- |
| `subscription.trialing` | Sent when a subscription enters a plan's trial phase from another status. Entering the trial at creation time is reported as `subscription.create`, and leaving a pause into the trial as `subscription.resume`. |
| `subscription.past_due` | Sent when a recurring charge fails and the subscription enters `PAST_DUE`. Only emitted for accounts where that status is enabled. See [Subscription Status](/reference/subscriptions/status-subscriptions). |
| `subscription.cycle_executed` | Sent for plan-based subscriptions when a `$0` cycle is executed, either a trial cycle or a fully discounted one. These cycles produce no `payment.purchase` webhook, so this event is the only receipt for them. |
| `subscription.phase_started` | Sent for plan-based subscriptions when a billing phase begins, including the first one. |
| `subscription.phase_completed` | Sent for plan-based subscriptions when a billing phase ends, immediately before the `subscription.phase_started` of the phase that replaces it. Not sent for the first phase, which has no predecessor. |
| `subscription.cancel_scheduled` | Sent when a cancellation is scheduled for a future date or billing cycle via `POST /v1/subscriptions/{id}/cancel` with a `schedule` block. |
| `subscription.cancel_schedule_canceled` | Sent when a pending scheduled cancellation is undone. Not sent when the schedule instead fires — `subscription.cancel` fires then. |

<Note>
  Treat the plan-change events as notifications, not as the source of truth. Reconcile against `GET /v1/subscriptions/{id}` rather than relying on webhook delivery alone. The same applies to the cancel-scheduling events. See [Payloads and Examples](/docs/webhooks/object-and-examples#subscription-plan_change_scheduled) for the full field reference of each.
</Note>

## Onboarding

`onboarding_triggers`

| Trigger | Event | Description |
| :- | :- | :- |
| `CREATED` | `onboarding.create` | Sent when an onboarding is created. |
| `PENDING` | `onboarding.pending` | Sent when an onboarding is submitted and awaiting review. |
| `SUCCEEDED` | `onboarding.succeeded` | Sent when an onboarding is approved. |
| `DECLINED` | `onboarding.declined` | Sent when an onboarding is declined. |
| `ERROR` | `onboarding.error` | Sent when an onboarding errors. |
| `EXPIRED` | `onboarding.expired` | Sent when an onboarding expires. |
| `BLOCKED` | `onboarding.blocked` | Sent when an onboarding is blocked. |
| `UNBLOCKED` | `onboarding.unblocked` | Sent when a blocked onboarding is unblocked. |
| `CANCELLED` | `onboarding.cancelled` | Sent when an onboarding is cancelled. |
| `INACTIVE` | `onboarding.inactive` | Sent when an onboarding becomes inactive. |
| `TRANSFERRED` | `onboarding.transferred` | Sent when an onboarding is transferred. |

<Note>
  The onboarding `FAILED` and `REJECTED` statuses aren't separate events; both are reported as `onboarding.declined`. Likewise, `PENDING_ADDITIONAL_DOCUMENTATION` and `PENDING_RECIPIENT_ACTION` are both reported as `onboarding.pending`, with the specific status carried in the payload rather than the event name.
</Note>

## Report

`report_triggers`

`report_triggers` subscribes to report lifecycle events: `CREATE` when a report is created, and `UPDATE` when its status changes (for example, once it's ready to download). Only `report.update` is currently emitted by any service; `report.create` can be subscribed to but has no emitter yet.

## Payout

Payout events don't have a corresponding trigger field.

| Event | Description |
| :- | :- |
| `payout.payout` | Sent when a payout event occurs. |

## Marketplace Split Transfers

Like payouts, split transfer events don't have a corresponding trigger field, and merchants currently cannot opt out of them. Per engineering, these are recorded internally under the `type_event` `transfer.transfer`; the delivered webhook body itself carries no `type`/`type_event` envelope — identify the event from the transfer object's own fields, as shown in [Payloads and Examples](/docs/webhooks/object-and-examples#marketplace-split-transfers).

| Event | Description |
| :- | :- |
| `succeeded` (type `split_transfer`) | Split transfer completed successfully. |
| `succeeded` (type `split_transfer_reverse`) | Split transfer reversal completed successfully. |

## Banking Connectivity

Banking Connectivity (Banking as a Service) webhooks follow the same delivery and retry behavior as the rest of this page, but are a separate product surface. See [Banking Connectivity webhook events](/reference/banking-connectivity#webhook-events) for the full event catalog (entities, onboardings, accounts, and transfers) and [Webhook Notifications](/reference/banking-connectivity/webhooks/webhook-notifications-banking) for the incoming-transfer payload structure.