Forward Stripe events to Slack in seconds
- Trigger
- POST /relay?token=
- Lands in
- The relay log, plus any channel you route to
- Setup
- 5 min
- Needs
- Stripe dashboard access
$59.00 · Apr 25, 9:41 AM
Nadia Rahman · Singapore, SG
- Product
- Pro annual
- [email protected]
- Plan
- $59.00 / monthly
- Period
- Apr 25 to May 25
Enriched from invoice.paid, which is why the name, plan, and billing period are on a charge card.
From Viably, create a relay endpoint and select Stripe Transactions in the dropdown. This tells Viably to expect Stripe-formatted payloads and route them to the right Slack message template.
In your Stripe dashboard, add a new Webhook Destination with the Viably query-param URL. Select charge.succeeded, charge.failed, invoice.paid, and optionally customer.subscription.updated for cancellation alerts.
Viably needs the Stripe signing secret to verify incoming requests. Copy it from the Stripe dashboard and paste it into your relay endpoint's config in Viably.
Set it up properly, step by step
Viably can receive events directly from Stripe and post them to Slack. Because Stripe webhook destinations post to a plain URL, you must use the query-param token format rather than the Bearer authorization header.
- 1Create a relay endpoint
In the Viably dashboard, create a new relay endpoint with Stripe Integration enabled. Once created, open the token dialog and copy the Stripe Webhook Destination. It looks like
https://hq.viably.app/relay?token=…. - 2Create a webhook destination in Stripe
In your Stripe Dashboard, go to Developers → Webhooks → Add destination. Paste the Viably query-param URL as the Endpoint URL. Select these events:
charge.succeeded,charge.failed,invoice.paid, and optionallycustomer.subscription.updated.charge.succeededcaptures all successful transactions in Slack, whether from Stripe Checkout or your own API integration.charge.failedturns an abandoned checkout into a recovery opportunity: Viably posts the customer, product, amount, and decline reason, and can spawn a follow-up task so someone reaches out to win the sale back.invoice.paidenriches each charge card with the customer's name, email, phone, and country.customer.subscription.updatedis optional, and it fires a cancellation recovery alert when a subscriber schedules their cancellation, so your customer care team can reach out before the billing period ends.
Do not send other Stripe events to this endpoint. Viably silently drops unrecognised event types, and sending them unnecessarily adds noise to your webhook logs. - 3Copy the signing secret
After saving, Stripe displays a signing secret beginning with
whsec_. Copy it to complete your setup on Viably. If you miss it, you can reveal or roll it from the destination details page. - 4Complete setup in Viably
Back in the Viably dashboard, click Edit on the relay endpoint. Paste the
whsec_…value into the Stripe webhook secret field and save. Viably will now verify every incoming Stripe request and reject anything unsigned. - 5Test it
Use Stripe's Send test event button on the destination page to fire a sample event. Check your configured Slack channel, where you should see a formatted message within a few seconds.
Stripe webhook destinations send a plain POST and do not support custom Authorization headers. The ?token=… format is the Viably-supported alternative for these integrations, and both URLs are shown in the token dialog after endpoint creation.
charge.succeeded: Transaction fields
Viably reads the charge object at data.object and maps the following fields into a Transaction card in Slack. Every field is optional, so Viably renders what it can find and omits the rest.
Viably scans data.object.metadata and surfaces the keys below as labelled fields in the Slack card. When several key aliases are listed, the first non-empty one wins, and any other metadata key is silently ignored.
charge.failed: Failed payment recovery
A failed checkout is a warm lead rather than a dead end. When charge.failed arrives, Viably posts a red Payment Failed card that names the product, the amount, why the card was declined, and who to reach, so your team can follow up while the customer is still in a buying mindset. By default it also spawns a task assigned to whoever should recover the sale.
New Stripe relays enable a follow-up task on charge.failed out of the box, posted as a card under the alert, assignable to a teammate or left up for grabs. Manage it under Spawn a task when editing the endpoint.
The same customer often fails several times over hours, whether from Stripe dunning retries or a shopper re-entering a declined card. Viably alerts once per customer per day: after the first charge.failed, further failures for the same Stripe customer, or for anonymous checkouts the same payment_intent, are suppressed for a 24-hour window, so one struggling checkout never spams your channel or spawns duplicate recovery tasks.
customer.subscription.updated: Subscription events
Viably classifies each subscription event as a cancellation scheduled, a new activation, or a generic update, each with its own Slack heading. The most actionable scenario is a scheduled cancellation, where Viably posts a recovery alert with the customer’s full contact details and a deadline for your customer care team to reach out before the billing period ends.
Stripe often fires four or five customer.subscription.updated events for a single user action, and some carry cancel_at_period_end: true in both the current and previous attributes, which is not a new cancellation. Viably drops those silently, and only the event where cancel_at_period_end transitions from false to true triggers the recovery alert. New activations and other subscription updates are collapsed into one Slack message per subscription within a 90-second window.
Revenue attribution
Every payment Viably relays is also matched to a person, and that person keeps the channel that first found them. You configure none of this. A contact form posts the page it sits on, a checkout puts the event on the charge, and a purchase months later is still credited to whatever brought that customer in originally, so your Contacts page can tell you which channels are worth running again without anyone maintaining a spreadsheet of them.
A ticket or a single sale carries enough to place it. Viably reads metadata.source when your checkout sets it, and otherwise recognises the event a charge names in metadata.description and matches it to the page you already sell that event on. Nothing is asked of you, and a charge it cannot place stays unattributed rather than being credited to a guess.
A renewal carries no trace of where the customer came from. They subscribed on a page months ago, and every charge since is a quiet monthly event naming a plan and nothing else. Viably will not invent an origin for it, so that revenue reads as Direct until you say otherwise. If you want it credited properly, open Webhook Relay → Subscription origins and name the page each plan is sold from. It is one line per plan, set once, and it applies to charges already captured as well as future ones. Skip it and everything else on the page still works exactly as it does today.
Periodic reporting
When batch mode is enabled on a Stripe Transactions relay, Viably accumulates events over a configurable window and posts a single summary card to Slack rather than one message per transaction.
A one-day window shows a single date, as in Apr 25. A multi-day window shows a range, as in Apr 19 – Apr 25. All dates are rendered in your workspace’s configured timezone.
When events span more than one time bucket, a bar sparkline such as ▁▂▄▇█▅▂▁ shows the relative revenue distribution across buckets at a glance, where taller bars mean more revenue in that slot.
Up to 20 charges are shown newest first as swipeable cards. Each card's title is the amount, the subtitle is the customer name or email, and the body shows email, phone or location, plan, subscription period, and charge time. If the batch holds more than 20, a footer note shows the remaining count.
Only successful charges count toward the total. Failed charges carry an amount but are excluded from the revenue count and the carousel, along with any other event that is neither charge.succeeded nor invoice.paid. Their type names are listed in a footer warning. Failed-charge recovery alerts and tasks are a real-time feature rather than a batch one.
The batch card header shows the transaction count and endpoint name, as in 5 Transactions — My Stripe Relay, with a Total Revenue and Transactions stats section directly below for visual hierarchy. Stripe charges are de-duplicated by charge ID before the total is calculated, so retried or re-delivered webhooks are never double-counted.
A couple of minutes. You create a relay endpoint in Viably, paste its URL into your Stripe webhook settings, and pick the events you care about. There is no server to deploy and no code to write.
Successful charges tell you the business is working, failed charges are the ones worth acting on the same day, and subscription updates tell you when plans change. Viably formats each into its own card rather than dumping raw JSON into the channel.
Yes. The payment attaches to a contact keyed on the email address, so the person who filled in your form in March and paid in June is one record. That is what lets the reporting say which channel earned the revenue.
No. The endpoint is a public URL from the moment you create it, so you can send a test event from the Stripe dashboard and watch it land in Slack immediately.
Create your Stripe relay endpoint. Webhook Relay is on the free plan, and every new workspace also gets a 14-day Viably+ trial without a card.
Add Viably to Slack