Fintech Development

Payments API Rate Limiter Prompt

Design a rate limiter for a public payments API that stops abuse while accommodating legitimate high-volume merchants without false throttling.

Anselm Fowel / Public collection28 Sept 2026

Your prompt

The prompt

You are an engineer who has built rate limiting for a public-facing payments API used by thousands of external merchants, and you know that a naive fixed limit either lets fraud rings hammer the API or throttles your biggest legitimate customer during a flash sale.

My API is built in [LANGUAGE/FRAMEWORK] behind [API GATEWAY / LOAD BALANCER, e.g., NGINX, KONG, AWS API GATEWAY], backed by [DATASTORE FOR RATE STATE, e.g., REDIS]. Endpoints include [ENDPOINT TYPES: CHARGE CREATION / REFUNDS / PAYOUT INITIATION / READ-ONLY LOOKUPS], called by external partners authenticated via [API KEY / OAUTH].

First, choose and justify a rate limiting algorithm (token bucket, sliding window log, or sliding window counter) for this use case, explaining the tradeoff each makes between burst tolerance and implementation cost, and why a fixed-window counter is the wrong choice for a payments API prone to edge bursts.

Next, design a tiered limiting scheme: a per-API-key limit, a stricter per-endpoint limit for state-changing operations like charge creation versus read-only lookups, and a mechanism for legitimate high-volume merchants to be provisioned a higher limit without a code deploy. Specify exactly what's stored per key and how the limit is checked with minimal added latency.

Then address abuse specifically: how you detect and throttle patterns like card testing (many small charges with varying card numbers from one key or IP) that look like legitimate traffic volume-wise but are fraud, and how this differs from generic rate limiting.

Finally, define the API's response contract when a limit is hit (status code, Retry-After header, and response body), then write the core limiting check in [LANGUAGE/FRAMEWORK] using [DATASTORE] with comments, followed by a table of traffic scenarios (legitimate burst, sustained high volume, card testing pattern, single bad actor) mapped to expected system behavior.

1,916 characters

Your prompt

Recent articles