Webhook events by provider

Webhooks are how PaymentGateway keeps your payment state in sync with what actually happens at the provider — a capture, a refund settling, a dispute opening. You subscribe to events at the provider, the provider signs and delivers them to your wallet webhook endpoint, and the platform normalizes each provider's events into the same internal payment_intent / charge state. The goal is parity: the same sequence of real-world events produces the same internal status, whichever provider processed the payment.

Always verify the webhook signature before trusting an event, and treat delivery as at-least-once — handlers must be idempotent. See the Webhooks guide for signing and deduplication.

Stripe

Stripe is the reference provider and emits the full event catalog. The platform consumes the payment- and billing-relevant events below to drive your state.

Charge charge.succeeded · charge.captured · charge.failed · charge.pending · charge.refunded · charge.refund.updated · charge.expired · charge.updated

Payment Intent (full lifecycle) payment_intent.created · payment_intent.processing · payment_intent.requires_action · payment_intent.amount_capturable_updated · payment_intent.succeeded · payment_intent.partially_funded · payment_intent.payment_failed · payment_intent.canceled

Refunds refund.created · refund.updated · refund.failed

Disputes (chargebacks) — full lifecycle charge.dispute.created · charge.dispute.updated · charge.dispute.closed · charge.dispute.funds_withdrawn · charge.dispute.funds_reinstated

Checkout / Customer / Billing — Stripe also drives Checkout Sessions, Customers, Invoices, Subscriptions, Quotes, Credit Notes, Coupons, Products/Prices and Tax via their respective event families (e.g. checkout.session.completed, invoice.paid, customer.subscription.updated). Because Stripe is billing_mode: native, these billing events are authoritative for Stripe-backed accounts.

Omise

Omise emits dedicated events for the operations below. A few behaviors differ from Stripe — note them when reasoning about state.

Events the platform handles today charge.create · charge.complete · charge.capture · charge.reverse · charge.update · charge.expire · refund.create · customer.create · customer.update · customer.update.card · customer.destroy · card.destroy

Caveats that matter for your integration

• charge.capture / charge.reverse fire on the manual-capture path only. These are real, dedicated Omise events — charge.capture when a previously authorized charge is captured, charge.reverse when an authorization is voided. They do not fire for auto-capture charges (which have no separate capture step — you'll see charge.create and, for 3DS flows, charge.complete). They fire whether the action was taken via the API or from the Omise dashboard, so out-of-band capture/void is reflected.
• Refunds emit only refund.create — there is no refund completion/update event. For refunds that settle asynchronously, the platform determines final refund state by re-querying the charge/refund rather than waiting for a second event.
• No authorization-lifecycle event. Omise has no equivalent to Stripe's payment_intent.amount_capturable_updated; authorization/"capturable" state is derived from the charge's fields, not pushed as an event.
• Disputes are deliverable but not yet handled. Omise can emit dispute.create, dispute.update, dispute.accept, and dispute.close (a dispute's won/lost outcome rides the status field on dispute.update/dispute.close). Handling for these is 📝 coming soon — until then, chargebacks on Omise are not reflected in your internal state automatically.

How normalization works

Whatever the provider, the platform maps incoming events onto the same internal model so your payment_intent.status means the same thing everywhere. Where a provider doesn't push a needed transition as an event (e.g. Omise authorization/refund settlement), the platform derives or reconciles that state from the charge so the end result still converges. When you build provider-agnostic logic, rely on the unified payment status, not on a specific provider's raw event names.

Other providers' webhook references will be added here as they're documented; this page starts with Stripe and Omise.