What should a payment alert include?

A payment alert should include the event, the amount, the customer, and a link to the Stripe record. Fee and net amounts help when Stripe's balance transaction is available. MRR belongs on subscription alerts, not on every payment. ChargeBell sends these fields in plain English where it can, but you still open Stripe for the final status and retry details.

A good payment alert and a bad one

Here is one event shown two ways. First, a raw Stripe webhook posted straight to Slack. An engineer can read it. A founder sees an amount in cents, a customer ID with no name, and nothing about fees.

Here is the same payment as a ChargeBell message, with sample data and gross display. Net fields appear only when the conditions above are met.

The second message reads as a sentence. Fee and net amounts can be added to it, and subscription alerts use their own format for MRR. The sections below split required fields from optional ones.

What a payment alert should include, field by field

A payment alert should say what happened, how much, who paid, and where to look. Add fee and net when Stripe has them, MRR for a subscription change, and an urgency marker for a failure or dispute. Leave a field out when the data is missing instead of filling it with a guess.

1. Amount, gross and net after fees

The gross amount alone overstates what you earned. A raw charge.succeeded or payment_intent.succeeded event has the gross amount, currency, and status. It does not have the processing fee or the net amount that reaches your balance. Stripe keeps those on a separate balance transaction, which you fetch or expand to read. Stripe sends no webhook for the balance transaction itself.

Stripe fees vary by region, card, currency, and payment method. Read the net amount from the actual balance transaction instead of a fixed percentage. Stripe's pricing page lists the rates for your country.

2. Who paid: name and email, not an ID

The raw event gives you a customer ID like cus_Qx9aB2c, with no name or email. You cannot spot a key account or reply to a support ticket from an ID. A good alert looks up the customer and shows the name and email in the message. Any Stripe payment notification in Slack should do this.

3. What happened: the event in plain English

The reader needs to know at a glance whether this is a sale, a failed charge, a refund, a dispute, or a cancellation. Each one goes to a different person and needs a different response. Start the message with a plain label and an emoji so people know the type before they read a number.

4. MRR change for subscription events

For subscription events, the MRR change is the most useful field. MRR moves in four ways: new, expansion, contraction, and churn. A "subscription updated" label tells you none of them. When a customer cancels at the end of the period, Stripe sends customer.subscription.updated first and customer.subscription.deleted only when the subscription ends. An alert has to read the event to know which movement it is.

A good subscription alert names the movement and the amount, such as "Upgrade · MRR +$40" or "Canceled · MRR −$249". It shows the customer, the old MRR, the new MRR, and the change. For setup steps, see how to monitor Stripe subscriptions in Slack.

5. A link and an urgency marker

The alert should link to the exact Stripe payment or customer, not the Dashboard home page, so checking takes one click. It should also show how urgent the event is. A routine sale can be quiet. A failed payment or a dispute needs someone to act, so it should look different and go to a different channel.

Urgency and routing in a payment alert

The higher the risk, the louder the alert should be. Routine events get a quiet message. Failures and disputes get a strong marker and go to the person who owns the fix. Events that need no action today belong in a digest, not a real-time ping.

So a payment alert also needs a severity marker, such as a color or emoji, and a channel or person who owns it. A failure also needs the reason and a next step. Here is a failed payment alert, built to look different from a sale:

This message shows the amount, the customer when Stripe has one, Stripe's failure message, and a prompt to check Stripe. It does not show a decline code, a retry schedule, or MRR at risk. Open Stripe for those, and use the Stripe decline codes cheat sheet to read the code. See also the failed payment alerts guide and which Stripe alerts go to which team.

Why a raw Stripe webhook is not a payment alert

A raw Stripe event wraps the data in envelope fields such as id, object, api_version, created, and type, and puts the object under data.object. Amounts are integers in the smallest currency unit, so amount: 2000 means $20.00. A non-engineer cannot read that, and anyone can misread it.

Three of the fields a good alert needs are not in the payload at all:

• Net after fees. It lives on a separate balance_transaction that you must expand or fetch. The charge webhook has neither the fee nor the net.
• Customer name and email. The event has a cus_ ID, and you look up the customer record to get the name.
• MRR movement. New, upgrade, downgrade, and churn have to be worked out from the event, because a cancellation often arrives as customer.subscription.updated.

Stripe's own Stripe Workflows for Slack app lets you pick events, choose a channel, and add a Dashboard link, and it is free. Zapier, direct webhooks, and other forwarders can pass any field in the event. In each case, net after fees, the customer name, and the MRR movement need extra lookups that you set up and maintain. If you are thinking of building them yourself, ChargeBell vs custom Stripe webhook code lists what that involves.

Payment alert checklist

Use this list whether you build alerts yourself or compare tools. A payment alert should include:

• Amount, gross and net. Format the currency, and read the fee from the balance transaction instead of using a fixed percentage.
• The customer. Show the name and email, so the reader knows the account.
• The event type. Use a plain label and marker, such as new payment, failed payment, refund, dispute, new subscriber, cancellation, or payout.
• MRR change. For subscription events, show the amount and whether it is new, upgrade, downgrade, or churn.
• A direct link. Link to the exact Stripe payment or customer.
• Urgency and an owner. Mark failures and disputes clearly and send them to the people who act on them.
• Sensible volume. Put low-urgency events in a digest instead of one message per webhook.

How ChargeBell builds each payment alert

ChargeBell's Stripe Slack integration builds alerts from the checklist above. Each message is plain English. It shows the net amount after Stripe fees when it can read the balance transaction, the customer name and email when Stripe has them, and the MRR change on subscription alerts when it can be calculated.

Urgency and routing are built in. Payment failed and dispute created alerts are critical, so they skip quiet hours and can add an @channel mention. You can send sales to #wins and problems to #founders with per-alert routing. Quiet hours hold low-priority alerts and post them as one "while you were away" message. Daily and weekly digests collect the small events. ChargeBell connects with read-only Stripe OAuth, so it can read events but cannot move money or change anything.