Rate Limiting a Payment Gateway in Production

Rate limiting a payment gateway isn't like rate limiting an API. When you throttle an API call, the user gets a 429 and retries. When you throttle a payment, money is involved. Getting this wrong means either leaving the system vulnerable to abuse or accidentally rejecting legitimate transactions.

The Dual Nature of Payment Rate Limits

Payment gateways need two distinct rate limiting strategies. The first is per-merchant — preventing any single merchant from overwhelming the system. The second is per-endpoint — protecting specific payment operations that have higher cost or risk profiles. A refund endpoint needs tighter limits than a balance check.

Algorithm Selection

We tested token bucket, sliding window, and fixed window algorithms. Token bucket won for payment processing because it handles bursts gracefully — a merchant can process a surge of transactions as long as their average rate stays within bounds. Sliding window was better for administrative endpoints where consistent spacing matters more than burst tolerance.

The Production Incident

The moment that taught me the most: we deployed rate limiting with a Redis-backed counter, and Redis had a brief network partition. The rate limiter defaulted to open (allowing all traffic) — the safe default for payments. But our monitoring wasn't configured to alert on the fallback path. We ran without rate limits for 12 minutes before anyone noticed. No damage was done, but it exposed a gap between our fail-safe design and our observability.

Lesson learned: rate limiters need three monitoring dimensions — the rate limit decisions themselves, the health of the rate limit infrastructure, and the proportion of traffic going through each decision path. All three must be alertable independently.