Is Stripe down?

Understanding Stripe availability

Stripe availability is not a single yes-or-no condition. A problem may affect payment processing, Checkout, dashboard access, or requests sent to api.stripe.com, and those surfaces can fail for different reasons.

The official Stripe status page is the best first check for a reported service-wide incident. Compare an incident's timing and affected component with your logs, including the endpoint, region or payment operation where available. A clear status page does not rule out an account configuration issue, deployment problem, local connectivity failure or integration-specific error.

Troubleshooting Stripe problems

1. Check for a reported Stripe incident

Open the official Stripe status page and look for an incident matching the affected Stripe component and time. If an incident is active, monitor its updates, avoid broad configuration changes, and preserve failed request details for later review.

If no matching incident appears, treat the problem as potentially localized and continue with the checks below. A clear status page cannot exclude an account, deployment, integration or network problem.

2. Identify the failing Stripe surface

Determine where the failure occurs:

• Dashboard or account access: Test the dashboard in a private browser window and, where appropriate, ask another authorized user whether the same account pages fail.
• Checkout or payment flow: Establish whether the error occurs in the browser before your server contacts Stripe, during the API request, or after your application receives a response.
• API requests: Record the HTTP status, response body, endpoint, timestamp and any request or error identifier. Confirm that the request targets api.stripe.com and whether the behavior is reproducible.

A message such as “payment failed” may represent a card decline, invalid request, account setting or application error rather than a Stripe-wide outage.

3. Separate network and connectivity failures

If requests to api.stripe.com time out or cannot establish a connection, compare the behavior from a second network or deployment environment. Check DNS resolution, outbound HTTPS access, firewall rules, proxy settings and TLS inspection in the affected environment.

If the same request works elsewhere, the cause is more likely to be local to the original network, host or deployment. For HTTP 502, 503 or 504 responses, use application and server logs to determine whether the response came from Stripe, your hosting layer, a reverse proxy or an API gateway. Use only a safe, authenticated test when reproducing the request.

4. Check browser, account and integration causes

For a dashboard or Checkout issue limited to one browser, clear site-specific data or test a private window, then compare with another supported browser or device. If the issue follows the account rather than the browser, have an authorized user review account access and permissions.

When Stripe appears available but one account or integration fails, review the affected environment, API credentials, permissions, webhook handling, request parameters and recently changed configuration. Compare test and live behavior only when safe and appropriate. A failure limited to one endpoint, merchant account, payment method or deployment is less consistent with a general Stripe outage.

Never expose secret API keys in browser reports, tickets or logs. Redact payment information and credentials before sharing diagnostic output.

5. Retry carefully and escalate with evidence

For transient network or server responses, follow the retry behavior defined by your integration and avoid duplicate payment operations. Use idempotency protection where your integration supports it, and verify the resulting payment state before attempting another charge.

If the status page shows no matching incident and the issue persists, collect the timestamp and time zone, affected environment, endpoint, HTTP status, sanitized response, request or error identifier, and whether the issue reproduces from another network. This evidence is more useful than repeated blind retries.