When payments degrade: catching Stripe incidents in time

Checkout still completes. The success page renders, the customer is charged, the order is created. But the confirmation emails are not going out, and webhook retries are stacking up quietly in the background. Finance spots the reconciliation mismatch before engineering has noticed anything is wrong at all.

A payment-provider incident does not always look like failed payments. This one is delayed and dropped webhooks: the charge succeeds synchronously, but the asynchronous events that confirm it, the ones that trigger fulfilment, send the receipt and update the ledger, arrive late or not at all. Everything the customer sees in the moment works. Everything that happens after the moment does not.

Why the dangerous ones hide behind success

The payment incidents that hurt are rarely the ones where the card is declined. A decline is loud and immediate: the customer sees it, retries or leaves, and your error rate moves. The expensive incidents are the ones where the payment succeeds and the steps after it quietly do not. There is no error on the path the customer walks, so there is nothing for a synthetic checkout to catch if it stops at "payment succeeded."

Who notices first, and why it is not you

Because the failure is downstream of the success, the people who notice are downstream of engineering. Support hears from customers who were charged but got no receipt. Finance sees orders that will not reconcile against payouts. By the time the signal reaches the team that can read a webhook queue, the queue is deep and the provider may still be showing green.

Payment failures are revenue failures, and revenue failures are noticed by the people counting the revenue, not the people watching the dashboards.

The first instinct is usually wrong in an instructive way. The visible symptom is missing emails, so engineering checks the email provider. The email provider is fine; it never received the events to send, because they are stuck behind the payment provider’s delayed webhooks. The time goes into the symptom, not the source.

What monitoring changes

The alert you want is the gap between charged and confirmed. That means watching the provider’s status, watching webhook delivery and retry rates, and running a synthetic journey that verifies the whole flow rather than the first half of it. When the distance between "payment taken" and "order confirmed" widens, that is the incident, and it is visible long before finance opens a spreadsheet.

Crowswatch pulls Stripe incidents from their status feed and watches the flow end to end, so a payment degradation surfaces as an operational event rather than a reconciliation surprise.