Intercom + Razorpay Failed Payment Correlation: Daily Support Cost Alert to Microsoft Teams via n8n
Quantify exactly how much failed payments are costing you in support volume — and alert when that cost crosses your threshold.
The stack in the order it runs — data flows from the source through to where it lands.
Payment failures generate support tickets. Every failed UPI payment, expired card, or bank decline creates a confused user who opens a chat. Most teams track support volume and payment failures in separate tools and never connect them. The result: you tune your Razorpay retry logic in isolation without knowing it's driving 30% of your Intercom conversation volume and a measurable jump in support cost per transaction.
Intercom stores conversation data with timestamps, tags, and CSAT. Razorpay's payment API returns failure reasons at the transaction level — `error_code`, `error_description`, `error_source`. Join those on date and user email and you can answer: what % of today's support conversations were preceded by a payment failure in the last 24 hours for the same user?
This workflow needs a real join operation — matching Razorpay failed payments to Intercom conversations by user email and timestamp proximity. n8n's Function nodes let you write that matching logic in JS. Make could technically do it with iterators and aggregators, but it's clunky. n8n on a $20/month cloud plan handles this cleanly.
One real constraint: Razorpay's API returns payment data but doesn't push webhooks for failures in batch — you have to poll. If your transaction volume is above 10,000/day, polling the last 24 hours will hit pagination limits. At that scale, set up Razorpay webhooks to write to a Supabase table and query Supabase instead. Also skip this entirely if you're pre-PMF with fewer than 100 transactions per day — the correlation will be statistically noisy. This pays off at $50K+ MRR where support cost is a real line item and payment failure rate directly moves EBITDA.
The stack (5)
The universal data scratchpad.
Still the fastest place to land tabular data everyone can read.
Chat + channels for Microsoft-365 shops.
If the company is on Outlook/365, Teams is where reports get read — push there, not a separate tool.
How it runs
- 1
Set up a daily 7 AM scheduled trigger in n8n
In n8n, create a new workflow. Add a Schedule Trigger node set to run at 07:00 every day. Set the timezone to match your business ops timezone. Name the workflow `Intercom-Razorpay Support Cost Correlation`. Connect a Slack or email notification to the workflow's error path — if this breaks silently, you lose your daily signal without knowing it.
- 2
Fetch failed Razorpay payments from the last 24 hours
Add an HTTP Request node. Method: GET. URL: `https://api.razorpay.com/v1/payments?count=100&from={unix_24h_ago}&to={unix_now}`. Auth: Basic with your API key and secret. After this, add a Function node and filter for payments where `status === 'failed'`. Extract `id`, `email`, `contact`, `amount`, `error_code`, `error_description`, `created_at`. That's your failure list for the day.
- 3
Fetch Intercom conversations from the last 24 hours
Add another HTTP Request node. Method: GET. URL: `https://api.intercom.io/conversations?created_after={unix_24h_ago}`. Auth: Bearer token — your Intercom access token. Use n8n's pagination handling: set the `page` param and loop until `pages.next` is null. Extract `id`, `created_at`, `user.email`, `tags`, and `conversation_rating` (CSAT) for each conversation.
- 4
Join failed payments to conversations by email and time window
Add a Function node. For each Intercom conversation, check two things: does `user.email` appear in your failed payments list, AND is the payment `created_at` within 4 hours before the conversation `created_at`? If both are true, tag it `payment_failure_driven`. Then compute: `payment_driven_count`, `total_conversation_count`, `correlation_pct = payment_driven_count / total_conversation_count * 100`. Also compute estimated support cost: `payment_driven_count * avg_handle_cost` — hardcode your actual cost-per-ticket here, e.g., $8.
- 5
Break down failures by Razorpay error code
In the same Function node or a new one, group the matched payment failures by `error_code`. The three Razorpay codes that matter most: `BAD_REQUEST_ERROR` (usually card declines), `GATEWAY_ERROR` (bank-side failures), `SERVER_ERROR` (Razorpay infra issues). Output a breakdown as `{error_code: count}`. This tells you whether the support surge is something you can fix — add a card retry prompt — or external noise like bank downtime.
- 6
Append the daily summary to Google Sheets
Add a Google Sheets node set to Append Row. Sheet: `support-cost-log`. Columns: `date`, `total_conversations`, `payment_driven_conversations`, `correlation_pct`, `top_error_code`, `top_error_count`, `estimated_support_cost_usd`. This log is how you close the feedback loop — when you change your Razorpay retry logic, you'll see in this sheet whether support volume actually drops.
- 7
Post to Microsoft Teams with threshold-conditional alert levels
Add an HTTP Request node pointing at your Teams incoming webhook URL — create one via Teams > Channel > Connectors > Incoming Webhook. Build an Adaptive Card payload. If `correlation_pct > 25`, red header: `🔴 High Payment-Support Correlation`. If 10–25%, yellow: `⚠️ Moderate`. Below 10%, skip posting entirely — no one needs a green-state ping every morning. The card body should show the four key numbers, top error code, and estimated daily support cost, plus a direct link to the Razorpay dashboard filtered for failed payments.
- 8
Add a weekly trend summary on Fridays
Add an IF node that checks whether today is Friday. If yes, query the last 7 rows of your Google Sheets log, compute week-over-week change in `correlation_pct` and `estimated_support_cost_usd`, and append a trend block to the Teams message: `📊 Week trend: support cost from payment failures {up/down} {X}% vs last week`. You get a strategic review artifact without building a second workflow.
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 servicesMore like this
Google Analytics 4 + HubSpot Lifecycle Stage: Weekly Acquisition-Quality Digest to Slack via Pipedream with Claude Narrative
Stop reporting traffic numbers. Report whether the traffic you paid for last week actually became pipeline — with a one-paragraph executive summary written by Claude.
Gmail Thread Aging + Stripe Invoice Overdue: Unified AR Follow-Up Digest to Slack via Zapier
Surface overdue Stripe invoices and the exact age of your last Gmail thread with that customer — every morning at 8:30, automatically — so AR follow-up stops living in someone's head.
Outlook Calendar Load + HubSpot Deal Velocity: Weekly Ops Digest to Microsoft Teams
Every Monday at 07:30, your revenue team gets one Teams card: last week's deal pipeline movement next to each rep's actual meeting load — so you stop guessing whether low close rates are a pipeline problem or a capacity problem.