Know when Stripe paymentsstart failing

10 min · you have a Stripe account · updated 6 September 2026

Payments can fail while the product looks completely healthy. Customers leave one at a time, Stripe retries a webhook in the background, or the account loses a capability after a verification requirement becomes overdue.

Beaam watches the parts of that path Stripe can prove from a read-only restricted key. It keeps ordinary declines quiet and asks for attention when the evidence points to an operational problem.

Connect with least privilege

In Stripe, open Developers → API keys, create a restricted key, and set these three resources to Read:

1. Account
2. Events
3. Webhook Endpoints

Paste the resulting rk_live_… key into Beaam. An rk_test_… sandbox key is also supported and is visibly labelled test mode. Beaam refuses full-access sk_live_… and sk_test_… keys.

The connection is saved only after all three reads work. It then starts watching the account and runs its first check immediately.

What Beaam watches

Can customers pay? Beaam counts successful and failed PaymentIntents over five minutes. The failure-share alert is evaluated only after at least ten attempts. Event pagination is bounded; if a very busy account exceeds that bound, Beaam keeps conservative counts but withholds the percentage alert instead of guessing its denominator.

Can the account operate? Charging and payout capability, Stripe's disabled reason, and past-due account requirements are checked every minute.

Are billing and money movements stuck? Failed invoice payments, invoice finalization failures, invoices requiring customer action, payout failures, refund failures, and delayed-method Checkout failures are retained. The actionable infrastructure failures alert by default; routine dunning context is charted without treating every customer decline as an outage.

Does someone need to act? New disputes and early fraud warnings surface immediately.

Are webhooks reaching their destinations? Beaam lists webhook endpoint status and queries events that remain undelivered after a ten-minute grace period, across Stripe's three-day retry window. A deliberately disabled endpoint is charted but alert-off by default; an aged undelivered event alerts after confirmation.

Provider failure reasons—such as a decline code or invoice finalization error—are retained as short, bounded evidence beside the metric and incident.

Payment silence

Zero failures can mean everything is healthy, or that checkout stopped creating payments at all. Because many small products naturally have quiet five-minute windows, the silence rule is off by default. If your account normally sees continuous sales, enable “Payments succeeded per 5 min < 1” and tune the threshold to your traffic.

Scope and limits

The key connects the Stripe account it authenticates directly. Live and test mode are separate connections even when Stripe reports the same acct_… id.

Stripe Connect child accounts are not silently included. Calls for a connected account require explicit account scoping, and Beaam does not currently fan a platform key out across those accounts. Connect the account you intend to watch; do not read “whole account” as “the platform plus every connected account.”

Beaam cannot infer a wrong price, an incorrect entitlement, or a business-logic failure after a successful charge. Instrument those invariants in your application. If you emit OpenTelemetry, send those signals to Beaam.

A sensible money-path setup

1. Connect Stripe with the restricted key above.
2. Add the public checkout and webhook-handler URLs as HTTP checks.
3. Connect the runtime and database behind the webhook handler.
4. Enable payment silence only if your normal volume makes five-minute silence abnormal.
5. Send a test alert and confirm the notification route reaches you.

That covers Stripe's view of the payment, the network edge, and the application that fulfils it—three different truths that commonly fail independently.

---