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
Example payload
Example payload
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
Example payload
Example payload
checkout.session.expired
An open session reaches its expiration without completing.
data.object: checkout_session · operations: none
Example payload
Example payload
Terminal batches
terminal_batch.closed
A terminal batch closes.
data.object: terminal_batch · operations: none
Example payload
Example payload
terminal_batch.reconciled
Every transaction in a closed terminal batch is matched to Ionic financial records without conflicts.
data.object: terminal_batch · operations: none
Example payload
Example payload
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
Example payload
Example payload
terminal_batch.needs_attention
A closed terminal batch needs review before its totals can be confirmed.
data.object: terminal_batch · operations: none
Example payload
Example payload
Charges
charge.settled
A Charge is included in a settled terminal batch.
data.object: charge · operations: none
Example payload
Example payload
Payment intents
payment_intent.created
A payment intent is created via POST /v1/payment_intents.
data.object: payment_intent · operations: confirm, cancel
Example payload
Example payload
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
Example payload
Example payload
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
Example payload
Example payload
payment_intent.payment_failed
A payment attempt is declined or cannot be completed.
data.object: payment_intent · operations: retry_with_new_payment_method
Example payload
Example payload
payment_intent.canceled
A payment intent is canceled or voided before capture.
data.object: payment_intent · operations: none
Example payload
Example payload
Refunds
refund.created
A refund is created via POST /v1/refunds.
data.object: refund · operations: none
Example payload
Example payload
refund.succeeded
A refund succeeds. Its settlement status can update later.
data.object: refund · operations: none
Example payload
Example payload
refund.failed
A refund attempt fails.
data.object: refund · operations: retry
Example payload
Example payload
refund.settled
A Refund is included in a settled terminal batch.
data.object: refund · operations: none
Example payload
Example payload
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
Example payload
Example payload
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
Example payload
Example payload
invoice.marked_uncollectible
Dunning is exhausted and the invoice is marked uncollectible — the final, no-retry failure.
data.object: invoice · operations: none
Example payload
Example payload
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
Example payload
Example payload
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
Example payload
Example payload
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
Example payload
Example payload
Credit notes
credit_note.created
A credit note is issued against an invoice.
data.object: credit_note · operations: void
Example payload
Example payload
credit_note.voided
A credit note is voided.
data.object: credit_note · operations: none
Example payload
Example payload
Customers
customer.created
A customer is created via POST /v1/customers.
data.object: customer · operations: update, delete
Example payload
Example payload
customer.updated
A customer’s details change.
data.object: customer · operations: update, delete
Example payload
Example payload
customer.deleted
A customer is soft-deleted via DELETE /v1/customers/{id}.
data.object: customer · operations: restore
Example payload
Example payload
customer.restored
A soft-deleted customer is restored via POST /v1/customers/{id}/restore.
data.object: customer · operations: update, delete
Example payload
Example payload

