Guide · Stripe → Slack · Verified November 1, 2026
Stripe to Slack webhook guide
Short answer: One Stripe endpoint verifies each delivery, a destination filter keeps the events in this guide, and every match is delivered to Slack with its own retry schedule and delivery log.
Failed payments are time-sensitive and low-volume, which makes Slack the right surface. The destination posts the invoice title, hosted link, and amount to a billing channel; the delivery log stores Slack's response body, including the message ts, so a thread can be traced back to the event.
At a glance
id when it starts with evt_, stable across Stripe retries.Target: SlackA Hooks Slack destination posts either to an incoming webhook URL already bound to a channel, or to chat.postMessage with a bot token and channel id so one app can reach many channels.1. Configure the Stripe webhook
- In the Stripe Dashboard, open Developers → Webhooks → Add endpoint.
- Paste the endpoint's ingestion URL and select the events you need (invoice, checkout, subscription).
- Copy the endpoint's Signing secret (`whsec_...`) into the Hooks endpoint secret.
- Send a test event from the Stripe Dashboard and confirm it in the delivery log.
HMAC-SHA256 over <t>.<raw body>; any matching v1 signature passes. Five minutes between t and the current time.
2. Filter to the events that matter
Filters run per destination before rendering, so a non-matching event is stored with no delivery and no agent call. The rules below are the difference between a useful pairing and a noisy one.
Filter: failed or action-required invoices
{
"allow": [
{
"field": "event.type",
"op": "in",
"value": ["invoice.payment_failed", "invoice.payment_action_required"]
}
]
}3. Configure the Slack destination
A Hooks Slack destination posts either to an incoming webhook URL already bound to a channel, or to chat.postMessage with a bot token and channel id so one app can reach many channels.
Destination: Slack alert
{
"mode": "chat",
"token": "{{secret.SLACK_BOT_TOKEN}}",
"channel": "C0123456789",
"text": "Payment failed: {{event.subject.title}}\n{{event.subject.url}}"
}Secrets enter configs only as {{secret.NAME}} references; literal credentials are rejected. Full Slack target guide
4. Verify the delivery and its retries
Send one real event from the source, then open Deliveries. A 2xx from the target means accepted, not finished. 408, 425, 429 and 5xx retry with backoff honoring Retry-After; other 4xx fail permanently with a named code. The rendered request is stored per attempt, so a bad field path is visible without re-sending.
The pitfall this pairing hits
Slack answers 200 with ok: false on rate limits. {"ok": false, "error": "ratelimited"} retries as SLACK_RATE_LIMITED instead of failing permanently; an HTTP 429 with Retry-After is honored the same way. Other 4xx responses fail permanently, so a deleted channel surfaces as a named error rather than a retry storm.
Frequently asked questions
Do I need one endpoint per source or one per destination?
One endpoint per source. Each destination under that endpoint carries its own filter, template, retry schedule, and delivery log, so the same event can feed several targets without duplicate ingress URLs.
What happens while the target is down?
Retryable failures back off and retry within the destination's window; permanent 4xx failures stop immediately. Either way, the original event stays stored, so after fixing the target you replay the event instead of asking the source to send it again.
Slack answers 200 with ok: false on rate limits
{"ok": false, "error": "ratelimited"} retries as SLACK_RATE_LIMITED instead of failing permanently; an HTTP 429 with Retry-After is honored the same way. Other 4xx responses fail permanently, so a deleted channel surfaces as a named error rather than a retry storm.