Razorpay + Stripe Daily Fee Leakage Report: Processing Cost Anomalies to Slack via Pipedream

Catch the day your payment processor quietly started charging you more — before it compounds into a material variance.

The flow
Razorpay logo
Source
Razorpay
Stripe logo
Process
Stripe
Pipedream logo
Process
Pipedream
Slack logo
Destination
Slack

The stack in the order it runs — data flows from the source through to where it lands.

Why this stack

Most founders running dual gateways — Razorpay for India, Stripe for the rest — check revenue religiously and never look at fees. That's the mistake. Gateway fees drift. A misconfigured payment method, a currency conversion you didn't catch, an MDR tier change nobody told you about. You won't see it until month-end when the damage is already four figures deep. This playbook computes daily fee-to-revenue ratio per gateway and alerts you the moment either one deviates from baseline.

Pipedream is the right glue here. It handles both REST API calls natively, no separate database needed, and lets you write real JavaScript inline for the ratio math. You don't need Make or n8n for something this stateless — Pipedream's step-chaining is leaner for two API calls plus arithmetic plus a Slack POST.

Razorpay's `/v1/payments` endpoint returns `fee` and `tax` per transaction. Stripe's `/v1/balance/history` returns `fee` per charge event. Both are paginated. Handle `has_more` correctly or you'll compute ratios on partial data and get false alerts every single morning.

Skip this if your daily volume is under ~50 payments per gateway. The fee ratio swings too wildly on low volume to be a reliable signal — run it weekly in a spreadsheet instead. This is for teams doing $10K+/day across gateways where a 0.2% fee rate shift is worth catching immediately.

The stack (4)

  1. Razorpay logo

    Payments + payouts built for India.

    Webhooks and the reports API make revenue an automatable signal, not a dashboard you check.

  2. Stripe logo

    Global payments with first-class APIs.

    Events + Sigma let you wire billing into any ops report or alert.

  3. Pipedream logo

    Code-level workflows with hosted triggers.

    Drop into Node/Python mid-flow when no-code hits a wall.

  4. Slack logo

    Team chat where most ops alerts and reports land.

    The default place a small team already lives — pipe reports here instead of email nobody opens.

How it runs

  1. 1

    Create a Pipedream workflow with a daily schedule trigger

    In Pipedream, create a new workflow and set the trigger to 'Schedule'. Use cron expression `0 8 * * *` — fires at 8 AM UTC daily. Name the workflow `fee-leakage-monitor`. Store your Razorpay Key ID and Secret plus your Stripe Secret Key as Pipedream environment variables: `RAZORPAY_KEY_ID`, `RAZORPAY_KEY_SECRET`, `STRIPE_SECRET_KEY`. Never hardcode credentials in steps.

  2. 2

    Fetch yesterday's Razorpay payments with fees

    Add a Node.js code step. Call `GET https://api.razorpay.com/v1/payments?from={unix_start}&to={unix_end}&count=100` with Basic Auth using your Key ID and Secret. Compute `unix_start` and `unix_end` as yesterday 00:00:00 and 23:59:59 UTC. Loop through pages using the `count` + `skip` pattern until you've pulled every record. Sum `amount`, `fee`, and `tax` across all captured payments — all in paise, so divide by 100 to get INR.

  3. 3

    Fetch yesterday's Stripe balance transactions

    Add a second Node.js step. Call `GET https://api.stripe.com/v1/balance/history?type=charge&created[gte]={unix_start}&created[lte]={unix_end}&limit=100` with Bearer auth. Paginate via `has_more` and `starting_after` cursor — this is the most common place this breaks, so don't skim it. Sum `amount` and `fee` across all objects. Both fields are in cents, so divide by 100 for USD.

  4. 4

    Compute fee ratios and compare to baseline

    In a third Node.js step, calculate `rzp_fee_ratio = (rzp_total_fee / rzp_total_amount) * 100` and `stripe_fee_ratio = (stripe_total_fee / stripe_total_amount) * 100`. Hardcode your known baseline ratios as constants — for example, `RZP_BASELINE = 2.1` and `STRIPE_BASELINE = 2.9`. Derive these by averaging the past 30 days manually the first time you set this up. Flag a gateway if its ratio deviates more than `0.25` percentage points from baseline in either direction. Export `{ rzp_ratio, stripe_ratio, rzp_flagged, stripe_flagged, rzp_revenue, stripe_revenue }` for the next step.

  5. 5

    Build a Slack message with context, not just numbers

    Add a Slack step — Pipedream has a native Slack action. Post to `#ops-alerts` or `#finance`. Use Block Kit: one section per gateway showing revenue processed, total fees charged, effective fee rate, and a ✅ or 🚨 flag. Only include the alert emoji and a bolded 'ACTION REQUIRED' line when a gateway is actually flagged. Don't post a wall of green checkmarks daily — you'll train people to ignore the channel and then the one alert that matters gets buried.

  6. 6

    Add a conditional early-exit for zero-volume days

    Before the ratio computation step, add a guard: if `rzp_total_amount === 0 || stripe_total_amount === 0`, post a short Slack message — 'No transactions processed yesterday on [gateway] — skipping fee ratio check' — and terminate the workflow. Division-by-zero throws an unhandled error and the silent failure is worse than the noise. This also handles weekends and holidays cleanly.

  7. 7

    Log daily ratios to Google Sheets for baseline drift tracking

    Add a Google Sheets step after the Slack post. Append a row to a sheet named `Fee Ratio Log` with columns: Date, RZP Revenue, RZP Fees, RZP Ratio, Stripe Revenue, Stripe Fees, Stripe Ratio. After 30 days of data, update your hardcoded baseline constants to a 30-day rolling average — do this manually once a month. That sheet is also your ammunition when you sit down to negotiate MDR rates with your gateway account manager.

Want me to build this for you instead?

Product Audit and CTO Mode run out of this same thinking. If you’re reading this thinking “I want this, but in my product” — let’s talk.

See services

More like this