Event signal:payment.failed| Destination:Slack| Use case:Payment Failed Notifications| Typical setup:~15 minutes
Workflow outcome
The workflow starts with one payment.failed event from your product and ends with a templated Slack message in the billing or ops channel your team already watches.
Instead of discovering failed charges in a report or waiting for a support ticket, you get a visible alert path with delivery history, retries, and replay when Slack or your own glue code would otherwise drop the event.
Why teams care
Payment failures are revenue events, not just billing events. Someone on the team usually needs to know right away whether the failure was isolated or part of a larger issue.
The DIY version looks small until you need formatting, channel selection, retry handling, and a way to prove the alert actually landed. That is where one-off notification code becomes operational debt.
Alert quality matters too. If you already emit different billing events for first failure versus exhaustion, you can point only the signal that deserves a human Slack alert into the rule instead of creating more noise.
What it depends on
These pages stay focused on the workflow outcome, but the setup still needs the right workspace, destination connection, and event path underneath.
You need a Meshes workspace and publishable key so your app can emit payment.failed.
Authorize Slack in Meshes and decide which channel should receive billing alerts.
Read moreYour app needs to send payment.failed with the fields Slack should display.
Choose a billing, support, or ops channel that can act on the alert instead of broadcasting every failure everywhere.
The source event
For a Slack alert, the important fields are the ones that let a human understand the issue immediately: who failed, how much revenue is at risk, why it failed, and which plan or customer segment is affected.
Event payload
payment.failed{
"customer_id": "cus_91ab2",
"email": "jane@acme.io",
"amount": 4900,
"currency": "usd",
"failure_reason": "card_declined",
"plan": "growth"
}What matters most
Gives the team a fast customer reference without opening the billing system first.
amount + currency
Makes the revenue impact obvious inside the Slack message itself.
failure_reason
Helps the team distinguish card issues from processor outages or expired cards.
plan
Adds customer-segment context so the alert is more useful than a bare failure notice.
customer_id
Gives you a stable reference for linking back to billing or support systems later.
Field mapping view
| Event field | Destination target | Why it matters |
|---|---|---|
| Slack message body | Show which customer was affected without opening another dashboard. | |
| amount + currency | Revenue line in the template | Call out the failed charge value in the alert itself. |
| failure_reason | Reason line | Explain whether this was a decline, expiry, or another failure mode. |
| plan | Context block | Add account or tier context so the right team reacts with the right urgency. |
| customer_id | Reference or deep-link token | Keep a stable handle you can reuse in downstream follow-up. |
The destination connection
In your Meshes workspace, create the Slack connection that should receive payment.failed and choose the channel that owns billing visibility. Once that connection is available in Meshes, you can map the event into a readable alert instead of leaving Slack delivery logic in your billing path.
Where Meshes matters
Most teams do not need another destination. They need the destination to stay in sync without embedding its delivery quirks, retries, and mapping logic into the product code path.
In Meshes, bind payment.failed to Slack Send Message, choose the billing or ops channel, and build a short template that surfaces the customer, plan, amount, and failure reason. The goal is not a wall of JSON. It is a message a human can act on in seconds.
A sample event
This is the part teams like: the source event stays readable and product-shaped while Meshes owns the destination-facing complexity.
TypeScript example
import MeshesEventsClient from '@mesheshq/events';
const events = new MeshesEventsClient(process.env.WORKSPACE_PUBLISHABLE_KEY!);
await events.emit({
event: 'payment.failed',
payload: {
customer_id: 'cus_91ab2',
email: 'jane@acme.io',
amount: 4900,
currency: 'usd',
failure_reason: 'card_declined',
plan: 'growth',
},
});Destination outcome
Use Send Test Event in Meshes or emit payment.failed from your product. A successful run should produce a templated Slack alert in the chosen channel within seconds.
Operational visibility
The difference between a nice demo and a usable product workflow is whether you can see what happened when the destination is slow, misconfigured, or unavailable.
In Meshes
Why teams buy Meshes
What's next
Use Case
See the broader payment.failed fan-out pattern across Slack, CRM, support, and email.
Integration
See the Slack connection flow, message templates, and delivery review details.
Open linkDocs
Use the publishable-key events API or SDK to emit payment.failed from code.
Compare
Compare one routed billing alert path with owning custom notification workers yourself.
Open linkGuide
Push adjacent revenue-change signals into Salesforce for CS and RevOps follow-up.
Open linkGuide
See another time-sensitive lifecycle workflow where delivery timing matters.
Open linkpayment.failed once, let Meshes deliver the alert, and keep the operational trail visible when billing issues spike.