Payments Status
Everything is up.
Payment outages are rarely total, and that shapes how you should read a verdict here. Providers deliberately make charge processing more resilient than their dashboards, so the common incident affects one card network, one local payment method, one region, or webhook delivery, while cards in general keep working. A single overall status therefore hides most of what a merchant actually needs to know.
The other thing that makes these incidents distinctive is that the failure is often not the provider's at all. Gateways depend on banks, card networks, and local rails, so an upstream outage shows up as elevated declines on one method while every other route succeeds. Merchants usually notice through a decline rate climbing rather than through any error message.
Merchant-of-record and hosted checkout products carry an extra risk: because they own the checkout page, an incident blocks new purchases outright even when the seller's own application is perfectly healthy.
- up
- slow
- down
- no reading
Common questions about payment providers
A decline comes back quickly with a reason code and means the provider is working. The card issuer refused it. An outage looks like a timeout, a 5xx, or a checkout page that will not load at all. Trying a card from a different issuer separates the two: if that succeeds, the provider is up.
Be careful. If the request timed out, the charge may have succeeded without the response reaching you, and a blind retry can double-charge. Look the payment up by its idempotency key or reference before retrying, and prefer the provider's own retry mechanism, which is built not to duplicate.
We check one endpoint, and payment incidents are usually confined to a single method, region, or rail. Card charges can be entirely healthy while one local payment method or a webhook queue is not. Your provider's dashboard and its per-component status page will show that detail.