Stripe Webhook Signature Tester

Stripe doesn't hand you a black-box signature. The Stripe-Signature header is a comma-separated list of key=value pairs: one timestamp t= and one or more signatures keyed by scheme — currently v1=. Verification is four moving parts, and getting any one wrong sinks the whole thing.

Step 1. Split the Stripe-Signature header on commas. Pull out t=<unix_timestamp> and v1=<hex_signature>. If either is missing, reject — that request is malformed and an attacker may be probing.

Step 2. Build the signed payload as the literal string timestamp + "." + raw_body. The body must be the exact bytes Stripe sent — which means you cannot re-serialize it after JSON.parse. Most webhook failures we audit are here: Express, NestJS, or Next.js middleware mangles the body before verification.

Step 3. Compute HMAC-SHA256 of the signed payload using your endpoint's signing secret (whsec_...). This is what Web Crypto's crypto.subtle.sign("HMAC") does. Output is 32 bytes, hex-encoded to 64 characters.

Step 4. Compare your computed hex against v1 from the header — using a constant-time comparison. Never use a === b here. A string-equality short-circuit leaks signature bytes through timing.

The fifth check most teams skip. Even with a valid signature, you should reject the request if now − t > 300 seconds. Without that tolerance, an attacker who replays a signed webhook from last week — say, a successful payment — can trigger your post-payment side effects (granting access, sending product) twice. This is the entire reason the timestamp is inside the signed payload: it ties the signature to a specific moment in time.

In Stripe's own server library, this is the difference between constructEvent() succeeding and throwing a SignatureVerificationError. The library defaults the tolerance to 300 seconds. You can pass a custom value if your application has unusual clock-skew tolerance, but most teams should stay at the default.

One more nuance: Stripe's header can include multiple v1 signatures during secret rotation. When you rotate a signing secret in the Dashboard, Stripe will send both the old and new signatures for a grace period. Your verifier should accept the request if any of the v1 signatures matches your current secret. Don't assume v1=<single value>.

If you're seeing 400s in your Stripe Dashboard's webhook attempts log and you can't figure out why, drop the failing payload into this tool. The step-by-step output points directly at the broken check — almost always either timestamp tolerance or body mutation.

For deeper builds — Connect marketplaces, multi-event idempotency, dunning state machines — see our Stripe integration services page, or use the Stripe integration cost calculator to estimate scope.