Webhook reliability for peptide subscription checkout
- A dropped renewal webhook on a peptide subscription store silently breaks fulfillment, dunning, and your reserve math all at once.
- Build for idempotency, signed verification, and a queue with retries — never trust a single delivery from any processor.
- A nightly reconciliation job that compares processor truth against your database catches the events that webhooks lost.
On this page
It is 7am and your peptide subscription store looks fine. Orders are flowing, the dashboard is green. Then a customer emails: they got charged for their monthly BPC-157 refill three days ago, but no tracking, no receipt, nothing shipped. You pull the charge in your processor. It settled. Your own database has no record of it. Somewhere between the acquirer firing a renewal event and your store writing it down, the webhook vanished. Now multiply that by the 40 silent ones you have not heard about yet.
This is the failure mode that quietly wrecks peptide subscription operations. Not a checkout that is down — those you notice in minutes. It is the renewal that charged the card, never reached your system, and left a customer paid-but-unfulfilled. On a high-risk vertical, that exact gap turns into chargebacks, and chargebacks turn into reserve hikes and closures. Webhook reliability is not a backend nicety here. It is risk management.
Why peptide subscriptions are uniquely exposed
Most ecommerce stores take a one-time payment. The webhook either lands or the customer complains at checkout and retries. Subscriptions are different: the charge fires on a schedule the customer is not watching, and the only signal your fulfillment system gets is an asynchronous event. If that event drops, nobody is standing at the register to notice.
Peptide operators stack three multipliers on top of that. First, recurring research-compound refills are the core revenue model, so renewal volume is high. Second, your chargeback ratio is already under a microscope on a high-risk MID, so a paid-but-unshipped order is far more expensive than it would be for a t-shirt brand. Third, many peptide stores run on a parent account with multiple brands, so one flaky integration can corrupt the ledger across the whole portfolio.
The math is brutal. A customer who pays and does not receive product files a "merchandise not received" dispute. That single event pushes your ratio toward the monitoring threshold, and on peptides the acquirer reaction is faster and harsher than on low-risk verticals.
The events that actually matter
Not every webhook is load-bearing. For a peptide subscription store, build hardest around the small set that moves money and triggers fulfillment.
- invoice.paid / charge.succeeded — the renewal cleared. This is the one that must trigger fulfillment. Lose it and you have a paid customer with no shipment.
- invoice.payment_failed — the renewal declined. Lose it and dunning never starts, so you lose the recovery and the customer churns silently.
- customer.subscription.updated / deleted — plan changes and cancellations. Lose it and you keep charging a canceled customer, which is a guaranteed dispute.
- charge.dispute.created — a chargeback opened. Lose it and you miss the representment window entirely.
- charge.refunded — keeps your ledger honest and your reserve math correct.
Everything else can be reconstructed from a nightly pull. These five cannot afford to be late.
Build for idempotency first
The single most common bug is processing the same event twice. Processors retry deliveries when they do not get a fast 2xx, so the same renewal can hit your endpoint three or four times. Without idempotency, that means a customer fulfilled twice, or a dunning email sent twice, or a refund counted twice in your reserve estimate.
Store every event ID the moment it arrives. Before you act on an event, check whether you have already processed that ID. If yes, return 200 and do nothing. This one rule eliminates the entire class of double-charge-double-ship bugs that look like fraud to your acquirer.
Acknowledge fast, work later
Return your 2xx within a couple of seconds, then do the real work — fulfillment write, email, ledger entry — in a background queue. If you ship inside the webhook handler and your fulfillment API is slow, the processor times out, marks the delivery failed, and retries. Now you have the double-processing problem on top of the slowness problem.
Verify signatures, always
Every serious processor signs its webhooks. Verify the signature on every request before you trust a single field. An unsigned or unverified endpoint is an open door: anyone who learns your URL can post a fake "payment succeeded" and trigger free fulfillment of physical peptide inventory. For a high-risk store, that is not theoretical — fraud rings probe these endpoints. Reject anything that does not verify, and rotate your signing secret if it ever leaks.
Retries and dead-letter handling
Assume your own system will be down sometimes. Deploys, database failovers, a bad release — your endpoint will return 500 at some point. The processor will retry on a backoff schedule (commonly across several hours to a few days), which buys you a window. But if the event still fails after the processor gives up, it is gone unless you caught it.
Put every inbound event into a durable queue before you process it. If processing fails, the event stays in the queue and retries on your own schedule. Events that exhaust retries land in a dead-letter queue that pages a human. The principle: the processor delivering once is not a guarantee of anything. Your queue is the guarantee.
| Failure | What breaks for a peptide store | The guard |
|---|---|---|
| Duplicate delivery | Double ship, double dunning email | Idempotency key on event ID |
| Slow handler | Processor times out, retries, duplicates | Ack in <2s, queue the work |
| Your endpoint down | Renewal charged, never fulfilled | Processor retries + your dead-letter queue |
| Spoofed event | Free fulfillment of real inventory | Signature verification on every request |
| Event lost entirely | Silent paid-unshipped, then a dispute | Nightly reconciliation pull |
Reconciliation is the real safety net
Webhooks are best-effort. Reconciliation is truth. Once a day, pull the authoritative list of charges, refunds, and disputes directly from each processor over its API, and diff it against your own database. Any charge the processor recorded that your system never wrote is a dropped event — fulfill it, alert on it, and find out why it dropped.
This nightly job is what separates operators who get blindsided from operators who do not. It catches the paid-unshipped orders before the customer files a dispute. On a multi-brand portfolio, run it per brand and roll the results into one consolidated ledger so a problem in one store does not hide inside aggregate numbers. If you are unsure how your reconciliation maps to what underwriters expect to see, our note on auditing a peptide merchant statement walks the same data from the risk side.
Where orchestration fits
multiflow sits on top of your processor — Stripe, Square, Authorize.net, NMI — as the orchestration layer for multi-brand peptide portfolios. We do not process the payment. What we do is normalize webhook handling across acquirers, dedupe and verify centrally, and keep one consolidated ledger so reconciliation runs once across every brand instead of N times. For an operator running three or more peptide brands, that is the difference between three fragile integrations and one hardened pipeline.
If you run a single peptide brand, this is mostly your engineering team building idempotency, signature checks, a queue, and a nightly diff — and that is the right call for you. We do not onboard single-brand operators, and a specialist ISO plus solid webhook hygiene will serve you better. The deeper structural tradeoffs live in our peptide operator playbook and the multi-brand operations playbook.
Ordering, replays, and the edge cases that bite
Webhooks do not arrive in order. A subscription.updated can land before the invoice.paid that triggered it, or a refund event can beat the charge it reverses. If your handler assumes order, it makes wrong decisions on perfectly delivered events. Always reconcile each event against the current state in your database rather than assuming the previous event already landed. When an event references a charge you have never seen, fetch that charge from the processor API and backfill it instead of dropping the event on the floor.
Replays are the other trap. When you recover from an outage, you may re-pull or re-receive a batch of events you partially processed. Without idempotency this re-fulfills orders and re-sends emails to customers who already got both. With idempotency keyed on event ID, a replay is harmless — every already-seen event returns 200 and does nothing. This is why idempotency and reconciliation are partners: reconciliation finds the gaps, idempotency makes filling them safe to retry as many times as you need.
Test the failure paths, not just the happy path
Most teams test that a successful renewal fulfills. Few test what happens when the handler throws halfway through, when the same event arrives twice, when a spoofed payload hits the endpoint, or when the processor is unreachable during reconciliation. Those are the paths that actually fail in production on a busy peptide store. Build a staging harness that fires duplicate, out-of-order, and malformed events at your endpoint, and confirm each one is handled without a double-ship or a dropped fulfillment before you raise renewal volume.
A reliability checklist before you scale
- Every event ID stored and checked before processing — no double work.
- Signature verified on every inbound request, secrets rotated on any leak.
- Handler returns 2xx in under two seconds; real work happens in a queue.
- Dead-letter queue with a human alert for events that exhaust retries.
- Nightly reconciliation pull diffed against your database, per brand.
- The five money-moving events monitored with their own alerting.
Get those six in place before you turn up renewal volume. Dropped webhooks do not announce themselves — they show up as chargebacks 30 days later, and by then they are already affecting your reserve and your effective rate.
If you are running multiple peptide brands and your webhook handling is duct-taped per store, that fragility compounds every time you add a brand. We are happy to walk your current setup and tell you honestly whether orchestration helps or whether you just need to harden what you have. Talk to an underwriter through our short application — no hard pull, an honest fit check inside 48 hours.