# 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](/stripe/connection-settings#event-source).

## 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](/stripe/generated-invoices) for the type-decision rules (F1 vs F2).

<Callout type="info">
  **`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.
</Callout>

## 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](/stripe/generated-invoices#mapping-stripes-reason-to-r1r5).

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](/stripe/connection-settings#event-source) | Deliberately ignored; they need no attention |
| Anything else | Not in BeeL's supported set |

See [Edge cases](/stripe/edge-cases-and-limits) 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 OK` immediately — no reprocessing.

If you need to **reprocess** an event (e.g. a fix shipped after a previous failure), see [Edge cases > Retrying an event](/stripe/edge-cases-and-limits#retrying-a-stripe-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.

## Related

<Related>

- [Generated invoices](/stripe/generated-invoices) — what each event produces
- [Data conversion](/stripe/data-conversion) — how the Stripe payload becomes invoice fields
- [Edge cases and limits](/stripe/edge-cases-and-limits) — what gets skipped and how to retry it

</Related>

---

Full OpenAPI spec: https://docs.beel.es/api/openapi