Event: payment.failed · Destinations: Slack, Intercom, Salesforce, Resend
The problem
Your billing system knows the card failed, but the rest of the business usually does not. Support is waiting in Salesforce, Intercom does not have the right context for customer messaging, and ops only finds out when someone notices churn rising or a customer opens a ticket.
The DIY version turns one billing event into four or five delivery paths with different payload requirements. Slack wants a formatted alert, Salesforce wants structured fields, Intercom wants the right tag, and email needs template variables. That is exactly where brittle workers and silent failures start.
Payment failures are one of the highest-urgency events in SaaS. If one downstream system misses the event because of a transient API failure or mapping bug, your revenue recovery workflow drifts out of sync immediately.
The event flow
Each use case follows the same product story: Meshes receives the source event once, maps it to the right destinations, and keeps delivery visible when downstream APIs fail.
Event payload
{
"customer_id": "cus_91ab2",
"email": "jane@acme.io",
"amount": 4900,
"currency": "usd",
"failure_reason": "card_declined",
"retry_count": 2,
"plan": "growth",
"subscription_id": "sub_91ab2"
}Slack
Meshes sends a message directly to #billing-alerts with the failed amount, plan, and retry count.
Ops gets immediate visibility into revenue risk and can inspect spikes before customers complain.
Intercom
Meshes tags the user for payment-issue messaging and support segmentation.
Intercom can trigger the right support or recovery messaging with current billing context.
Salesforce
Meshes updates payment-failure fields so Salesforce automation has reason, amount, and retry details.
CS or RevOps can create the right follow-up task without waiting for a manual sync.
Resend
Meshes sends a payment update email template directly with next-step context.
The customer gets a clear billing update fast instead of waiting for a separate worker or cron job.
How Meshes handles it
Instead of maintaining separate workers, retry logic, and visibility per destination, Meshes gives you one event path, destination-aware routing, and built-in delivery guarantees.
From your product
import MeshesEventsClient from '@mesheshq/events';
const meshes = new MeshesEventsClient(
process.env.WORKSPACE_PUBLISHABLE_KEY!,
);
await meshes.emit({
event: 'payment.failed',
resource: 'subscription_plan',
resource_id: 'growth',
payload: {
customer_id: 'cus_91ab2',
email: 'jane@acme.io',
amount: 4900,
currency: 'usd',
failure_reason: 'card_declined',
retry_count: 2,
plan: 'growth',
subscription_id: 'sub_91ab2',
},
});Across destinations
On every delivery
Why this matters
Payment failures lose money when the signal stalls. Routing the same event to support, CRM, email, and ops at once keeps recovery workflows moving immediately.
When Slack, Salesforce, Intercom, and email all react from the same payload, you avoid conflicting customer outreach and stale billing data.
Without a delivery layer, one broken webhook can hide for days. Meshes gives you retries, dead letters, and replay before that becomes lost revenue.
Related
Docs
See the fastest path from workspace to first routed event.
Open linkDocs
See how Meshes maps one billing event to multiple destinations with reusable actions and rules.
Open linkIntegration
Post billing alerts directly into the channels your team already watches.
Open linkIntegration
Update Salesforce contact fields so downstream automation can follow up.
Open linkBlog
Why exponential backoff and jitter matter for revenue-critical delivery paths.
Open linkBlog
How to avoid losing failed billing events when retries are exhausted.
Open linkCompare
See what it costs to own billing-event workers, retries, and replay paths yourself.
Open link