Stripe API Rate Limits for Payment Processing
Learn about Stripe API rate limits for read and write operations. Understand how Stripe handles rate limiting for payment processing and webhook delivery.
Detailed Explanation
Stripe API Rate Limits
Stripe's rate limits are designed to handle the bursty nature of e-commerce traffic while protecting the payment infrastructure.
Default Rate Limits
| Operation Type | Limit | Notes |
|---|---|---|
| Read (GET) | 100/s | Per API key |
| Write (POST/DELETE) | 25/s | Per API key |
| Search | 20/s | Per API key |
| Files upload | 20/s | Per API key |
How Stripe Rate Limits Work
Stripe uses a per-second sliding window approach. Unlike hourly or daily limits, Stripe's limits are enforced at the second level, which means:
- You cannot "bank" unused requests
- Each second is evaluated independently
- The limit applies per API key (live or test)
Rate Limit Response
When rate limited, Stripe returns:
HTTP/1.1 429 Too Many Requests
Retry-After: 1
{
"error": {
"type": "rate_limit_error",
"message": "Too many requests..."
}
}
Design Patterns for High-Volume Stripe Usage
- Webhook-first architecture: Use webhooks instead of polling for status changes
- Batch operations: Use Stripe's batch endpoints where available
- Read caching: Cache customer, product, and price data locally
- Write queuing: Queue non-urgent writes (like metadata updates) and process at a controlled rate
- Idempotency keys: Always use idempotency keys for write operations to safely retry after rate limits
Webhook Delivery Limits
Stripe also rate limits webhook delivery:
- Initial delivery: immediate
- Retries: up to 3 days with exponential backoff
- Maximum: 8 retry attempts per event
Use Case
You are running a flash sale that expects 10,000 orders in 5 minutes. Each order requires 3 Stripe API calls (create payment intent, confirm payment, update metadata). You need to verify that your order volume stays within Stripe's rate limits and design a fallback strategy.