Send any payment event to Slack

Not on Stripe? No problem. Viably’s Webhook Relay accepts a simple JSON payload from any payment provider or homegrown billing system, formats it into a clean transaction card, and posts it to your Slack channels, with optional periodic revenue summaries so your team always knows where revenue stands.

Trigger: POST /relay
Lands in: The relay log, plus any channel you route to
Setup: 4 min
Needs: Anything that can send an HTTP POST

#revenue

ViaApp8:30 AM

$49.90 · Apr 27, 8:30 AM

Samuel Chan · Jakarta, ID

Product: Pro Plan, monthly
Email: [email protected]
Phone: +62 877 1212 1212
Source: pay.myapp.com

Open the contact

Sending the customer email is what attaches this payment to a contact, so the revenue can be attributed to the channel that won them.

What this guide produces, as it appears in Slack.

Get started in 2 steps

Before you start

Invite @Via to the Slack channel where you want webhooks to appear. Without this, Viably accepts your webhook but cannot post to the channel.

Step 1Create a Non-Stripe Transactions relay

In the Viably dashboard, click New Relay, then Transactions, then Non-Stripe Transactions. Give it a name, pick your Slack channels, and hit Create. You get a Bearer token and relay URL immediately.

Step 2POST your payload from your payment handler

After a successful payment in your backend, send a POST to the relay URL with your Bearer token in the Authorization header. Viably formats it and posts to Slack within seconds.

Bearer auth, not a query param

Unlike Stripe, which posts to a plain URL, your own backend can set custom headers. Always pass the token as Authorization: Bearer <token> and store it in an environment variable rather than hardcoding it.

Payload reference

POST a flat JSON object to the relay URL. Viably reads the following top-level fields and maps them into a transaction card in Slack. Fields marked required must be present for the message to render correctly and for batch reporting to produce accurate totals.

Field	Status	Notes
`amount`	required	Integer in minor currency units, e.g. 4990 for $49.90. Divided by 100 before display. Also summed across events for batch totals and periodic revenue reports, so if it is missing or sent as a decimal, report figures will be wrong.
`currency`	required	ISO 4217 code, e.g. "USD", "EUR", "IDR". Defaults to USD if absent, though explicit is better.
`name`	recommended	Customer full name. Shown as the card subtitle with a country flag when country is also provided. Falls back to email if absent.
`email`	recommended	Customer email. Shown as a labelled field in the card body when name is also present.
`description`	recommended	What was purchased, shown as "Product". Falls back to the product field if absent.
`order_id`	recommended	Your own id for the order. Viably remembers it for 24 hours and drops a second delivery carrying the same one, so a retried webhook or a double-submitted checkout cannot post the sale twice or count twice in your revenue totals. Any stable value works, as long as a retry of the same charge sends the same one.
`event_id`	optional	The same protection for a payload with no order behind it, such as a refund notice or an in-app purchase event. Derive it from the row the event created, never from a clock read or a fresh UUID at the moment of sending: a value that changes per request matches nothing and switches off the payload comparison Viably otherwise falls back on.
`source`	optional	Origin site or app, such as pay.myapp.com. Shown in the message footer, and it suppresses the missing-source hint.
`title`	optional	Overrides the default card header. Useful for branding, e.g. "New Sale on Dunder Mifflin Pay".
`submitted_at`	optional	ISO 8601 timestamp of the transaction, e.g. "2026-04-27T08:30:00Z". Shown as "Submitted at".
`phone`	optional	Customer phone number.
`city`	optional	Customer city. Joined with country into a "Location" field, e.g. "Jakarta, ID".
`country`	optional	ISO 3166-1 alpha-2 code, e.g. "US", "ID", "SG". Drives the country flag beside the customer name.

Minor units, always

amount must be an integer in the smallest currency unit, consistent with Stripe and most payment processors. Send 4990 for $49.90 rather than 49.90. Viably divides by 100 before display and sums raw integers for batch totals and periodic reports, so sending major units makes every revenue figure a hundred times too large.

Code examples

Call the relay from your payment success handler, after your payment provider confirms the charge. Store the token in an environment variable rather than in source code.

const VIABLY_TOKEN = process.env.VIABLY_RELAY_TOKEN;
const VIABLY_URL  = "https://hq.viably.app/relay";

await fetch(VIABLY_URL, {
  method: "POST",
  headers: {
    "Authorization": `Bearer ${VIABLY_TOKEN}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    amount: 4990,                           // required — minor units (4990 = $49.90)
    currency: "USD",                        // required — ISO 4217
    name: "Samuel Chan",                    // recommended
    email: "[email protected]",                // recommended
    description: "Pro Plan — Monthly",      // recommended — shown as Product
    source: "pay.myapp.com",                // optional — shown in message footer
    title: "New Transaction",               // optional — overrides card header
    submitted_at: new Date().toISOString(), // optional — ISO 8601
    phone: "+6287712121212",                // optional
    city: "Jakarta",                        // optional
    country: "ID",                          // optional — ISO 3166-1 alpha-2
  }),
});

Channel override

Route individual events to a specific Slack channel by adding a channels array to the payload, "channels": ["C0XXXXXXX"]. Viably routes to those channels instead of the endpoint default, as long as the bot is a member.

Spawn a task per transaction

Turn on Spawn a task for the endpoint to create an owned, claimable task from each transaction, assigned to a teammate or left up for grabs. Handy for high-touch follow-up on new or large payments. See the Auto-create tasks guide.

Periodic reporting

Enable Batch Mode on a Non-Stripe Transactions relay to accumulate events over a configurable window and post a single summary card rather than one message per transaction. Enable Periodic Reporting to also receive a scheduled revenue digest on a daily or multi-day cadence.

Revenue total

Viably sums the amount values across all events in the batch window and displays a Total Revenue figure. The sum is computed from the raw integers you send, so the minor-unit convention is load-bearing and a stray decimal will corrupt every report total.

Transaction carousel

Up to 20 transactions are shown newest first as swipeable cards. Each card shows amount and submission time as the title, customer name with country flag as the subtitle, and email, phone, city, and product in the body.

Revenue sparkline

When events span more than one time bucket, a sparkline such as ▁▂▄▇█▅▂▁ shows the relative revenue distribution across buckets at a glance, where taller bars mean more revenue in that slot.

Period label

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.

Common questions

What teams ask before they turn this on.

Does this work with providers other than Stripe?

Yes, that is what it is for. Any provider or backend that can send an HTTP POST works, including Paddle, Lemon Squeezy, Razorpay, a payment processor with no Slack integration at all, or your own billing code.

What do I have to send?

A type of transaction and an amount is enough to get a card in Slack. Adding the customer email is what makes the payment attach to a contact, so the revenue can be attributed back to the channel that won that customer.

Can we get a revenue summary rather than a message per payment?

Yes. Periodic reporting posts a digest on the schedule you choose, covering what came in and where it came from, which suits teams whose payment volume would otherwise make the channel unreadable.

Is there a server to run?

No. The endpoint is hosted by Viably, so the only thing on your side is the POST. Nothing to deploy, monitor, or keep patched.

Get started

Create a payment relay endpoint. It works with any provider that can send a POST, on the free plan.

Add Viably to Slack

See it in actionWebhook Relay