Skip to main content
Ionic sends 29 event types. Each example below uses the same payload shape as a webhook delivery. Every payload is wrapped in the standard envelope; subscribe to the ones you handle when you create an endpoint.
Two markers to watch for: Delayed events can arrive shortly after the related API response. Not emitted yet events are reserved for future use and are not sent in v1.

Checkout sessions

checkout.session.created

A checkout session is created via POST /v1/checkout/sessions. data.object: checkout_session · operations: expire, expand

checkout.session.completed

A session’s payment completes and funds are captured. This is the money-moved signal for hosted checkout — fulfill on it. data.object: checkout_session · operations: refund

checkout.session.expired

An open session reaches its expiration without completing. data.object: checkout_session · operations: none

Terminal batches

terminal_batch.closed

A terminal batch closes. data.object: terminal_batch · operations: none

terminal_batch.reconciled

Every transaction in a closed terminal batch is matched to Ionic financial records without conflicts. data.object: terminal_batch · operations: none

terminal_batch.incomplete

A closed terminal batch has one or more transactions that cannot yet be matched to an Ionic financial record. data.object: terminal_batch · operations: none

terminal_batch.needs_attention

A closed terminal batch needs review before its totals can be confirmed. data.object: terminal_batch · operations: none

Charges

charge.settled

A Charge is included in a settled terminal batch. data.object: charge · operations: none

Payment intents

payment_intent.created

A payment intent is created via POST /v1/payment_intents. data.object: payment_intent · operations: confirm, cancel

payment_intent.requires_action

A payment needs additional buyer authentication, such as 3-D Secure.
Defined in the catalog but not emitted yet — Ionic doesn’t run 3DS in v1. It ships now so your handler’s switch can be complete.
data.object: payment_intent · operations: none

payment_intent.succeeded

A payment intent is captured and succeeds. Folds both automatic-capture success and a manual capture. data.object: payment_intent · operations: refund

payment_intent.payment_failed

A payment attempt is declined or cannot be completed. data.object: payment_intent · operations: retry_with_new_payment_method

payment_intent.canceled

A payment intent is canceled or voided before capture. data.object: payment_intent · operations: none

Refunds

refund.created

A refund is created via POST /v1/refunds. data.object: refund · operations: none

refund.succeeded

A refund succeeds. Its settlement status can update later. data.object: refund · operations: none

refund.failed

A refund attempt fails. data.object: refund · operations: retry

refund.settled

A Refund is included in a settled terminal batch. data.object: refund · operations: none

Invoices

Invoice events can arrive shortly after the invoice status changes. Do not require the event to arrive during the API request that caused the change.

invoice.paid

An invoice is paid. data.object: invoice · operations: none

invoice.payment_failed

A collection attempt is declined and a retry is scheduled. (There is no separate invoice.payment_attempted event — a failed attempt that schedules a retry is the failure signal.) data.object: invoice · operations: update_payment_method

invoice.marked_uncollectible

Dunning is exhausted and the invoice is marked uncollectible — the final, no-retry failure. data.object: invoice · operations: none

Subscriptions

subscription.created

A subscription is first created, via the API or a subscription-mode checkout. Fires once, before any update. data.object: subscription · operations: cancel

subscription.updated

A subscription’s status or configuration changes. This is the catch-all signal — activation, past-due, resume, item or payment-method changes, and a scheduled cancel-at-period-end all fold into it. Read data.object for the new state. data.object: subscription · operations: cancel

subscription.canceled

A subscription is canceled immediately — service stops now. A scheduled cancel-at-period-end is a subscription.updated, not this, so you don’t revoke access early. data.object: subscription · operations: none

Credit notes

credit_note.created

A credit note is issued against an invoice. data.object: credit_note · operations: void

credit_note.voided

A credit note is voided. data.object: credit_note · operations: none

Customers

customer.created

A customer is created via POST /v1/customers. data.object: customer · operations: update, delete

customer.updated

A customer’s details change. data.object: customer · operations: update, delete

customer.deleted

A customer is soft-deleted via DELETE /v1/customers/{id}. data.object: customer · operations: restore

customer.restored

A soft-deleted customer is restored via POST /v1/customers/{id}/restore. data.object: customer · operations: update, delete