Crypto Payment Gateway Rate Limits 2026: We Checked 9
We read nine crypto payment gateway rate limit policies on 30 September 2026. Only two publish a number, and one sends headers it never documents.
Key Takeaways
- Two of nine gateways publish a rate limit you can code against. CoinGate states 200 requests per minute and Coinbase Business 10,000 requests per hour. NOWPayments, BitPay, Cryptomus, Plisio and BlockBee publish no number at all.
- The bigger-sounding limit is the smaller one. Coinbase Business's 10,000 an hour is 166.7 a minute; CoinGate's 200 a minute is 12,000 an hour. The gateway that quotes the larger figure gives you 20% less headroom.
- OxaPay is the only one that tells you at runtime, and the only one whose docs never mention limits. Its responses carry
x-ratelimit-limit: 100, while its published error page lists six status codes and 429 is not among them. - Our measurement: OxaPay's budget is keyed to the source IP. Across 40 calls from a rotating egress range on 30 September 2026 the remaining counter reset to 99 whenever the IP changed and stepped down only on repeats — so every server behind one NAT shares one allowance.
- 200 a minute is 33 invoices. At a ten-second poll per open invoice, CoinGate's limit supports 33 concurrent invoices and Coinbase Business's supports 27. That is the number that decides whether you poll or listen.
Table of Contents
What each gateway actually publishes
Your checkout works for a month, then a flash sale puts forty open invoices on the polling loop at once and the gateway starts refusing you — and you cannot tell whether you are over a limit because the gateway never said what the limit was. The stakes are ordinary and expensive: a refused status poll means an order that stays unpaid on your side after the customer has paid on theirs. So we went looking for the actual crypto payment gateway rate limits, and read the published developer documentation for nine processors on 30 September 2026, then called each one's unauthenticated endpoints ourselves the same day to see what the responses admit that the docs do not.
Two of the nine publish a number. Here is the whole audit in one table.
Read the “none published” rows carefully, because they are not all the same claim. BitPay's own API Integrations page covers authentication, invoice states, transaction speeds, webhooks and certification requirements, and says nothing about throughput. Plisio's documentation and BlockBee's docs site contain no instance of the words “rate limit”, “throttle” or “429” anywhere in the pages we fetched. NOWPayments is the interesting one: it confirms limits exist without quantifying them, telling merchants that if you are “currently being rate-limited, contact our support team” and it will “review your account to potentially increase the limits”. A limit that only becomes visible after you hit it is a limit you cannot design around.
CoinRemitter belongs on this list and is not on it. Its documentation host answered our client with HTTP 403 on 30 September 2026, and its public rate endpoint did the same, so we have no evidence either way about what it publishes. We would rather have nine verified rows than ten with a guess in the last one.
Two numbers, and the bigger one is smaller
CoinGate's API Limits and Quotas page is the most useful document in this niche. It gives a default of 200 requests per minute, says the limit applies to public and private endpoints alike, and prints the exact refusal you will parse: reason RateLimitExceeded, message “API request limit is exceeded”. It also names a second quota that nothing else in the niche documents — 500 orders per hour per business, refused as OrderIsNotValid with the error “Order limit exceeded (contact support to increase)”. Those are two different ceilings and a busy merchant can hit the second while nowhere near the first.
Coinbase's Coinbase Business rate limiting page gives 10,000 requests per hour per API key or app, refused with HTTP 429 and the id rate_limit_exceeded. Put the two on the same axis and the intuition inverts.
An hourly quota and a per-minute quota are not interchangeable even when they normalise to similar totals, and the difference cuts both ways. CoinGate's minute window refills every sixty seconds, so a burst costs you one minute and no more. Coinbase's hourly window means a script that loops away 10,000 requests in four minutes has nothing left for the remaining fifty-six — and neither page documents a burst allowance, so assume none.
OxaPay sends a header its own docs deny
The most informative gateway at runtime is the least informative on paper. Every response we got from OxaPay carried x-ratelimit-limit: 100 and a matching x-ratelimit-remaining. No other gateway we called returned a rate-limit header of any kind.
Now hold that against the documentation. OxaPay's error reference enumerates the status codes you should expect — 200, 400, 401, 404, 500 and 503 — and 429 is not one of them. Its introduction page does not mention rate limiting either. So the gateway is metering you, is telling you so on every single response, and has documented neither the window the counter covers nor the status code it will hand you when the counter reaches zero.
A header without a documented window is only half a signal. We know the allowance is 100 and we can watch it fall, but we cannot tell whether it refills in a second, a minute or an hour, which is exactly the parameter a backoff needs. The pragmatic reading: treat x-ratelimit-remaining as a live gauge to slow down on, not as a budget you can plan a batch against.
We measured it: the budget is per IP
OxaPay does not say what its counter is keyed to, so we measured. We sent 40 sequential unauthenticated requests to the same endpoint from a host whose outbound address rotates across a /24, and recorded x-ratelimit-remaining on each one. If the allowance were global to our account or our client, the counter would have marched down from 100 to 60. It did not. It bounced.
The 40 readings landed as follows: one at 100, ten at 99, seven at 98, six at 97, five at 96, three at 95, three at 94, two at 93, two at 92 and one at 91. That is not noise, it is a set of independent counters. The value reset to the top whenever our egress address changed and stepped down by one only when an address repeated — the signature of a per-source-IP bucket, each holding its own 100.
Our rotating egress is also the reason we cannot report the 429 threshold for any gateway on this page. Forty requests spread across roughly ten addresses is four per address, which will never trip a limit of 100. So we have not measured where any of these gateways starts refusing, and we are not going to imply otherwise. What the rotation does prove is the keying, because a counter that resets with the address is a counter indexed by the address.
For a merchant this is the finding with teeth, and it points in the opposite direction to how a per-IP limit sounds. Four application servers behind one NAT gateway do not get four allowances — they share one, and the first server to get busy starves the other three. The mirror case is just as real: a serverless deployment whose functions leave from a changing pool of addresses gets a fresh allowance per address, which means your load tests pass and a pinned-egress production environment then fails at a quarter of the traffic.
What 200 a minute buys: the polling budget
A published limit only becomes a design constraint when you convert it into the thing you actually do with it, which for a payment integration is polling open invoices for a status change. One invoice polled every ten seconds costs six requests a minute. Divide the limit by that and you get the only number that matters.
Thirty-three concurrent invoices is a modest storefront, and it is the ceiling on the gateway with the most generous published limit in this comparison. That is the argument for not polling. Every gateway here will push a status change to a callback URL instead, which costs you zero requests against the limit and removes the ceiling entirely — and the retry behaviour behind those callbacks varies from five attempts inside four hours to forty across six days, which we measured separately in our comparison of gateway webhook retry rules.
The honest version is that you need both. A webhook you never receive is indistinguishable from a payment that never happened, so a reconciliation sweep that polls anything still open after a sensible interval is not optional — it is what catches the callback your server rejected while it was redeploying. Size that sweep against the table above rather than against optimism, and remember the clock it is racing: most gateways cancel an unpaid invoice in fifteen minutes, which we covered in the invoice expiry window.
Status polling is not your only spend. Rate lookups, currency lists, payout calls, balance checks and every retry after a timeout come out of the same allowance, and CoinGate states explicitly that its 200 a minute covers public and private endpoints together — so the unauthenticated currency list you refresh on every page load is competing with your own checkout.
BTCPay's only throttle is on creating users
BTCPay Server is the outlier, because there is no vendor between you and the API. We searched the full Greenfield OpenAPI specification — a 552 KB document — for every mention of throttling, and found exactly one 429 response in the entire surface. It is not on invoices, payments, payouts or webhooks. It is on POST /api/v1/users, and its description reads: “DDoS protection if you are creating more than 2 accounts every minutes (non-admin only)”.
So a self-hosted BTCPay instance imposes no documented limit on the calls a checkout actually makes. That is a genuine advantage and it comes with the obvious transfer of responsibility: the ceiling is now your own node, your own database and whatever your host gives you, and nobody will send you a 429 before it falls over. The trade is the same one that runs through every column of a crypto payment API integration — you stop inheriting somebody else's limits and start owning your own capacity planning.
What to code against when nothing is published
Five of the nine gateways here publish nothing, which leaves you writing a client against an unknown. The generic advice circulating on this query is to back off on a 429, and it is not wrong so much as insufficient: it tells you what to do after the failure you were trying to avoid, and on at least one of these gateways the 429 is not even a documented response. Four things are worth doing instead, in this order.
Log the response headers you did not ask for. OxaPay's allowance is discoverable in one curl and is in no document anywhere. Any gateway may add the same headers tomorrow and will not announce it, so capture the full header set on a sample of responses and diff it periodically. This is the cheapest observability in the whole integration and the only reason we can report a number for OxaPay at all.
Treat every non-2xx as rate-limiting until proven otherwise. A gateway with no documented 429 has to refuse you somehow, and an undocumented throttle can surface as a 503, a connection reset or a silent timeout. If your retry logic only recognises 429 it will hammer straight through the other three, which is how a throttle becomes an outage. The status-code inventory in the seven real causes of a missing crypto payment is the map we use for this.
With no published figure, we size a client at 60 requests per minute per source IP and treat anything above it as a deliberate, monitored exception. That is under a third of the only two published limits in this comparison, it leaves room for the retries and rate lookups that share the allowance, and on the one gateway whose header we can read it sits comfortably inside the 100 that OxaPay advertises. It is a guess. The point is that it is a written-down guess with a number in it, which a backoff can be tested against and a support conversation can start from.
Assume the limit is per IP and shared. It is the keying we measured, it is the stricter assumption, and it costs nothing to be wrong about. Give each worker its own token bucket sized to a fraction of what you believe the total is, rather than letting every worker race.
Then ask, and put the answer in writing. NOWPayments explicitly invites the conversation and will raise an account's limits on a business case. A number from support is worth more than a number from a blog, ours included — and if you are still choosing, the presence of a published quota is a fair proxy for how much of the rest of the integration you will have to discover by experiment. The gateways that document their sandboxes, which we tested in our sandbox comparison, are largely the same ones that document their limits.
Check the quota before you commit the checkout
We track fees, settlement models, supported chains, invoice windows, webhook retries and developer tooling for every processor in the directory, so a published rate limit is one more column you can weigh before you wire anything. NOWPayments publishes no number but will raise your account's limits on request, which is more than five of the nine offer.
Compare Crypto Payment Gateways →FAQ
What is the rate limit for a crypto payment gateway API?
There is no industry default, and most gateways do not publish one. Of the nine we checked on 30 September 2026, only two state a figure: CoinGate allows 200 requests per minute across public and private endpoints, and Coinbase Business allows 10,000 requests per hour per API key or app. NOWPayments confirms limits exist without naming a number, and BitPay, Cryptomus, Plisio and BlockBee document nothing at all.
What is CoinGate's API rate limit?
CoinGate's API Limits and Quotas page gives a default of 200 requests per minute, applying to both public and private endpoints. Exceeding it returns the reason RateLimitExceeded with the message “API request limit is exceeded”. There is a second, separate quota that is easy to miss: 500 orders per hour per business, refused as OrderIsNotValid with the error “Order limit exceeded (contact support to increase)”. Support can raise both.
What is the Coinbase Commerce API rate limit?
The Coinbase Business documentation, which now covers the Commerce checkout APIs, gives a default of 10,000 requests per hour per API key or app. Exceeding it returns HTTP 429 with the id rate_limit_exceeded and the message “Too many requests”. Take care with figures found elsewhere for “Coinbase”: the 600-requests-per-10-seconds and 3-to-5-requests-per-second numbers that circulate belong to Coinbase's trading and platform APIs, not to the commerce checkout product.
Does NOWPayments publish an API rate limit?
No. NOWPayments confirms that limits exist but publishes no number in its API documentation or help pages. Its integration-practices page tells merchants that if you anticipate high volume or are currently being rate-limited you should contact support with details of your business case, and it will review the account to potentially increase the limits. In practice that means you cannot size a client against NOWPayments in advance; you have to ask.
Which crypto payment gateway returns rate-limit headers?
Only OxaPay, of the nine we called on 30 September 2026. Its responses carry x-ratelimit-limit: 100 and a matching x-ratelimit-remaining. CoinGate in production and sandbox, NOWPayments in production and sandbox, BitPay, BlockBee, Plisio and a BTCPay Server instance all returned none. The irony is that OxaPay's own error reference lists 200, 400, 401, 404, 500 and 503 and does not include 429, so the one gateway that meters you visibly is also the one that never documents doing it.
Is a crypto gateway rate limit per IP or per API key?
It varies, and most gateways do not say. Coinbase Business states its limit is per API key or app. CoinGate does not specify the key for its per-minute limit, though its second quota is explicitly per business. We measured OxaPay's and it is keyed to the source IP: across 40 calls from a rotating address range the remaining counter reset to the top whenever the address changed and stepped down only on repeats. Where it is unstated, assume per IP, because that is the assumption that makes several servers behind one NAT share one allowance rather than each getting its own.
How many invoices can I poll on 200 requests per minute?
Thirty-three, if you poll each open invoice every ten seconds. One invoice on a ten-second interval costs six requests a minute, so a 200-per-minute limit divides into 33 concurrent invoices, and Coinbase Business's 166.7 per minute into 27. Stretch the interval to 30 seconds and CoinGate supports 100 and Coinbase 83. Remember that rate lookups, currency lists and payout calls draw on the same allowance, so the real figure is lower than the arithmetic.
Does BTCPay Server rate limit its API?
Effectively no, for payments. We searched the whole Greenfield OpenAPI specification and found a single 429 response in the entire API surface, on POST /api/v1/users, described as DDoS protection against creating more than two accounts a minute for non-admin callers. Nothing on invoices, payments, payouts or webhooks carries a documented limit. Because BTCPay is self-hosted, the ceiling is your own server rather than a vendor quota, and nothing will warn you before you reach it.
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 findings before publication. Method, so you can repeat it: every published limit, window, scope and error string above was read from the named company's own developer documentation on 30 September 2026, and the BTCPay figure came from searching its Greenfield OpenAPI specification directly. The header audit and the OxaPay per-IP measurement are our own, taken the same day by calling each gateway's unauthenticated endpoints and recording the full response headers. We did not measure where any gateway begins refusing requests, because our outbound address rotates and a burst would have been spread across several allowances — so no 429 threshold on this page is presented as measured. Where a gateway publishes no policy we say so rather than estimating. Last updated 30 September 2026.