Stripe's Swish payment method returned elevated errors for 6h 36m on 6 October 2026. Stripe says the cause was its own scheduled maintenance, not anything in your integration.
Started
00:30 UTC
Duration
Lasted 6h 36m
Source
IsDown
Next time
Stripe is degraded. Is your product working?
An incident on their side does not always mean an outage on yours, and the only way to know is to already be watching your own endpoints. Set that up in under a minute and you will be notified the next time your own site is affected. And there will be a next time.
50 monitors for your own websites. No card.
Affected components: Acquirers and payment methods
What happened?
Stripe's status page opened an incident at 00:30 UTC titled "Elevated Swish errors", affecting the Acquirers and payment methods component. The first update said that as of 00:28 UTC it had seen elevated errors on Swish payments and that it was continuing to investigate. No further updates followed until resolution at 07:04 UTC, nearly seven hours later. That final update narrowed the actual error window to 00:00 to 03:00 UTC and attributed it to scheduled maintenance on Stripe's side. So the incident was open on the status page for 6h 36m, but Stripe's own account of the fault window is shorter, roughly three hours, with the rest being the gap before they confirmed resolution. There is no mid-incident update explaining what the maintenance touched or why it produced errors on Swish specifically rather than other payment methods. No user reports were filed during the window on this page. Stripe's 90 day history shows 27 incidents with a median duration of 1 hour 20 minutes, so this one ran well past that typical length. Across all time Stripe has logged 237 incidents, averaging 3.6 a month, which gives some sense of how routinely this status page gets updated.
Learning
UptimeRobot's own probes against Stripe's API, run from EU and NA regions every 60 seconds, show 100% uptime over 24 hours, 7 days and 30 days, and this incident was not registered against those checks. That is not a contradiction. The fault here sat inside one payment method, Swish, within the Acquirers and payment methods component, a narrow slice of Stripe's surface that a general API availability check has no way to see. Your own monitoring of your integration would show the same clean result, because your endpoints were never the problem, Stripe's downstream handling of one payment method was. This is a common shape for payment platform outages: the core API answers normally while a specific method or region quietly fails behind it. If you process Swish payments, transactions in that window could have failed or errored without any sign of it in your own uptime checks. Your monitoring covers your half, UptimeRobot now watches the provider's half too, so next time you know which side broke without guessing.
