Is Stripe down right now?

How to check Stripe API status

When payments stop going through, the first question is whether Stripe itself is having problems or whether the issue is in your integration. The fastest way to find out is to check from outside your own infrastructure.

The tool above tests Stripe's status page from our servers. If it responds quickly with a 200 status, Stripe's infrastructure is likely healthy. For more detailed information, visit the official Stripe status page, which breaks down the health of individual components like the API, Dashboard, Checkout, and webhooks.

Keep in mind that Stripe's status page may show "operational" even when you're experiencing issues. If your specific API calls are failing but the status page looks fine, the problem is more likely in your integration, authentication, or network.

Common Stripe API errors and what they mean

Not all Stripe failures are outages. Understanding the difference between error types helps you respond correctly and avoid unnecessary panic.

• HTTP 400 (Bad Request) — your request has a problem: missing required fields, invalid card number, or malformed JSON. This is a code issue, not an outage.
• HTTP 401 (Unauthorized) — your API key is invalid, expired, or you're using a test key in production. Double-check your configuration.
• HTTP 402 (Request Failed) — the request was valid but the payment failed. The card was declined, insufficient funds, or fraud was detected. Not an outage.
• HTTP 429 (Rate Limited) — you're making too many requests. Back off and retry with increasing delays.
• HTTP 500, 502, 503 (Server Error) — Stripe's servers are having trouble. These are the errors that indicate a genuine Stripe-side problem. Retry with backoff.
• Timeout (no response) — the request was sent but no reply came back. Critical: the payment may or may not have been processed. Always check before retrying.

Retry strategies and exponential backoff

When Stripe returns a 5xx error or times out, retrying is the right approach — but you need to do it safely. For payment-related endpoints, this is especially critical because a retry without proper safeguards could charge a customer twice.

Always use idempotency keys. Stripe supports an Idempotency-Key header on all POST requests. If you send the same key twice, Stripe returns the original response instead of processing the request again. This is your safety net against duplicate charges.

Use exponential backoff. Start with a 1-second delay after the first failure. Double it on each subsequent retry: 1s, 2s, 4s, 8s, up to a maximum of 30 seconds. Add a small random jitter (50–200ms) to avoid thundering herd problems where all your retries hit Stripe simultaneously.

Know when to stop. After 3–5 retries, stop and surface the error to the user. If Stripe is genuinely down, retrying indefinitely wastes resources and delays the user experience. Show a clear message like "Payment processing is temporarily unavailable" instead.

When to check Stripe's status page vs your own code

A helpful rule of thumb: if the problem affects all your Stripe API calls across all endpoints, it's likely a Stripe-side issue. If it only affects specific endpoints or specific customers, the problem is probably in your code.

• Check Stripe first if: all API calls are failing, you see 500/502/503 errors, or webhooks have stopped arriving.
• Check your code first if: only one endpoint fails, you see 400/401 errors, or the issue started after a deployment.
• Check your network if: you get timeouts or DNS errors but Stripe's status page shows green. See our guide on API timeout vs DNS error for help diagnosing this.