Payment providers grade their own outages. Here's what they actually disclose.

Key findings

• 3 of 19 providers publish no machine-readable incident history – PayPal, Checkout.com and Braintree. (Mollie was in this list until a 2026-07-23 re-check found its Instatus incident feed – see the correction log.)
• Stripe's machine-readable history exists – on a domain its own status page doesn't mention. status.stripe.com exposes no API and an RSS spanning ~55 days of mostly scheduled maintenance; the standard status API (50 incidents over 254 days) is served only from the legacy domain stripestatus.com. We initially misclassified Stripe as opaque because of this – see the correction log. Discoverability of the disclosure surface is itself part of transparency.
• Visible history depth varies 350-fold among providers that do publish: from 7 days (Twilio's most recent 50 incidents) to 2,460 days (Shopify). Among PSPs, Adyen is the deepest at 1,263 days.
• Adyen publishes the deepest PSP history but no resolution timestamps– 0% of its 129 visible incidents carry one, against 92–100% for the other 13 providers. It exposes a resolved flag and a status timeline instead.
• There is no shared severity language. The 14 providers use 7 distinct severity taxonomies – from none/minor/major/critical to colour codes – so "major incident" means different things on different status pages.
• Incident counts are not comparable across providers – and any ranking built on them would be wrong. Worldpay's most recent 50 incidents span 50 days; Stax's span 879. That reflects posting practice, not reliability.

Why this matters

Status pages are the only public record of payment-infrastructure incidents, and they are curated by the very vendor whose uptime they describe. That is a problem in the two moments that matter most. In procurement, a status page is the only independent-looking source you can check – and for 3 of the 19 providers we assessed, there is nothing machine-readable to check at all. And during an actual incident, it is the worst place to first learn you have a problem: it updates on the provider's schedule, in the provider's language, and in the provider's interest, while your revenue moves in real time. This is the evidence behind advice we had already published from practitioner experience: trust your own metrics over their status page.

The transparency table

What each provider's public status surface exposed on 2026-07-17. "Window" is the number of days spanned by the provider's visible incident history – for status-page APIs this is the ~50 most recent posts, so it measures disclosure practice, not incident frequency. Mollie's row is a 2026-07-23 re-check (Instatus RSS), added by the correction below.

Resolution-time disclosure

Share of each provider's visible incidents carrying a resolution timestamp, and the median self-reported time to resolution. These medians describe what providers report about themselves, within their own window – they are not comparable across providers and say nothing about unreported incidents.

What the opaque three publish instead

• PayPal. Custom status SPA; its Statuspage API (paypal.statuspage.io) is private (HTTP 401) and the public surface exposes no incident-history endpoint.
• Checkout.com. Status endpoints return an S3 AccessDenied error to automated clients.
• Braintree. Serves HTML on API paths; not backed by a status-page API.

Method

On 2026-07-17 we collected every incident visible on the public status surfaces of 16 payment and billing providers, plus three non-payments comparators (Shopify, Twilio, GitHub) for disclosure-norm context – 19 surfaces in total. Sources: the standard status-page API (/api/v2/incidents.json) where present, and Adyen's own history API (/api/incident-messages/history?year=Y), queried for every year it answers. Providers were marked opaque after testing their status host for the standard status-page API and its RSS/Atom feeds; as the Mollie correction below records, that testing centred on Statuspage-style surfaces and initially missed a provider hosted on a different platform (Instatus). The failing endpoint and behaviour are recorded per provider in the dataset. Each record keeps its source URL. The collection and analysis scripts are versioned with this site, and every figure above is computed from the published dataset – anyone can re-run the collection and check us.

Limitations

• Status pages under-report by design. Providers decide what counts as an incident and when to say so. Nothing here measures actual reliability – only what is disclosed.
• Windows differ. Status-page APIs expose roughly the 50 most recent posts, so a provider that posts often shows a short window. Counts must never be compared across providers.
• Severity is self-assigned in 7 different vocabularies; we preserve each provider's own labels rather than mapping them to a common scale.
• Opaque means unverifiable, not unreliable. A provider with no public history may be highly reliable – the point is that you cannot check.
• Single snapshot. This page reflects 2026-07-17; surfaces change. We re-collect quarterly and version every snapshot.

The live edition

This study is a snapshot; the same sources now power a live status radar – 20 providers' self-reported state on one page, refreshed every minute – and a searchable incident-history archive that grows weekly, with these limitations kept attached to both.

Correction log

• 2026-07-23 – Mollie reclassified from opaque to machine-readable. Our original probe tested only the Statuspage-style path (status.mollie.com/api/v2/incidents.json, 404) and concluded Mollie had no machine-readable history. In fact Mollie runs on Instatus, not Statuspage, and publishes an incident-history RSS at status.mollie.com/history.rss – 25 incidents visible on re-check (2026-06-01 to 2026-07-15). This is the same class of error as the Stripe correction below: a real disclosure surface on a platform our collection tooling did not test. Opaque providers were revised 4→3, and Mollie was added to the transparency table with its 2026-07-23 figures; its per-incident records will be folded into the corpus at the next snapshot (its RSS format differs from the Statuspage JSON the corpus is built from).
• 2026-07-17 – Stripe reclassified from opaque to machine-readable. Our initial probe tested Stripe's current status domain (status.stripe.com, no API) and its RSS, and wrongly concluded no machine-readable history existed. The standard status API is in fact served from Stripe's legacy domain (stripestatus.com), found while testing live-status endpoints. The dataset, tables and headline figures on this page were corrected the same day: 5→4 opaque providers, 613→663 incidents. The original snapshot is preserved in the version history of this site's repository. This is exactly the class of error our correction policy exists for.

Dataset

Everything is downloadable and licensed CC BY 4.0 – use it freely with attribution to PayRes:

• incidents-2026-07-17.csv – 663 normalized incidents (provider, severity, timestamps, duration, source URL)
• incidents-2026-07-17.json – the same, as JSON
• transparency-2026-07-17.json – per-provider disclosure assessment, including the opaque three with tested endpoints and failure modes, and Stripe's corrected classification
• analysis-2026-07-17.json – the computed figures used on this page

Spotted an error, or a provider surface we missed? Tell us and we'll correct it – corrections are versioned too. Our evidence rules are documented at how we source claims.