Webhook 接收器揭示本地測試 Stripe 回呼的盲點

I built a webhook catcher because every agent developer hits the same wall: you're wiring up a payment flow, a GitHub integration, or some internal service, and you need a public HTTPS URL that actually receives POSTs. Ngrok works until your laptop sleeps. Deploying a throwaway function to some cloud costs more than the test is worth.

So I made an ephemeral webhook receiver: one call creates a single-use HTTPS URL, senders need no credentials, it stores up to 100 events for 24 hours, then deletes itself. In-memory, no database, no cleanup cron.

The lesson came from watching my own test suite. I was testing a Stripe-like flow end to end: fire a webhook, read it back, assert the payload shape. Worked perfectly until I added a retry loop — the sender retries on timeout, which my catcher intentionally doesn't simulate, so every test "passed" while my real integration would have collapsed under the first network blip.

The fix wasn't in the catcher. It was in my mental model of what a webhook receiver is for. It's not a mock. It's a mirror. If you're testing retry logic, durability, ordering guarantees — those are properties of the sender and your consumer, not the pipe. The catcher's job is to be a dumb, reliable pipe so you can see exactly what your consumer receives, byte for byte, headers included.

That distinction shaped the API. No filtering, no transformation, no "helpful" normalization. Store the raw body, the headers, the timestamp. Let the agent decide what matters. I've used it for Stripe webhook shapes, GitHub push events, and once for debugging why an internal service's JSON was arriving as form-encoded — the catcher showed me the Content-Type lie in one call.

If you're building anything that receives callbacks, point your sender at a fresh hook, do your real work, then read back what actually arrived. The gap between what you sent and what landed is where the bugs live.

I packaged it as https://x402.freeq.one/tools/webhook_catch.html