What Should a Payment Alert Include?

What a payment alert should include, at minimum, is five things: how much came in and how much you actually keep after fees, who paid (name and email, not an ID), what happened (the event type), what it means for MRR, and what to do next (a deep link plus an urgency cue). Miss any of those and you have a notification you still have to investigate. The catch is that a raw Stripe webhook physically can't give you most of them — the net amount and the customer's name live somewhere else.

Good alert vs bad alert

Here is the same event two ways. First, a raw Stripe webhook forwarded straight to Slack. An engineer can decode it; a founder or ops teammate sees an integer in cents, a customer ID with no name, and no idea what the payment is worth after fees:

Now the same payment as an alert a person can act on without opening a tab. Plain English, gross and net, a real customer, the plan, the MRR delta, and a link straight to the record:

The second one is not just prettier. To produce it you have to do work the raw payload doesn't do for you: compute the net, turn a customer ID into a name and email, classify the subscription movement, and attach a deep link. That's the whole anatomy of a good alert — so let's take it field by field.

The anatomy: what a payment alert should include, field by field

Every actionable payment alert answers five questions in order: how much, who, what, so what, and what next. Map each to a concrete field and you have a template that works for a sale, a failed charge, a refund, or a churn.

1. Amount — and net after fees

Gross alone is a vanity number. A raw charge.succeeded or payment_intent.succeeded event carries the gross amount, currency, and status — but not the processing fee or the net that actually lands in your balance. Stripe exposes those on a separate balance_transaction object, which you have to fetch or expand to read the fee and the net. There is no webhook for the balance transaction itself.

Why it matters: US card pricing is 2.9% + $0.30 per successful charge, so a $100 sale nets about $96.80 — a raw alert saying "$100.00" overstates real revenue by roughly 3.2%. And you can't just hardcode 2.9%: international cards add 1.5%, currency conversion adds another 1%, and ACH is 0.8% capped at $5. The fee varies per payment, so a correct alert reads the actual fee off the balance transaction rather than guessing.

2. Who — customer name and email, not an ID

The raw event gives you a bare customer ID like cus_Qx9aB2c — no name, no email. A cus_… string tells you nothing you can act on; you can't recognize a key account, spot a churned whale, or reply to support without resolving it first. A good alert has already done that lookup and shows the customer's name and email inline. This is basic to any Stripe payment notification in Slack worth reading.

3. What — the event type, in plain English

"Something happened in Stripe" is not an alert. The reader needs to know instantly whether this is a new sale, a failed charge, a refund, a dispute, or a cancellation — because each one routes to a different person and a different response. Lead with a labeled event type and an emoji marker so the category is legible at a glance, before anyone reads a single number.

4. So what — the MRR impact

For anything subscription-related, the single most useful field is the MRR delta. MRR moves four ways — new, expansion, contraction, and churn — and "subscription updated" tells you none of them. Worse, cancellations in Stripe usually surface as a generic customer.subscription.updated event (triggered when someone cancels in the customer portal), not a dedicated "churn" event, so a useful alert has to interpret the event to classify the movement.

A good subscription alert states the movement category and the delta: "Upgrade · MRR +$40" or "Canceled · MRR −$249." In practice, movement alerts include the customer, prior MRR, current MRR, the delta, and the category (new / expansion / contraction / churn). That's the difference between a number that scrolls past and one that makes someone open Slack. If subscriptions are your lifeblood, see how to monitor Stripe subscriptions in Slack.

5. What next — a deep link and an urgency cue

An actionable notification lets the reader act from the message. That means a deep link to the exact Stripe record — the specific payment or customer, not the Dashboard home page — so investigating is one click, not a search. Pair it with an urgency cue: match the interruption to the stakes. A routine sale can be quiet; a failed payment or a dispute should look and route differently, because those need a human now. A failed charge that recovers on its own doesn't warrant the same volume as one that's about to churn a key account.

Urgency and routing cues: not every alert is equal

The best notification-UX guidance is simple: the higher the risk, the stronger the interruption. A quiet acknowledgment for routine events; a loud, prominent marker for high-value or destructive ones. In alerting terms, prioritize events that combine business impact with a defined response path, route by severity to the right people, and remember that not every alert needs to wake someone at 3 a.m. Low-urgency events belong in a digest, not a ping.

So a payment alert should also carry cues that answer "how much does this matter, and who owns it?" In practice that's three things: a severity marker (color or emoji), a routing target (which channel or person), and — for failures — a reason and next step. Here's a high-urgency example, deliberately built to look different from a routine sale:

This one earns a louder marker, a decline reason you can act on, an at-risk MRR figure, the retry timeline, and a link to the customer — and it's routed to founders, not the general wins channel. That's the anatomy of a failed-payment alert done right; the full playbook is in how to send failed payment alerts to Slack, and deciding who gets what is covered in which Stripe alerts go to finance, support, and founders.

Why raw webhooks can't do this on their own

It's worth being precise about the gap, because it explains why "just forward the webhook" never produces a good alert. A raw Stripe Event wraps everything in envelope fields (id, object, api_version, created, type) and nests the real data under data.object. Amounts are integers in the smallest currency unit — amount: 2000 means $20.00 — so unformatted JSON is unreadable to a non-engineer and easy to misread.

More fundamentally, three of the five fields a good alert needs are not in the payload at all:

• Net after fees lives on a separate balance_transaction object you must expand or fetch — the charge webhook doesn't carry the fee or the net.
• Customer name and email aren't in the event; you get a cus_… ID and have to resolve it against the customer record.
• MRR movement type (new vs upgrade vs downgrade vs churn) has to be *derived* by interpreting the event, since Stripe surfaces most cancellations through a generic subscription.updated.

Stripe's own default Slack app and Stripe Workflows for Slack let you pick events, choose a channel, and optionally include a Dashboard link — which is genuinely useful and costs nothing. But users describe the out-of-the-box output as "mostly a direct transformation of data": it doesn't compute net-after-fees, doesn't resolve a bare customer ID into a name, doesn't classify MRR movement, and sends one ping per event with no grouping. Raw forwarders (Zapier, direct webhooks, Hookdeck) can pass any field, but they leave every bit of that enrichment to you. If you're weighing building it yourself, ChargeBell vs custom Stripe webhook code walks through exactly what that enrichment costs to maintain.

The full checklist

Use this as a spec whether you're building alerts yourself or evaluating a tool. A payment alert should include:

• Amount, gross and net — formatted currency, with the actual fee read from the balance transaction (not a hardcoded percentage).
• Customer identity — name and email resolved from the ID, so the reader recognizes the account.
• Event type — a plain-English label and marker: new payment, failed, refund, dispute, new subscriber, cancellation, payout.
• MRR impact — for subscription events, the delta and movement category (new / upgrade / downgrade / churn).
• A deep link — straight to the exact Stripe payment or customer record.
• An urgency + routing cue — a severity marker and the right channel, so failures and disputes stand out and reach the right people.
• Sensible volume — batch low-urgency events into a digest instead of one ping per webhook.

How ChargeBell builds each alert

ChargeBell is a purpose-built Stripe-to-Slack alert product, and its alerts are the anatomy above, assembled for you. Each message is plain English with the numbers already computed: the net amount after Stripe fees, the customer name and email when Stripe provides them, and the MRR impact for subscription changes — not raw webhook JSON.

The urgency and routing cues are built in too. Payment failed and dispute created are treated as critical — they bypass quiet hours and can add an @channel prefix — while routine wins can go to a #wins channel and problems to #founders via per-alert routing. Quiet hours hold low-priority alerts and combine them into one "while you were away" message, and daily and weekly digests batch the small stuff so your channel stays signal, not noise. It connects through official read-only Stripe OAuth, so it can see payment events to build these alerts but can never move money or change anything.