Webhooks that don't check who's calling
A payment webhook tells your app that money arrived. If you skip Stripe's signature check, anyone on the internet can POST fake success and unlock paid features for free.
What can go wrong
Webhooks are HTTP callbacks: Stripe (or another provider) POSTs to your server when an event happens.
Stripe signs each request with a secret only you and Stripe share. Your handler must verify that signature before trusting the body.
Two common AI mistakes: skipping verification entirely, or parsing the POST body before checking the signature. Parsing first changes the bytes Stripe signed, so verification fails even when you tried.
About 50% of the AI-generated webhook handlers vibe-eval sampled skip or break verification (vibe-eval #8).
It happened for real
Stripe's own documentation warns that unsigned handlers let attackers forge payment-success events (Stripe webhook signatures). Practitioner guides for AI-written Stripe integrations repeat the pattern: AI skips signature verification or parses the body in the wrong order (vibeorigin Stripe guide).
This is less a headline breach class than a silent fraud lane: fake webhooks grant access without a news story.
How to check yours
Seatbelt flags this automatically. Stripe webhook routes without signature verification (or your project's shared verify helper) are soft payment flags. Handlers that verify in the wrong order get a separate soft flag.
Ask your agent: "Open every Stripe webhook route. Confirm it reads the raw body bytes, verifies the Stripe signature, and only then parses the event JSON."
We don't catch this yet: Non-Stripe providers (Paddle, Lemon Squeezy) unless we see the same missing-verify pattern in your source.
Fix direction
Verify on the raw request body first. Reject unsigned or tampered requests with 400 before updating orders or entitlements.
Paste into your agent: "Fix Stripe webhooks to verify signatures on the raw body before parsing. List every webhook file changed."