Supported Stripe events
Every Stripe event BeeL listens to, what BeeL does with each, and which ones are explicitly ignored.
BeeL subscribes to a curated subset of Stripe events. Some create invoices, some only update connection metadata, and many are explicitly ignored to keep the event log clean. This page is the canonical list — if an event isn't here, BeeL drops it with a typed reason.
At a Glance
| Events that create invoices | payment_intent.succeeded, invoice.paid, invoice.payment_succeeded, checkout.session.completed |
| Events that create correctives | refund.updated (status=succeeded), credit_note.created |
| Events that update the connection | account.application.deauthorized, account.updated |
| Events explicitly ignored | charge.succeeded, subscription lifecycle, dispute lifecycle |
| Deduplication | Stripe event.id per account — same event is processed at most once |
Events that create invoices
| Stripe event | What BeeL does | Notes |
|---|---|---|
payment_intent.succeeded | Issues a standard or simplified invoice (forward) | The default success event for one-off payments |
checkout.session.completed | Issues a standard or simplified invoice (forward) | Triggered after a Checkout flow completes |
invoice.paid | Issues a standard or simplified invoice (forward) | Fired when a Stripe Invoice (Billing) is paid |
invoice.payment_succeeded | Issues a standard or simplified invoice (forward) | Stripe Billing on the platform account |
All four produce a forward invoice in BeeL — see Generated invoices for the type-decision rules (F1 vs F2).
Events that create correctives
| Stripe event | What BeeL does | Notes |
|---|---|---|
refund.updated (when status: succeeded) | Issues a corrective referencing the original invoice | BeeL maps Stripe's reason to an R1–R5 code |
credit_note.created | Issues a corrective referencing the original invoice | Stripe Billing's native credit note |
BeeL looks up the original invoice by the Stripe payment intent ID stored on the original. If the original isn't found (yet — possible due to event ordering), the event is parked and retried.
Events that update the connection
| Stripe event | What BeeL does |
|---|---|
account.application.deauthorized | Marks the connection as disconnected; subsequent webhooks are rejected |
account.updated (with restrictions) | Marks the connection as in error until the restriction is lifted |
You don't need to do anything when these fire — the dashboard surfaces the connection state and you can reconnect from there.
Events explicitly ignored
These arrive but BeeL drops them with a typed reason:
| Stripe event | Why |
|---|---|
charge.succeeded | Parallel event to payment_intent.succeeded. We prefer payment_intent.succeeded because it carries the expanded customer.tax_ids block; processing both would double-issue. |
charge.dispute.created | Tracked in the event log but no auto-amend happens; disputes need manual handling for now |
payment_intent.payment_failed / invoice.payment_failed | Defined in the catalogue but no handlers registered — failed payments don't generate invoices |
customer.subscription.* | Subscription lifecycle is informational; invoices come from invoice.paid / invoice.payment_succeeded |
| Anything else | Not in BeeL's supported set |
See Edge cases for what to do when an event you expected to produce an invoice was skipped.
Deduplication
Stripe sends events at least once. BeeL deduplicates by Stripe's event.id:
- The first delivery is recorded and processed.
- Subsequent deliveries with the same event ID return
HTTP 200 OKimmediately — no reprocessing.
If you need to reprocess an event (e.g. a fix shipped after a previous failure), see Edge cases > Replay.
What about the Stripe webhook signature?
BeeL verifies every webhook with HMAC-SHA256 against the connection's signing secret. Unsigned or mis-signed requests are rejected before they're recorded.
Related
- Generated invoices — what each event produces
- Data conversion — how the Stripe payload becomes invoice fields
- Edge cases and limits — what gets skipped and how to replay