Across the 11 payment services StatusBird monitors, the last 90 days produced 1,632 minutes of major or critical downtime, and one service caused 1,548 of those minutes. Plaid averaged 387 minutes per incident, roughly six and a half hours, while Affirm's single incident lasted 22 minutes. Uptime percentage told you almost nothing useful here; incident length told you everything.
These figures come from StatusBird's independent 2-minute monitoring over the 90 days ending September 21, 2026.
What did payment services actually do over the last 90 days?
Only three of the 11 monitored payment services recorded a major or critical incident in the window. Here is the full category, ordered by total downtime.
| Service | Uptime | Grade | Major/critical incidents | Total downtime | Avg incident | Last incident |
|---|---|---|---|---|---|---|
| Plaid | 98.8% | C | 4 | 1,548 min | 387 min | 2026-08-03 |
| Sezzle | 99.95% | A+ | 1 | 62 min | 62 min | 2026-07-05 |
| Affirm | 99.98% | A+ | 1 | 22 min | 22 min | 2026-08-10 |
| Adyen | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
| Afterpay | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
| Authorize.net | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
| Braintree | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
| Klarna | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
| PayPal | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
| Square | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
| Stripe | 100.0% | A+ | 0 | 0 min | 0 min | None in window |
Plaid accounts for about 95% of all payment-category downtime in the window, and its 98.8% uptime is the lowest figure in the entire monitored set of 84 services. It was also the most affected service in the outage index for August 2026, a month that logged 16 major or critical incidents and 40.4 combined hours of downtime across nine services.
Why does average incident length matter more than uptime percentage?
Uptime percentage is a summary of how much of the quarter a service was up. It does not tell you what a single bad afternoon looks like, and a single bad afternoon is what breaks your checkout.
Compare two services with similar totals. Plaid recorded 1,548 minutes across 4 incidents, an average of 387 minutes each. Shippo, in the shipping category, recorded 1,344 minutes across 10 incidents, an average of 134 minutes each. Similar totals, completely different operational problem. Shippo hands you ten interruptions of roughly two hours; you feel them often, but each one ends inside a normal work session. Plaid hands you four interruptions averaging over six hours; you feel them rarely, but when one starts in the morning it can still be running at dinner.
That difference changes what you do in the first ten minutes. A two-hour average failure is something you wait out with a support macro. A six-hour average failure is something you route around, because by the time it clears you have lost most of a trading day on whatever it powered.
Downtime shape, by the numbers in this window
- Few and long: Plaid, 4 incidents, 387 min average. Build a bypass.
- One and short: Affirm, 1 incident, 22 min. A 2-minute check interval catches it; your customers may not.
- One and moderate: Sezzle, 1 incident, 62 min. One support macro and a checkout note covers it.
- None recorded: Adyen, Afterpay, Authorize.net, Braintree, Klarna, PayPal, Square, Stripe. Zero major or critical incidents in 90 days does not mean zero risk going forward, only that this window was clean.
What does a 387-minute average mean for a store using Plaid?
Plaid typically sits behind bank-account connection flows: ACH and bank-debit payment methods, payout and onboarding verification, and any app that reads bank data for financing or reconciliation. When it fails, card payments usually keep working, which is why a Plaid outage often reads internally as "a few customers complained" rather than "the store is down."
With an average incident of over six hours, the practical exposure is a full day of bank-based checkouts failing for the subset of customers who prefer that method, plus any new customer onboarding that depends on account verification. If bank debit is 5% of your orders, that is 5% of a day. If you sell high-ticket items where customers choose ACH to avoid card limits, the share of revenue at risk is far larger than the share of orders. You can check the current state on the Plaid status page and the incident pattern on its reliability history.
How should this change your checkout fallback plan?
Rank your payment dependencies by average incident length, not by uptime, then write the specific action for each one.
- List which methods depend on which vendor. Open Shopify admin, go to Settings, then Payments, and write down every provider and additional method that is active, including bank debit, BNPL, and wallets. Note which of them route through a bank-linking provider.
- Keep one card path that shares no dependency with your bank-debit path. In this window, Adyen, Authorize.net, Braintree, Square, and Stripe all recorded zero major incidents, so a card fallback is a realistic second lane. StatusBird is not affiliated with any of these providers.
- Write the deactivation order in advance. For each method, record the exact admin path and the toggle you will flip, so nobody has to hunt for it mid-incident. Deactivating a broken method is usually better than letting customers hit an error at payment.
- Set your banner threshold by average incident length. For a vendor averaging 387 minutes, publish a checkout note immediately. For a vendor averaging 22 minutes, hold off and let the alert resolution close it out.
- Log the minutes. Record start and end times for every vendor incident that hits you. Total downtime per vendor per quarter is the number you need when you renegotiate or ask for credits.
What these numbers do not tell you
Eight of 11 payment services showed 100.0% uptime and zero major or critical incidents in this window, and that is a real result, not a rounding trick. It is also only 90 days. The monthly index shows how much variance a quarter hides: April 2026 alone carried 20 major or critical incidents and 122.1 hours of combined downtime across 11 services, while March 2026 carried 2 incidents and 8.3 hours. A clean quarter for a vendor is evidence, not a guarantee.
Degraded performance also sits outside these counts. This data covers major and critical incidents against reachability and response, so a provider that is slow but answering, or failing only on one card network, may not appear. If you want the exact definitions and check cadence, they are documented on the methodology page, and you can compare any single vendor over time on its reliability history, for example Affirm or Sezzle.
If you want to know when a payment dependency starts failing instead of finding out from a customer email hours later, StatusBird checks these services every 2 minutes and can send the alert by SMS, email, Slack, Teams, or Discord. You can set up monitoring here and pick only the vendors your checkout actually touches.