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, checkout.session.completed, invoice.paid |
| Events that create correctives | refund.created / refund.updated (once the refund has succeeded), credit_note.created |
| Events that raise a review item | charge.dispute.created, charge.dispute.closed (lost), credit_note.voided (after its corrective was issued) |
| Events that update the connection | account.application.deauthorized, account.updated |
| Events explicitly ignored | charge.succeeded, payment_intent.payment_failed, credit_note.updated |
| Deduplication | Stripe event.id per account — same event is processed at most once |
Which of these a connection acts on also depends on its event source (PAYMENTS, INVOICES or BOTH) — see Connection settings.
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 |
All three produce a forward invoice in BeeL. When the same charge arrives through more than one of them, it is invoiced once. See Generated invoices for the type-decision rules (F1 vs F2).
invoice.payment_succeeded is not one of them. On a connected account, a paid Stripe Invoice is invoiced from invoice.paid; invoice.payment_succeeded is recorded as an unsupported event type.
Events that create correctives
| Stripe event | What BeeL. does | Notes |
|---|---|---|
refund.created | Issues a corrective referencing the original invoice, as soon as the refund has succeeded | A card refund is already succeeded when it is created, so the corrective is issued immediately |
refund.updated | Issues the corrective when the refund moves to succeeded | Covers asynchronous payment methods, where the refund starts as pending |
credit_note.created | Issues a corrective referencing the original invoice | Stripe Billing's native credit note |
A refund produces one corrective whichever of its events arrives first, and a refund that is also settled by a credit note is not corrected twice. Stripe's reason is mapped to an R1–R5 code — see Generated invoices.
BeeL. looks up the original invoice by the Stripe charge the refund or credit note belongs to. If the original isn't found (yet — possible due to event ordering), the event is retried. A credit note issued against a Stripe Invoice that was never paid produces no corrective: there is no BeeL. invoice to correct.
Events that raise a review item
These never issue anything on their own. They link the Stripe object to the charge and its invoice, and put the event in front of you, because the fiscal outcome is your decision.
| Stripe event | What BeeL. does |
|---|---|
charge.dispute.created | Records the dispute against the charge and its invoice, and opens a manual-review item |
charge.dispute.closed | Closes the review item opened by charge.dispute.created. If you won the dispute, the charge and its invoice stand and nothing else is asked of you. If you lost it, the money went back to the payer and a single review item remains: decide whether the invoice needs a corrective, and issue it yourself |
credit_note.voided | If the credit note had already produced a corrective, opens a review item: that corrective is already numbered and submitted, and voiding the note in Stripe does not undo it. If it had produced nothing, the event is ignored |
Each dispute leaves one review item, even when Stripe delivers the closing event before the opening one.
Events that update the connection
| Stripe event | What BeeL. does |
|---|---|
account.application.deauthorized | Marks the connection as disconnected; subsequent events are recorded but not processed |
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. records them as skipped on purpose:
| Stripe event | Why |
|---|---|
charge.succeeded | Same payment as payment_intent.succeeded, which is the one that invoices; processing both would double-issue. |
payment_intent.payment_failed | A failed payment has nothing to invoice |
credit_note.updated | Changes that matter reach BeeL. as credit_note.voided |
invoice.created, invoice.finalized, invoice.updated, invoice.sent | The Stripe Invoice is still waiting for payment; it is invoiced when invoice.paid arrives |
| Events outside the connection's event source | Deliberately ignored; they need no attention |
| 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 > Retrying an event.
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.