Webhook Guides
Stripe Webhook Gateway
Stripe webhooks drive billing state, checkout fulfillment, subscriptions, disputes, invoices, and internal finance workflows. A direct endpoint can accept the request, but production teams also need verification, routing, retries, replay, and delivery logs.
FastHook sits between Stripe and your destinations as a webhook gateway: receive the signed Stripe request, persist event evidence, route it to the right systems, and recover failed deliveries after downstream services are fixed.
Why Stripe webhooks need reliable delivery
Billing events often arrive while deploys, queues, databases, or internal APIs are unhealthy. Returning200 OK to Stripe does not prove that the invoice, subscription, or customer workflow finished inside your product.
- Keep a record of the original Stripe request and signature result.
- Route payment, invoice, checkout, subscription, and dispute events separately.
- Retry failed destination deliveries without asking Stripe to resend everything.
- Replay only the affected event window after a downstream fix.
Stripe signature verification
FastHook Stripe sources verify the stripe-signature header with the endpoint signing secret. Verification happens before accepted traffic is routed to destinations.
- Use the same Stripe endpoint signing secret in Stripe and FastHook.
- Preserve raw-body verification at ingress.
- Inspect rejected requests when timestamps or signatures fail.
- Route verified events with source evidence attached.
Failed Stripe webhook delivery
A Stripe event can be accepted by FastHook and still fail later at a destination. FastHook attempt logs show the destination URL, response status, body preview, latency, and retry state.
Replay Stripe events
Replay is useful after a billing receiver is fixed. Start with a single failed event, confirm the receiver handles duplicate Stripe event ids safely, then widen recovery only if the result is correct.
Route Stripe webhooks to multiple destinations
| Stripe event family | FastHook route | Destination example |
|---|---|---|
| checkout.session.completed | Fulfillment branch | Production API |
| invoice.payment_failed | Ops alert branch | Slack incident channel |
| customer.subscription.updated | Audit branch | Google Sheets |
| charge.dispute.created | Finance branch | Internal HTTP receiver |
Stripe webhook to Google Sheets
Send selected Stripe events to Google Sheets when finance, support, or operations needs a human-readable review queue. Map fields such as customer email, invoice id, amount, currency, and event type.
Stripe webhook to Slack
Send Slack notifications for failures, disputes, subscription changes, or high-value events. Keep Slack as an alert surface and FastHook logs as the durable delivery record.
Stripe to internal API
Most Stripe webhook gateways still need a primary internal API destination for billing state. FastHook keeps that destination separate from operational destinations such as Slack and Google Sheets, so a Slack alert can succeed even if the billing API needs retry or replay.
Troubleshooting
- Signature failed: compare the FastHook signing secret with the Stripe endpoint secret.
- No event arrived: verify the Stripe endpoint URL points to the current FastHook source URL.
- Destination failed: inspect response status and body before retrying.
- Duplicate processing: store Stripe event ids before creating side effects.
- Too much traffic: filter by event type before fan-out or Slack delivery.
Stripe webhook gateway FAQ
Can FastHook verify Stripe webhook signatures?
Yes. The Stripe source type verifies the signed header with the configured endpoint secret before routing.
Can I send Stripe webhooks to Slack and Google Sheets?
Yes. Use separate FastHook connections so each destination has its own filters and retry behavior.
Should I replay every failed Stripe event?
No. Fix the receiver first and confirm idempotency around Stripe event ids before replaying.