Stripe integration
Reliable Stripe webhooks with persistent buffering
Stripe sends webhooks for every meaningful payment event — checkout.session.completed, invoice.payment_failed, customer.subscription.deleted. If your handler is unhealthy when one arrives, Stripe retries for up to three days, but during that window you may double-process events, lose them on partial failure, or simply miss the retry windows during a long incident.
Last updated: 2026-05-01
TL;DR
Point Stripe at a Zalapier endpoint instead of your app. Zalapier persists every event to Postgres before any delivery is attempted, then forwards it to your real handler with HMAC verification, exponential-backoff retries, and a UI for editing and replaying broken payloads. Free for 1,000 events/month.
Why Stripe webhooks fail (and the cost when they do)
Stripe's webhook system is solid — but the failure modes that bite teams aren't on Stripe's side. They're in your stack: a deploy that takes 90 seconds, a Postgres connection pool that briefly exhausted, an n8n container that restarted mid-flow, a 502 from your reverse proxy during a config reload.
Stripe will retry, but only on a fixed schedule and only for three days. If your incident outlasts that window, the event is gone. For payment_intent.succeeded that means a paid order with no record in your system; for invoice.payment_failed it means a customer who silently lapses; for charge.dispute.created it means missing the dispute deadline.
How Zalapier solves it
Zalapier ingests the Stripe webhook, verifies the Stripe-Signature HMAC, and persists the entire payload (headers + body + metadata) to Postgres before any delivery is attempted. Returning a 200 to Stripe is decoupled from your downstream handler being healthy.
From there, Zalapier queues delivery to your destination(s) — your API, your n8n flow, your Slack channel — and retries with exponential backoff (1m → 5m → 15m → 1h → 4h). If the destination eventually fails after all retries, the payload sits in your dashboard waiting for manual intervention; you can edit the JSON body and re-queue from the built-in sandbox.
What you get end-to-end
Inbound HMAC verification using your Stripe webhook secret (no token in URL paths). Outbound HMAC signing of the forwarded payload with X-Zalapier-Signature so your destination can verify the request came from Zalapier and wasn't replayed.
Real-time delivery dashboard, full payload search by status (received, delivered, failed, held), CSV export, and a 7-day or 30-day retention window depending on your plan.
Set up Stripe webhook buffering in 3 minutes
-
1
Create a Zalapier endpoint
Sign up free at zalapier.com and create an endpoint. You'll get a unique URL like https://zalapier.com/api/in/stripe-prod-7x2k.
-
2
Add your destination
In the Zalapier dashboard, add a destination — your real Stripe webhook handler URL (e.g., https://api.yourapp.com/webhooks/stripe). You can add multiple destinations to fan out to your API, n8n, and Slack simultaneously.
-
3
Switch Stripe to the new endpoint
In your Stripe dashboard, edit your webhook endpoint to point at the Zalapier URL instead. Pick the events you care about (payment_intent.*, invoice.*, etc.). Stripe will start sending events to Zalapier; Zalapier will buffer and forward to your real handler.
-
4
Verify and decommission the old path
Watch Zalapier's live event log to confirm payloads are arriving and being delivered with 2xx responses. Once you're confident, remove the direct-to-app webhook in Stripe so all events flow through the buffered path.
Frequently asked questions
Does Zalapier verify Stripe's HMAC signature? ⌄
Yes. Configure your Stripe webhook secret in your Zalapier endpoint and Zalapier will verify the Stripe-Signature header on every inbound request before persisting.
What if my downstream handler is down for hours? ⌄
Zalapier retries with exponential backoff up to ~5 hours of cumulative delay (1m, 5m, 15m, 1h, 4h). If the handler is still unhealthy after that, the payload moves to a 'failed' state and waits in the dashboard for manual replay — it's never dropped.
Will this double-process Stripe events? ⌄
No. Zalapier delivers each event once per destination by default. If your handler is idempotent (and it should be — Stripe's docs recommend it), retries are safe. Stripe's event ID is preserved so you can deduplicate downstream.
Can I see the raw payload Stripe sent? ⌄
Yes — every received payload (headers + body) is stored in Postgres and viewable in the dashboard. You can copy the cURL or open the Payload Sandbox to edit and replay.
How much volume does this support? ⌄
1,000 events/month free, 100,000 on Pro ($29/mo), 1,000,000 on Ultra ($99/mo). Stripe charge volume rarely exceeds these tiers for most SaaS businesses.
Does Zalapier work alongside Stripe webhook signatures? ⌄
Yes. Zalapier verifies Stripe's signature on inbound, then re-signs the forwarded request with X-Zalapier-Signature so your downstream can verify origin. You can also pass through the original Stripe-Signature header if you want your handler to verify against Stripe directly.
Stop losing Stripe events to deploys
Free plan covers 1,000 events/month. No credit card required. Switch your Stripe endpoint in 3 minutes.
Start free — no credit card →