Rate Limiting

Rate limiting is the practice of restricting how many requests a client can make to a service within a set time, for example 100 requests per second for each account. When the limit is reached, further requests are refused or delayed until the client's allowance refills. Almost every public application programming interface applies some form of it.

In payments the control has two jobs. It protects shared systems from being overloaded by one customer's traffic, and it slows down automated abuse such as attempts to guess card details. It is normally enforced at an API gateway in front of the payment platform, and the limits are published in the provider's developer documentation and sometimes written into contracts.

A payment processor serves thousands of merchants on shared infrastructure, and behind that infrastructure sit card networks, banks and other third parties that have capacity limits of their own. A single merchant with a faulty integration that resends the same call in a tight loop, or one running an unannounced flash sale, could consume enough capacity to delay authorizations for everyone else. Limits keep each customer within a fair share and give the platform predictable load.

Limits are also a security measure. In a card testing attack criminals submit large numbers of small authorizations to find which stolen card numbers are valid. Credential stuffing against login pages and attempts to enumerate account numbers follow the same pattern of very high request volume. Capping requests per key, per address or per card does not stop these attacks, but it makes them slower and more visible. It also offers some protection against a distributed denial-of-service attack.

A limit has three parts: what is being counted, who it is counted against, and the time window. Providers usually count requests per API key or account, and often add separate limits per endpoint, per source address or per end customer. Read operations such as fetching a balance tend to have higher limits than write operations such as creating a payment. The sandbox used for testing normally has much lower limits than the production environment.

Some platforms add concurrency limits, which cap the number of requests in progress at one moment, and business limits such as a maximum number of payouts per batch. Large customers can usually negotiate higher limits, particularly ahead of known peaks such as holiday sales.

Several standard methods are used to count requests.

• Fixed window. Requests are counted in set intervals, such as each calendar minute, and the counter resets at the boundary. It is simple but allows a burst at the edge of two windows.
• Sliding window. The count covers the most recent interval measured from the current moment, which smooths out the boundary problem at the cost of more bookkeeping.
• Token bucket. Each client has a bucket that fills with tokens at a steady rate up to a maximum. Every request spends a token. This permits short bursts while holding the long-run average to the refill rate.
• Leaky bucket. Requests join a queue that is drained at a constant rate, so output is steady and excess requests are dropped when the queue is full.

On a REST API a refused request normally returns the HTTP status code 429, Too Many Requests. Many providers include response headers that state the limit, the number of requests remaining and when the allowance resets, or a Retry-After value giving the number of seconds to wait.

A well-built integration treats this response as a signal to slow down, not as a payment failure. The usual approach is to retry after a delay that grows with each attempt, known as exponential backoff, with some random variation so that many clients do not all retry at the same instant. For payment creation, each retry should carry the same idempotency key so that a request which did reach the server is not processed twice. Clients with heavy workloads, such as a batch payout to thousands of recipients, generally place the work on a message queue and release it at a pace below the limit.

A marketplace pays 20,000 sellers every Friday through a payout API that allows 25 write requests per second. If its system fires all the requests at once, most are rejected with status 429 and the job must be rerun. Instead, a worker process takes payout instructions from a queue at 20 per second, sends each with its own idempotency key, and pauses when a rejection is received. The run finishes in under 20 minutes with no duplicates and without affecting the marketplace's checkout traffic, which uses a separate key and allowance.

Rate limits are blunt. Set too low, they block legitimate peaks and cause lost sales. Set per source address, they can penalize many users who share one address and be evaded by attackers who spread traffic across many. They are therefore combined with other controls, including bot detection, a velocity check on cards and accounts, and fraud scoring.