webhookslisted

Use when receiving, verifying, or acting on Stripe events server-side — building a webhook endpoint, verifying the Stripe-Signature header, handling event delivery/retries/duplicates, or deciding which events matter for a payment / subscription / checkout / Terminal / Connect flow. This skill is the shared foundation referenced by ALL other stripe-* skills (stripe-suite:payments, stripe-checkout, stripe-suite:billing, stripe-suite:terminal, stripe-suite:connect). Triggers — "webhook", "Stripe-Signature", "whsec_", "constructEvent / construct_event", "signature verification failed", "No signatures found matching", "event destination", "thin vs snapshot event", "payment_intent.succeeded / checkout.session.completed / invoice.paid / customer.subscription.updated / account.updated", "stripe listen", "stripe trigger", "resend event", "duplicate webhook / idempotent processing", "raw body / body-parser broke my webhook", "which events should I listen to". API version pinned 2026-06-24.dahlia.
Florkin/claude-stripe-skills · ★ 0 · Web & Frontend · score 70

Install: claude install-skill Florkin/claude-stripe-skills

# Stripe Webhooks Server-side ingestion of Stripe events. A webhook endpoint is Stripe's way of pushing you asynchronous notifications ("this payment succeeded", "this subscription renewed") so you don't have to poll. **Pinned API version: `2026-06-24.dahlia`.** A webhook endpoint carries its *own* API-version pin, set at creation time, which controls the shape of the `Event` object it delivers — this is independent of your SDK/account pin. Verify the endpoint's pinned version matches what your handler expects. > This is a **shared foundation** skill. If you're implementing a specific product flow, start from its > skill (`stripe-suite:payments`, `stripe-checkout`, `stripe-suite:billing`, `stripe-suite:terminal`, `stripe-suite:connect`) > and come here for the endpoint + verification mechanics. The `stripe-suite:integration` router picks the > right one. Never re-derive auth/idempotency/money rules — those live in the shared foundations. ## When to use / decision tree ``` Do you need to REACT to something that happened in Stripe (payment cleared, subscription renewed, account updated) rather than something a user just did in a request you control? → yes: you need a webhook. Continue. → no (you got a synchronous API response you can trust): you may NOT need a webhook at all. Is the payment method delayed/async (bank debit, some wallets, delayed Checkout)? → yes: the synchronous response is NOT final. You MUST use webhooks to learn the outcome. Is this a subscripti