Stripe source

Turn Stripe webhooks into EventSend events with no code — setup steps, the default event mapping, and how to test it.

A Stripe source gives you revenue alerts without writing an integration. Paste one URL into Stripe, paste one secret back, and payments, failures, subscriptions, and disputes start arriving as events you can route anywhere.

Setup

In EventSend, open Sources, create a source, and choose Stripe. The form shows your endpoint URL and the list of Stripe events to enable. Then, in Stripe:

In your Stripe Dashboard, go to Developers → Webhooks and click Add destination (or Add endpoint).
Paste this source's URL as the endpoint URL.
Select the events you enabled in EventSend (or "Select all events" — anything else is safely ignored).
After creating the endpoint, reveal its signing secret (whsec_...) and paste it into the signing secret field in EventSend.
Test it: run stripe listen --forward-to <this URL> and stripe trigger checkout.session.completed with the Stripe CLI.

Stripe's own webhook documentation is at docs.stripe.com/webhooks.

The signing secret is encrypted at rest and never shown again after you save it. Until you provide it, EventSend rejects incoming requests — this is expected, and it is not a problem: Stripe retries failed deliveries for about 72 hours, so events sent during the setup gap arrive once the secret is in place.

What each Stripe event becomes

Stripe event	Event name	Level	Icon
`checkout.session.completed`	`payment-received`	`success`	💰
`invoice.paid`	`invoice-paid`	`success`	🧾
`invoice.payment_failed`	`payment-failed`	`error`	⚠️
`customer.subscription.created`	`new-subscriber`	`success`	🎉
`customer.subscription.deleted`	`churn`	`warning`	👋
`charge.dispute.created`	`dispute`	`critical`	🚨
`customer.created`	`new-customer`	`default`	👤

Stripe events that aren't in this table are ignored — EventSend answers 200 so Stripe doesn't mark your endpoint as failing, and nothing is recorded or metered.

Because the names are predictable, a topic pattern of payment-* catches both payment-received and payment-failed, and a minimum level of error catches failures and disputes while ignoring routine payments. See routing rules.

The payload

EventSend does not forward the raw Stripe object. Each event carries a small structured payload with just the useful fields, so webhook destinations get something machine-readable and chat messages stay short:

{
  "provider": "stripe",
  "provider_event_id": "evt_1PxYzABC123",
  "object_id": "cs_test_a1B2c3",
  "amount": 4900,
  "currency": "usd",
  "customer_email": "[email protected]",
  "plan": "Scale Monthly"
}

Fields that Stripe didn't supply are omitted. Amounts are in the currency's smallest unit, exactly as Stripe sends them, while the human-readable message renders them as a decimal ("New payment: 49.00 USD from [email protected]").

Security and duplicates

Every request is verified against your signing secret before it is parsed, using the same scheme Stripe documents: the signature is computed over the raw request body, and deliveries older than 300 seconds are rejected. A bad signature returns 401 and increments the source's failure counter, which is visible on the source page.

Stripe retries deliveries, and retries carry the same event id. EventSend uses that id as the event's idempotency key, so a retried delivery is recognized and answered 200 without producing a second event or a second notification.

Ready to route it somewhere? Follow Stripe revenue alerts in 2 minutes.