Get Alerted on Every Payment Moment That Matters

The problem

Your first paid user signs up at 11:14pm on a Tuesday. You find out Wednesday morning from a Stripe email buried in a shared billing inbox that nobody actively watches. The single most important moment in the early life of your product just happened, and the signal came twelve hours late through the worst possible channel.

Or: a customer’s payment fails. Their subscription goes into grace period. Three days later they churn because nobody on your team saw the failure in time to reach out and fix the card on file. A save that would have taken one email went unmade because the notification went to an address nobody reads.

The failure mode is not that payment processors lack notifications. Stripe, Paddle, LemonSqueezy, PayPal, and every other processor send notification emails, run dashboards, and fire webhooks. The failure mode is that the emails land in shared billing inboxes that nobody watches, the dashboards require manual logins, and the webhooks are raw payloads that nobody has wired up to the channels where people actually work.

Payment moments are inherently high-signal. Every single one of them matters, because every one of them either moved revenue or lost it. These events deserve the best notification path you have, not the worst.

The general shape of the fix

Every modern payment processor supports outbound webhooks. You pick the specific events you care about, forward them to API Alerts, and your phone buzzes the moment they fire. Different events can use different channels: first paid user on a wins channel, failed renewals on a retention channel, chargebacks on a finance channel. One app, one tap, straight to the detail that matters.

The principles that make this useful instead of noisy:

Filter to the events that matter. Stripe sends around 50 different webhook event types. You probably care about 5 to 10 of them at most: subscription created, subscription canceled, payment succeeded for the first time, payment failed, refund issued, dispute opened. Resist the urge to wire them all.
Include enough context to skip the dashboard trip. The notification should be readable on its own: amount, customer identifier, plan name, and whatever else a human needs to decide if this requires immediate action.
Split different events across different channels. First-paid-user events on a personal channel (a moment of celebration). Failed payments on a retention channel. Chargebacks on a finance channel. Each channel is its own feed in the mobile app, so wins, failures, and disputes never pile into one mixed stream.
Two implementation paths. Either your backend receives the payment processor webhook and calls API Alerts directly (more control, requires a backend), or Zapier bridges the two (no code, requires a Zapier plan). Both are legitimate. Pick based on whether you already have a webhook receiver in your stack.

What this unlocks: the emotional moments buzz your phone at the instant they happen. The operational moments land in the channel owned by the person who can act. And your inbox stops filling up with Stripe digest emails that you read three times and then start filtering.

Implementation by payment processor

Stripe (via your backend)

Stripe’s webhooks are the most powerful path because the event list is deep, the filtering is precise, and you keep full control of the payload. The trade-off is that you need a backend endpoint to receive the webhook, and you need to handle the signature verification.

// Node.js with Express and the official Stripe SDK
import Stripe from 'stripe'
import express from 'express'
import { ApiAlerts } from '@apialerts/apialerts-js'

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY)
const app = express()

ApiAlerts.configure(process.env.API_ALERTS_KEY)

app.post('/stripe/webhook', express.raw({ type: 'application/json' }), async (req, res) => {
  let event
  try {
    event = stripe.webhooks.constructEvent(
      req.body,
      req.headers['stripe-signature'],
      process.env.STRIPE_WEBHOOK_SECRET
    )
  } catch (err) {
    return res.status(400).send(`Webhook Error: ${err.message}`)
  }

  switch (event.type) {
    case 'customer.subscription.created': {
      const sub = event.data.object
      await ApiAlerts.sendAsync({
        channel: 'revenue',
        event: 'subscription.created',
        title: 'New paid subscription',
        message: `${sub.customer} started ${sub.items.data[0].price.nickname}`,
        tags: ['stripe', 'new-customer'],
      })
      break
    }
    case 'invoice.payment_failed': {
      const invoice = event.data.object
      await ApiAlerts.sendAsync({
        channel: 'retention',
        event: 'payment.failed',
        title: 'Payment failed',
        message: `${invoice.customer_email} could not renew (${invoice.amount_due / 100} ${invoice.currency})`,
        tags: ['stripe', 'failure'],
      })
      break
    }
    case 'charge.dispute.created': {
      const dispute = event.data.object
      await ApiAlerts.sendAsync({
        channel: 'finance',
        event: 'dispute.created',
        title: 'Chargeback received',
        message: `${dispute.amount / 100} ${dispute.currency} disputed by ${dispute.reason}`,
        tags: ['stripe', 'chargeback'],
      })
      break
    }
  }
  res.json({ received: true })
})

Each channel (revenue, retention, finance) shows up as a separate feed in the API Alerts mobile app, so wins, failures, and chargebacks each stay on their own stream instead of piling into one mixed inbox.

See the JavaScript SDK reference for the full API surface, and the same pattern works in Python, Go, and every other SDK we ship.

Stripe (via Zapier, no backend)

If you do not have a backend receiving webhooks, Zapier handles the bridge without any code.

In Zapier, create a Zap with a Stripe trigger (options include “New Charge”, “New Customer”, “New Invoice”, “Failed Charge”, “New Subscription”)
Add an API Alerts action as the next step
Map the Stripe fields (customer, amount, plan) into the API Alerts event payload
Turn on the Zap

Zapier handles Stripe’s authentication and webhook setup for you. The trade-off: you can only use the Stripe triggers that Zapier exposes, and each Zap costs against your Zapier task quota. For high-volume flows the backend path is cheaper and more flexible, but for a handful of “alert me on these moments” triggers, Zapier is the fastest path to value.

Paddle

Paddle emits webhooks for events like transaction.completed, transaction.payment_failed, subscription.created, subscription.canceled, and subscription.updated. The pattern is identical to Stripe: receive the webhook in your backend, verify the signature, call API Alerts with a clean event.

// Simplified Paddle webhook handler
app.post('/paddle/webhook', express.json(), async (req, res) => {
  const event = req.body
  if (event.event_type === 'transaction.completed') {
    await ApiAlerts.sendAsync({
      channel: 'revenue',
      event: 'paddle.transaction.completed',
      title: 'New Paddle transaction',
      message: `${event.data.customer.email} paid ${event.data.details.totals.total / 100}`,
      tags: ['paddle', 'new-customer'],
    })
  }
  res.json({ received: true })
})

Paddle also has a Zapier integration if you prefer the no-code bridge.

LemonSqueezy

LemonSqueezy has a clean outbound webhook surface and strong developer ergonomics. Event names include order_created, subscription_created, subscription_payment_success, subscription_payment_failed, and subscription_cancelled.

The backend pattern works identically to Stripe and Paddle. LemonSqueezy also has a first-party Zapier integration, which makes it a particularly good fit for indie developers who want fast setup.

Chargebee

Chargebee is more enterprise-oriented and has a heavier API surface, but the webhook flow is the same. Events like subscription_created, invoice_generated, payment_succeeded, and payment_failed fire on the corresponding moments. Receive, transform, and call API Alerts.

Polar

Polar is a newer indie-focused payment platform with strong Stripe-like ergonomics. Polar webhooks include subscription.created, subscription.canceled, and order.created. Follow the same backend pattern or use Zapier.

PayPal

PayPal’s notification story is PayPal-specific and complex (IPN, webhooks, REST API notifications, all with different formats and evolution histories). The realistic path is: use the modern webhooks API if you have a backend, or use Zapier’s PayPal integration if you do not. PayPal is the case where Zapier usually wins on developer time even if it costs a few tasks.

Gumroad

Gumroad sends a simple “ping” webhook on sale events. The payload is straightforward: product ID, price, customer email, timestamp. For indie creators and digital product sellers, this pairs naturally with API Alerts as the “ping me on every sale” layer.

# Gumroad pings a URL you provide, with form-encoded fields.
# Receive it in any minimal backend (even a Cloudflare Worker or a Vercel function)
# and forward to API Alerts:
curl -X POST https://api.apialerts.com/event \
  -H "Authorization: Bearer $API_ALERTS_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "channel": "revenue",
    "event": "gumroad.sale",
    "title": "New Gumroad sale",
    "message": "New sale: $29 from a customer in NZ",
    "tags": ["gumroad", "sale"]
  }'

Any payment processor with a webhook

If your payment processor is not listed above but has webhook support, the pattern is the same: receive the webhook in your backend, verify the signature (critical, do not skip this), transform into an API Alerts event shape, and call the SDK or HTTP API.

Zapier integration. The no-code bridge for payment processors when you do not have a backend webhook receiver.
JavaScript SDK, Python SDK, Go SDK, and the rest of the SDKs. Use whichever matches the language your webhook receiver is written in.
HTTP API introduction. The event schema for any language not covered by a first-party SDK.

Get started in 5 minutes

Create a free workspace and grab an API key
Pick the one payment event you want your phone to buzz for tonight (probably: “new paid subscription” for indie devs, “payment failed” for retention-focused teams)
Choose your path: backend webhook handler (more control) or Zapier bridge (no code)
Wire the webhook to API Alerts using the snippet for your payment processor above
Trigger a test payment and watch the notification land on your phone

Use separate channels for different event types so wins, failures, and chargebacks live in their own feed. Free tier is 1,000 events per month, which comfortably covers every high-signal revenue moment for any early-stage product.