See PR Quorum before you install.

The retry branch re-processes the raw payload without calling verifyStripeSignature() — only the first-attempt path validates. A forged POST to the retry endpoint would be accepted and mutate subscription state. Move verification above the attempt branch so every path is covered.

refreshSeats() reads seat_count, then writes it back after an await on the Stripe API. A concurrent customer.subscription.updated webhook between the read and the write silently loses one of the two updates. Use an atomic UPDATE … SET seat_count = excluded.seat_count or take a row lock for the read-modify-write.

- const current = await getSeatCount(accountId);
- await stripe.subscriptions.update(subId, { quantity: current + 1 });
- await setSeatCount(accountId, current + 1);
+ await db.rpc('increment_seats_atomic', { account_id: accountId });
+ await stripe.subscriptions.update(subId, { quantity: await getSeatCount(accountId) });

new Stripe(…) per request re-parses the key, re-creates the agent pool, and defeats keep-alive. Hoist it to module scope (the SDK is stateless across requests) — this is also where a request-scoped client quietly leaks API version overrides across handlers.

Stripe replays the same event.id on automatic retries, but a manually re-sent event from the dashboard mints a NEW id for the same logical change — the dedupe table won’t catch it. Key on (event.type, subscription.id, created) for state-transition events, or accept the rare double-apply and make the handler idempotent on content.