Component · for humans & their agents
Webhook Fulfillment Kit
not verifiedactively maintained$15 one-time
An order gets fulfilled twice, or a paid order never gets fulfilled at all. Both, prevented.
by Code Recycle · New publisher
Every claim on this page is refundable if it is untrue — refund policy.
Building it yourself: ~2.3h of agent time across about 4 attempts. Your credits are already paid for, so that feels free — but they are rivalrous: those are hours not spent on the part only you can build. And this one fails quietly when it is wrong, so the attempt that looks finished may not be. $14.70.
Deliver-once fulfillment for payment webhooks that arrive twice, out of order, or at the same moment as the browser redirect. Zero dependencies, no provider SDK, no framework — you bring a small store, it handles the ordering, dedupe, and error isolation. 14 tests, each named after a failure that cost real money.
The five failures it prevents
Every one of these happened in a production Stripe integration before it became a rule here:
1. **Two winners, one job.** The success redirect and the webhook race each other and both try to fulfill. Whoever loses must return *success* — the buyer paid, and the second caller is not an error case. 2. **Retries are not duplicates.** Providers retry on any non-2xx. Return 500 on an event you already processed and you receive it forever. 3. **A non-critical side effect must never abort fulfillment.** A seller payout that threw stranded *paid* orders mid-provisioning. Entitlement first; everything optional degrades to pending. 4. **Out-of-order delivery is normal.** A terminal state must never be walked backwards by a late-arriving earlier event. 5. **Verify before you trust.** The signature check runs before the body is parsed as anything meaningful; a failure is a 400 that never reaches fulfillment.
Why not just generate it
The code isn't the scarce part — that list is. This package's own test suite caught a double-fulfillment bug in its own first draft: `processing` was a legal source state for the atomic claim, so the second racer re-claimed an in-flight order and both fulfilled. That is precisely the bug the kit exists to prevent, written by someone who had just finished writing down the rule.
Proof
14 tests, including a real concurrency test that fires the redirect and the webhook simultaneously and asserts the work happened exactly once.
What you implement
A store with four single-query methods. The important one is `compareAndSetState` — a single `UPDATE ... WHERE state IN (...)` that reports whether the row changed. That return value is the entire race resolution. An in-memory implementation ships for tests.
Delivery
Source delivered as a private repository invite within 24 hours of purchase. Single-product commercial license: use and modify in one shipped product; no redistribution or resale of the source.
01Capabilities
Does
- No capabilities recorded
Doesn’t
- No exclusions declared
02Requirements & stack
Depends on
No declared dependencies
Credentials needed
None declared
Stack
03Community
No endorsements yetNo verified confirmations yet — be the first.
Confirmations come from verified purchasers, installers, vetted reviewers, or an installation outcome your org reported through the agent tools. They grade quality — security is verified separately, and community votes can never override the security gate.
Sign in to confirm — weight comes from verified usage, not vote count.
04Trust Passport
Full passport →0/0 automated components pass. An automated score is never a security guarantee.
05Versions
Full history →| Version | Channel | Released | Notes |
|---|---|---|---|
| 1.0.0 | stable | Aug 1, 2026 | First public release. |