Payments on Sale Day: Rate Limits, Load Tests and Fallbacks Before Peak Traffic

What breaks under peak load

Rate limits: the ceiling you can't see until you hit it

• Find your actual limits in your providers' documentation or from your account manager, for every endpoint you call at checkout, not just create-payment.
• Count all the calls a payment makes. A single payment can mean a create call, one or more status checks, a capture for cards, and later a refund or two. Status checks are often the biggest share.
• Ask for higher limits well before the event if your estimate gets close. Providers usually need notice.
• Throttle on your side, so bursts are smoothed before they reach the provider, rather than discovering the limit through rejected payments.
• When you do get a 429, wait (honouring Retry-After if present), then retry with the same idempotency key. Never retry immediately in a tight loop.

// Allows short bursts up to "capacity", then a steady "ratePerSec".
class TokenBucket {
  private tokens: number;
  private last = Date.now();

  constructor(private capacity: number, private ratePerSec: number) {
    this.tokens = capacity;
  }

  async take(): Promise<void> {
    for (;;) {
      const now = Date.now();
      this.tokens = Math.min(this.capacity, this.tokens + ((now - this.last) / 1000) * this.ratePerSec);
      this.last = now;
      if (this.tokens >= 1) {
        this.tokens -= 1;
        return;
      }
      const waitMs = ((1 - this.tokens) / this.ratePerSec) * 1000;
      await new Promise((resolve) => setTimeout(resolve, waitMs));
    }
  }
}

// Keep a margin below the provider's documented limit.
const createPaymentBucket = new TokenBucket(20, 15);

async function createWithProvider(payload: PaymentRequest, key: string) {
  await createPaymentBucket.take();
  return provider.createPayment(payload, { idempotencyKey: key });
}

Estimate your peak on paper first

1. Start from the busiest minute you expect: the number of orders, from last year's sale or your marketing forecast.
2. Divide by 60 for orders per second at that peak, and allow for bursts within the minute: traffic is spikier than an average suggests.
3. Multiply by attempts per order, since some customers retry or switch methods.
4. Multiply by API calls per attempt (create, status checks, capture) for each endpoint, and compare each endpoint's figure with its limit.
5. Do the same for inbound webhooks: events per payment times payments per second is the rate your endpoint must absorb.

Load testing without hammering a provider

• Load test your own stack against a stub that imitates the provider: realistic response times (including a slow tail), occasional errors, 429s when you exceed a configured rate, and webhooks fired back at your endpoint.
• Test the whole checkout, from basket to confirmation page, because the bottleneck is often before the payment call.
• Test webhook ingestion separately at several times your expected peak rate, including duplicates and out-of-order events.
• Run a small number of real end-to-end payments on production with each method before the event, to confirm configuration rather than capacity.
• If you need to test against a provider's systems at volume, agree it with them first.

Make overload graceful

• Queue and shed load at the edge (a waiting room or a short queue before checkout) rather than letting every request pile onto the payment step.
• Cap concurrent calls to each provider, so a slow provider can't tie up all your workers. Time out deliberately, and treat a timed-out payment as unknown. Our guide to payment API timeouts explains why.
• Back off with jitter when a provider returns 429 or 503, so your retries don't arrive as a synchronised wave.
• Keep a second provider for your main methods if your volume justifies it, with routing rules ready to shift a share of traffic. Our incident runbook covers moving traffic safely.

A readiness timeline

Don't forget the money after the sale

Frequently asked questions