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
Hosted Connect lifecycle
These types are introduced by the Connect lifecycle release (catalog v4). Confirm that the release and your Platform Program are enabled before subscribing.
Selecting an existing Account does not emit
account.created. A completed visit
means merchant actions finished; payments_enabled can remain false while the
application is under review. A new Connection emits connection.created;
connection.activated describes reactivation after suspension.
Subscribe to the Platform-owned and connected-account scopes separately; each
endpoint has its own signing secret. Application-derived Account events go only
to the originating Platform with its exact active Connection. Pre-consent visit
events do not reveal merchant identity. Payloads never include onboarding answers,
owner identity, bank information, documents or browser credentials.
After verifying the signature, persist the envelope id for deduplication.
Advance the snapshot only for a higher data.object.version within the same
object ID, mode and version_scope. Scopes are account, connection,
account_link, or application:<application_id> on application-derived Account
updates. A replacement link starts its own version sequence. Map your customer
using the AccountLink ID your server saved; external_reference may repeat.
