Crypto Payment Gateway Webhooks 2026: Retry Rules Compared
We checked seven crypto payment gateways' webhook retry rules on 26 September 2026. CoinGate retries for six days; OxaPay gives up in under four hours.
Key Takeaways
- Only two of the seven gateways we checked publish enough to know whether a notification survives your downtime, and the two differ by a factor of about 44. CoinGate documents 40 attempts ending about 6.5 days out; OxaPay documents 5 attempts ending at 3 hours 34 minutes.
- A 401, a 403 or a redirect on your callback URL ends CoinGate's retries immediately — not after 40 attempts, on the first one. So does a TOR or private-network address. Putting basic auth in front of a callback endpoint is the quietest way to break a checkout.
- The response body is part of the contract and the gateways disagree. OxaPay wants HTTP 200 with the literal body ok; BitPay wants HTTP 200 with an empty body and counts anything else as a failure; CoinGate takes 200 or 204.
- BitPay does not sign its notifications at all and says so in its own docs. That is defensible, because the same page tells you to use the notification only as a trigger to re-fetch the invoice — which is what you should do on every gateway anyway.
- Four of the seven let you replay a delivery on demand (BitPay, Cryptomus, CoinGate, BTCPay Server). The resend endpoint is worth more than the retry schedule, because it is the one you control.
Table of Contents
- Seven gateways, seven different answers
- What we checked, and how to repeat it
- CoinGate publishes the whole schedule: 40 attempts, six days
- Four ways a callback dies and never gets retried
- What an outage actually costs you
- BitPay does not sign its notifications, and that is defensible
- Self-hosted: BTCPay queues instead of quitting
- Build the reconciliation job, not faith in the retry
- FAQ
Seven gateways, seven different answers
The money arrived. The blockchain says so, the gateway dashboard says so, and your shop still shows the order as unpaid. Somewhere between those two facts is a failed HTTP request, and how much it costs you depends entirely on a policy almost nobody reads before choosing a processor: how a crypto payment gateway retries the webhook it could not deliver. Get it wrong and you are refunding customers who already paid, or shipping to customers who did not. We spent 26 September 2026 reading the callback documentation of seven gateways, and the spread is much wider than the generic advice suggests — from five delivery attempts inside four hours to forty spread over six and a half days, with four of the seven publishing no schedule at all.
Here is the whole finding in one table. Every figure is quoted from the company's own developer documentation, read on the date above.
Read the last two columns together and the useful conclusion appears. The retry schedule is the column merchants ask about and the replay column is the one that saves them, because a retry policy is something the gateway does to you on a timetable you cannot influence, while a resend endpoint is something you can call at 3am when you have found the gap.
What we checked, and how to repeat it
No gateway was asked for comment and none supplied data. Every number above came from a public documentation page, fetched on 26 September 2026, and you can check all of them in about twenty minutes:
- CoinGate — the full attempt table, the 20-second timeout and the termination conditions are at developer.coingate.com/reference/api-callbacks.
- BitPay — the unsigned-IPN statement, the empty-body requirement and the resend endpoint are at developer.bitpay.com/docs/invoice-webhooks.
- BTCPay Server — the redelivery schedule and the toggle that controls it are in the project's General FAQ.
- OxaPay — the five-attempt schedule, the HMAC-SHA512 scheme and the body ok requirement are at docs.oxapay.com/webhook.
- Cryptomus — the MD5 signing recipe and the single source IP are at doc.cryptomus.com.
Two caveats, stated rather than buried. NOWPayments' help centre would not serve an automated request from our container (HTTP 403 behind a JavaScript challenge), so its entry above is built from its API reference and integration guides; the configurable notification count is documented, the default value and interval are not. And an absent policy is not necessarily a bad one — Cryptomus, Plisio and NOWPayments may well retry generously. The point is that you cannot plan around what you cannot read, and four of seven leave you unable to.
CoinGate publishes the whole schedule: 40 attempts, six days
CoinGate is the outlier for transparency and it costs the company nothing, which makes the silence elsewhere harder to excuse. The escalation is published in full, and it is the most generous we found anywhere in crypto payments.
Add the bands up and the last of the 40 attempts lands roughly 155 hours after the first, at which point, in CoinGate's words, the "callback is terminated and no more will be sent". It also allows a 20-second timeout for your server to answer, which is unusually forgiving — a synchronous handler that verifies a signature, writes a row and sends a confirmation email will comfortably fit inside it, though you should still not write one that way.
The practical consequence is that on CoinGate a deployment that takes your checkout down for an afternoon costs you nothing at all. A merchant on OxaPay doing the same deployment, on the same day, silently loses every notification for any invoice that resolved more than three and a half hours before the endpoint came back. Same outage, same duration, completely different reconciliation workload the next morning — and the difference is invisible unless you went looking for it, which is the argument for reading this page before you pick a processor rather than after. Our gateway comparison tracks the commercial terms; this is the operational half.
Four ways a callback dies and never gets retried
This is the section that does not exist anywhere else, and it is the one that actually loses orders. Retry schedules assume the gateway considers the delivery worth retrying. Several conditions mean it does not, and they are not failures in any sense your monitoring will flag — your endpoint is up, your TLS is valid, and the notification will never arrive again. CoinGate documents its termination triggers explicitly, and they generalise.
The fourth row is the expensive one, because it fails in the direction people do not expect. A slow handler does not lose payments, it duplicates them: the gateway never saw your 200, so it tries again, and a handler that credits an account on every delivery credits it four times. This is why every gateway in the set that documents anything at all tells you to key your processing on the invoice ID and ignore a repeat. If you take one engineering instruction from this page, it is that one. We go further into the failure modes in why a crypto payment shows as not received, and the wider integration patterns are in our crypto payment API guide.
What an outage actually costs you
Retry schedules only matter as an answer to one question: my server was down for this long, do I still get told? Nobody publishes that answer, so we derived it from the schedules above. Read down your gateway's column and find the longest outage it forgives.
The right-hand column is the honest answer for the majority of the market, and it reframes the whole question. For four of seven gateways the retry policy is not a safety net, because you cannot know whether it caught anything. That is not an argument against those gateways — Cryptomus and BitPay both give you a resend endpoint, which is strictly better than a schedule you cannot verify — it is an argument against treating the webhook as your source of truth. Payment timing is downstream of this too; we mapped when the money itself actually lands in crypto payout schedules.
BitPay does not sign its notifications, and that is defensible
The most surprising line in any of these documents is BitPay's: "BitPay does not sign IPNs, so the information in the payload should not be trusted outright." For a processor of that size in 2026 it reads like a gap. Spend a minute with the rest of the page and it turns into a defensible design choice, because the same document tells you what to do instead: treat the notification purely as a trigger and verify through GET /invoices/:invoiceId. An unsigned notification that you never trust is not a vulnerability. It is a doorbell.
The comparison worth making is not signed versus unsigned but what the signature lets you skip, and the answer on every gateway here is nothing. Even a valid HMAC tells you only that the body was authentic when it was sent, not that it is current — notifications can arrive out of order, and a "paid" that overtakes a "refunded" will happily verify.
Cryptomus also posts from a single IP address, 91.227.144.54, which is a genuine convenience for allowlisting at the edge — just remember an allowlist is not authentication, and see the 401 row above before you put one in the request path. There is more on hardening the whole flow in our crypto payment security guide.
Self-hosted: BTCPay queues instead of quitting
Running your own processor changes the shape of the problem rather than removing it. BTCPay Server retries "after 10 seconds, 1 minute, and up to 6 times after 10 minutes" — about an hour of cover, shorter than OxaPay and far shorter than CoinGate — and, unlike the hosted gateways, the retries are a toggle you can forget to turn on. It is called "Automatical redelivery" in the webhook settings, and a webhook created without it gets exactly one attempt.
There is a subtler behaviour worth knowing about, because from the merchant's side it looks exactly like a dead webhook. When an endpoint is failing, BTCPay queues the deliveries for it rather than discarding them, and sends them once the endpoint recovers. That is the good outcome, but for years the webhook UI displayed only when a delivery was created, not when it was actually sent, so a delivery that had been queued for hours was indistinguishable from one that never fired. A change merged on 27 January 2026, shipping in milestone 2.3.4, added a delivery-time field and a badge for delays over a minute. If you are debugging queued webhooks on an older instance, upgrade before you spend an afternoon on it.
Build the reconciliation job, not faith in the retry
Every finding above points the same way. The retry schedules vary by a factor of 44, four of seven are unpublished, and all of them can be short-circuited by a redirect you did not know you had. None of that matters much if you build the one thing that makes you independent of all of it.
- Record every invoice at creation. Gateway, gateway invoice ID, amount, status, created-at. If the only record of an expected payment is in the gateway's dashboard, a missed callback is unrecoverable by definition.
- Poll the ones that went quiet. A scheduled job that selects open invoices past their window and calls the gateway's status endpoint. This replaces all seven retry policies with one you control, and it is the only mechanism that catches a delivery that succeeded before your database write failed.
- Return 200 before you do the work. Acknowledge, queue, process. It removes the timeout class of failure completely, and with it the duplicate-crediting bug that follows.
- Make the handler idempotent on the gateway invoice ID, in durable storage rather than memory. Retries are a certainty, not an edge case, and an in-process cache does not survive the deploy that caused the retry.
- Keep the callback path anonymous and un-redirected. No auth layer, no WAF rule, no http-to-https hop, no private or staging host. Verify the signature inside the handler.
- Find the resend endpoint before you need it. On BitPay, Cryptomus, CoinGate and BTCPay it exists; write down the exact call now, while nothing is broken.
One limit on all of this, stated plainly: these are documented policies read on a single day, not measured deliveries. We did not take seven gateways into production and pull their plugs, and a company can change a retry schedule without changing a marketing page. What is durable is the structure. Retry generosity is unrelated to gateway size or price, it is almost never mentioned during sales, and the replay endpoint matters more than the schedule — so ask for both in writing before you integrate, and build the reconciliation job regardless of the answer. If you are running recurring crypto payments, where a missed notification compounds every billing cycle, treat it as mandatory.
Compare gateways on what they do when things break
We track service fees, settlement models, invoice windows, rate spreads and KYC requirements for every processor in the directory, so you can weigh the operational terms against the commercial ones before you wire anything into a checkout. NOWPayments is the directory's most-used gateway and documents an HMAC-SHA512 callback signature.
Compare Crypto Payment Gateways →FAQ
Why did my crypto payment gateway webhook never arrive?
Assume your endpoint refused it before you assume the gateway failed. The four common causes are all merchant-side: the endpoint returned something other than the exact response that gateway wants, it answered too slowly, it sat behind an auth layer that returned 401 or 403, or the callback URL redirected. CoinGate stops permanently on a 401, a 403 or a redirect, so an http-to-https rule on your callback URL kills every future notification silently. Check your own access log for the inbound POST first.
How many times does a crypto payment gateway retry a failed webhook?
Between five attempts and forty, and only three of the seven gateways we checked publish a schedule. CoinGate documents 40 attempts ending about six and a half days out. OxaPay documents five, the last roughly three and a half hours in. BTCPay Server retries after 10 seconds, 1 minute, then up to six times at 10-minute intervals. BitPay says only that it tries multiple times until it gives up; Cryptomus, NOWPayments and Plisio publish no schedule at all.
What HTTP response should my webhook endpoint return?
Whatever that specific gateway asks for, because they disagree and a wrong body counts as a failure. OxaPay requires HTTP 200 with the literal body ok. BitPay requires HTTP 200 with an empty body and treats anything else as failed. CoinGate accepts 200 or 204. Returning 200 with a JSON body to a gateway that wants an empty one is logged as a failure and retried, which is how a correctly processed payment gets delivered four more times.
Do crypto payment gateways sign their webhooks?
Most do, with different algorithms. NOWPayments and OxaPay both use HMAC-SHA512 (in x-nowpayments-sig and HMAC respectively), BTCPay Server sends BTCPay-Sig, and Cryptomus uses an MD5 hash of the base64-encoded body combined with your API payment key. CoinGate passes a token in the payload. BitPay does not sign at all and says so: its docs state the payload should not be trusted outright, making the notification only a trigger to re-fetch the invoice.
Can I manually resend a crypto payment webhook?
On four of the seven, and it matters more than the retry schedule because you control it. BitPay exposes POST /invoices/:invoiceId/notifications. Cryptomus has both a resend-webhook and a testing-webhook endpoint. CoinGate has a re-send tool in the dashboard under Integrations, API Management, Callback Testing. BTCPay Server can redeliver any past delivery from the webhook page in store settings. For the rest, your only route back is polling the invoice status yourself.
Is a webhook enough to mark an order as paid?
No, and BitPay's documentation is clearest on why: treat the notification as a trigger to verify through GET /invoices/:invoiceId, and note its warning that the confirmed notification may not always be sent, so watch for complete too. Any gateway that does not sign requires the same discipline, and even a signed callback can arrive out of order. Verify against the API before you release goods.
What should I build so a missed webhook does not lose an order?
A reconciliation job, which is perhaps thirty lines of code. Store every invoice you create with its gateway ID and a status, then on a schedule select the ones still open past the point where they should have resolved and call the gateway's status endpoint for each. That makes you independent of all seven retry schedules, and it is the only thing that catches the case no retry policy covers: a notification delivered successfully to a server that crashed before committing the write.
Affiliate disclosure: payyd.co earns a commission on sign-ups made through our /go/ links, including the NOWPayments link above. No gateway supplied, reviewed or saw these figures before publication. Method, so you can repeat it: every retry count, interval, timeout, response requirement and signature scheme above was read from the named company's own public developer documentation on 26 September 2026 and is quoted or arithmetically derived from it. Where a policy is unpublished we say so rather than estimating. Last updated 26 September 2026.