Payment Gateway Rate Limits: How to Keep a Sale-Day Checkout Working
Short Answer
Payment gateways cap API requests per second and answer with 429 errors when you exceed them. Use exponential backoff, idempotency keys and fewer unnecessary calls so a sale-day rush does not duplicate or lose orders.
A White Friday campaign goes live at midnight, and within minutes checkout starts showing errors. The payment gateway itself is healthy. Your store is simply sending more requests per second than your gateway account is allowed. That is a rate limit, and it looks exactly like an outage to the customer staring at a spinning Pay button on her phone.
Rate limits are normal, published and predictable, which means a developer can design around them in advance. This guide explains what payment gateway limits are and how 429 errors appear to shoppers. It then covers the retry, idempotency and queueing patterns that keep orders correct under load. Stripe's documentation is used as the worked example, because its limits are published.
What is a payment gateway rate limit?
A rate limit caps how many API requests your account can send in a set period. When your store exceeds it, the gateway answers with HTTP status 429, Too Many Requests. The request is refused before processing, so nothing was charged by that request.
Stripe's documentation, checked in September 2026, lists a global live-mode limit of 100 requests per second. Most individual endpoints have their own limit of 25 requests per second. Sandbox limits are lower, at 25 requests per second globally, so test environments hit limits sooner than production.
Quick Answer
A payment gateway rate limit caps API requests per second, returning HTTP 429 when exceeded. Stripe lists 100 requests per second in live mode and 25 per endpoint by default.
Why do stores hit limits during a sale?
Stores rarely hit rate limits from genuine purchases alone. They hit them because each checkout makes several avoidable calls, such as fetching the same customer record or payment status repeatedly. Background jobs, like report exports or subscription syncs, then compete for the same account limit.
The worst pattern is polling, where the page asks the gateway for payment status every second. Multiply that by hundreds of open checkout pages and the account limit disappears within seconds. Webhooks replace most polling, because the gateway tells your server when something changes instead.
Quick Answer
Stores usually hit gateway rate limits through repeated status polling and background jobs, not purchases alone. Replacing polling with webhooks removes most of these avoidable API requests during peak traffic.
How should the store retry a refused request?
Retry with exponential backoff, which means waiting longer after each failed attempt. Stripe's documentation recommends adding randomness to those waits so thousands of retries do not arrive together. Stop after a small number of attempts and show the shopper a clear payment pending message.
Retrying immediately in a tight loop makes rate limiting worse, because each retry is another request. If the gateway sends a Retry-After header, respect it before trying again. Keep retries on your server, not in the shopper's browser, so one impatient customer cannot multiply the load.
Quick Answer
Handle HTTP 429 errors with exponential backoff and random jitter, as Stripe recommends. Respect any Retry-After header, cap the total number of attempts and keep retry logic on your server.
How do idempotency keys prevent double charges?
An idempotency key is a unique value that lets the gateway recognise a repeated request. If a timeout hides whether the first charge succeeded, retrying with the same key returns the original result. The customer is charged once, however many retries happen.
Stripe's reference says keys can be up to 255 characters and suggests random values such as version 4 UUIDs. Keys can be removed after at least 24 hours, so do not rely on them for later retries. Never put email addresses or other personal data inside the key.
Quick Answer
Idempotency keys let a gateway recognise repeated requests and return the first result, preventing double charges. Stripe accepts keys up to 255 characters and advises random values without personal data.
How do you prepare a checkout for peak traffic?
Count the API calls one checkout makes, then remove the unnecessary ones before the sale. Cache product and price data locally, confirm payments by webhook and queue non-urgent jobs until after peak hours. Ask your gateway account manager about limit increases well before the campaign starts.
Be careful with load tests. Stripe discourages load testing against its sandbox, because sandbox limits are lower and results can mislead. Test your own code with a mocked gateway instead, then run a small live rehearsal with real cards and refunds before launch day.
Quick Answer
Before a UAE sale, cut unnecessary gateway calls, confirm payments by webhook and postpone non-urgent background jobs. Load test against a mocked gateway, because Stripe's sandbox limits are deliberately lower.
Main Takeaways
Payment gateways cap requests per second and return HTTP 429 when stores exceed them. Stripe lists 100 live requests per second globally and 25 per endpoint by default. Replace polling with webhooks, retry with exponential backoff and jitter, and use idempotency keys to prevent double charges. Load test against a mocked gateway, because Stripe's sandbox limits are lower than live.
Getting ready for your next sale
Pick your busiest expected hour of the campaign and estimate orders per minute. Multiply that by the API calls each checkout makes, then compare the result with your gateway's published rate limits. If the numbers are close, reduce calls before the campaign rather than hoping for luck. Removing status polling alone can bring a busy store well under its limit.
Our custom development team reviews payment integrations for UAE stores and fixes retry and confirmation logic. We also help plan safe load tests against a mocked gateway before launch day. Read how checkout architecture keeps orders on the server, and how to diagnose 3-D Secure drop-off. Share your campaign date and payment gateway so we can plan the review early.
Sources & References
FAQs
Questions readers usually ask next
These FAQs are written to match the topic of this post and to help readers move from understanding to action.
Does a 429 error mean the customer was charged?
No, a 429 response means the gateway refused that specific request before processing it. Still confirm the order status by webhook, because a different, earlier attempt may have already succeeded.
Are rate limits the same for every payment gateway?
No, each provider sets its own limits and some vary by account or endpoint. Ask your chosen gateway for its documented limits and whether they can be raised for campaigns.
Should the checkout button be disabled after one click?
Yes, it reduces accidental double submissions from an impatient shopper's browser. But it cannot stop server retries, network timeouts or repeated webhooks, so idempotency keys remain essential on the server.
Do we need a message queue for payment requests?
Small stores usually do not, if polling is removed and retries use exponential backoff. A queue helps when background jobs and checkout traffic compete for the same gateway account limit.
Can a pending payment reserve stock?
Yes, for a short, clearly defined window that matches your slowest payment methods. Release the stock automatically if the gateway reports failure or the window expires without any confirmation arriving.
What should support see during a rate-limit incident?
Support needs a list of orders stuck in pending status with gateway references. Clear status labels let staff reassure customers instead of promising payments that the system cannot yet confirm.
Why do lock timeout errors look like rate limits?
Stripe returns a 429 status for some lock timeouts, when several concurrent requests change the same object. Its documentation recommends queueing changes to one object sequentially and retrying with backoff.
Should failed retries continue running overnight?
No, cap automatic retries, then move remaining cases to a reconciliation list for staff to review. Endless retries waste limits and can act on orders that customers have already abandoned.
How do webhooks reduce gateway API calls?
The gateway sends your server an event when a payment changes, so your store stops asking repeatedly. One webhook notification replaces dozens of status checks from every open checkout page.
What should a developer show before a campaign launch?
Ask for a count of gateway API calls per checkout and the retry configuration. Also request evidence of a live rehearsal covering a payment, a refund and a simulated timeout.
Related Resources
Need help deciding whether to keep a platform or go custom?
We help UAE businesses scope the checkout, data model, and integrations before they commit to a stack that is too heavy or too limited.
Built for stores where pricing, inventory, or delivery rules need more control than a default template gives.
