Throttling is the deliberate limiting of how fast a system accepts or processes requests, transactions or jobs, by delaying, queuing or rejecting anything above a set rate. In payments it protects card processors, banking cores and open banking APIs from overload, stops one heavy client degrading service for others and contains card-testing bots. Most APIs use a token bucket that refills at a fixed rate and rejects excess calls with HTTP 429 and a Retry-After header, with limits per key, merchant, endpoint and globally. PSD2 standards cap background account data pulls by an AISP at four in 24 hours. Clients should retry with exponential backoff, and 429 rates show how much headroom a platform has.
How does API throttling work
Most APIs implement throttling with a token bucket. Each client has a bucket that refills at a fixed rate, say 100 tokens per second, up to a maximum of 200. Every request consumes a token; if the bucket is empty the request is rejected with HTTP 429 Too Many Requests, usually with a Retry-After header telling the client how long to wait. The bucket size allows short bursts while the refill rate enforces the long-run average.
Limits are applied at several layers: per API key, per merchant account, per endpoint (a refund endpoint is usually tighter than a balance check) and globally. A sliding window counter is the common alternative when a provider wants a strict "1,000 requests per minute" rule rather than burst tolerance.
Throttling vs rate limiting
The terms overlap and many providers use them interchangeably. Where a distinction is drawn, API rate limiting is the published quota a client may use, while throttling is the enforcement behaviour when traffic approaches or exceeds it: slowing responses, queuing, or shedding load. A gateway can throttle every client during an incident even when no individual client has broken its quota.
Throttling in open banking and card payments
Regulation sets some limits directly. Under the PSD2 regulatory technical standards on SCA and secure communication, Article 36(5)(b), an account information provider can pull a user's account data no more than four times in 24 hours when the user is not actively requesting it, unless the provider and the bank agree a higher frequency with the user's consent. Banks enforce this cap by throttling background calls, which is why an AISP sees refusals after the fourth overnight refresh.
On the merchant side, throttling is a fraud control. A checkout receiving 600 card authorisations in two minutes from one IP range, most with different card numbers and small amounts, is likely under a card-testing attack; limiting attempts per IP, device and BIN cuts the number of authorisations the merchant pays for and the issuer declines it accumulates.
Handling throttling as a client
Clients that ignore 429 responses and retry instantly make outages worse. Sound retry logic uses exponential backoff with jitter, respects Retry-After, and pairs with a circuit breaker so a payment platform fails over to another provider rather than hammering one that is shedding load. For an acquirer of a payment gateway, throttling configuration and 429 rates per partner are a quick measure of how much headroom the platform has before volume growth needs new infrastructure.
See also: API throttling.