As a startup founder, ensuring that customer communication is seamless is a top priority. For us, Intercom was the backbone of those conversations. It powered not only our in-app chat but also emails and automated support workflows. So you can imagine the panic when our messenger suddenly disappeared from our site—without warning. After digging deep, we discovered that the root cause was a failed payment that triggered Intercom’s billing system to disable features, and it took even deeper digging to uncover that a webhook retry fix could restore everything.
TLDR
When our Intercom subscription payment failed due to a temporary credit card issue, the billing system automatically downgraded our account and disabled key features like the site messenger. This broke customer communication until we reactivated the payment. However, restoring messenger functionality required additional steps involving webhook retries from Stripe to Intercom. By manually retrying the failed webhooks and confirming event delivery, we were able to bring conversations back online.
Understanding What Went Wrong
Initially, the disappearance of the Intercom messenger on our site felt like a bug. There were no emails, no in-app alerts, and no loud red banners on the dashboard. The widget—critical to our support and lead conversion strategy—was just gone.
After checking our Intercom settings, website code integrations, and even browser console logs, we found nothing broken on the client-side. Only after logging into the billing section did we spot a note: “Service downgraded due to unsuccessful payment.”
This raised a couple of questions:
- Why was the payment unsuccessful? A quick check revealed our corporate card had recently expired, and the renewal details hadn’t updated in Intercom’s payment system.
- Why did Intercom disable critical functionality without proper notice? While we did receive a standard billing email, there was no clear indication that the messenger would be disabled, making the issue harder to diagnose in real-time.
Impact on User Experience
The most significant consequence of the disabled messenger was the sudden silence of user interactions. Site visitors could no longer initiate conversations. Open conversations in the inbox went dormant, and our resolution rates declined significantly over the next 48 hours.
This directly impacted:
- Lead capture: Fewer qualified leads entered our funnel.
- Customer support: Open tickets weren’t escalated promptly, leading to user frustration.
- Onboarding: New users received no contextual help via chat triggers.
We realized how critically our daily operations depended on a single tool working flawlessly—and worse, how vulnerable we were to silent failures caused by billing-related automations.
The Root Cause: Failed Payment and Billing Automation
Digging into the logs and billing communication from Stripe revealed the issue began with a declined charge attempt. Intercom’s automated billing system, once it detected the failure, downgraded our plan. As part of the downgrade, the messenger widget was silently disabled from the front end.
Here’s a brief sequence of what happened:
- Credit card on file expired and failed to process a renewal payment for our subscription.
- Stripe generated a
invoice.payment_failedevent. - Webhook delivering this event to Intercom failed or was not handled properly.
- Intercom’s system eventually treated the payment as “unrecoverable” and disabled premium features like the messenger.
The missing link here? The webhook. Even after the card was updated and the payment retried manually, the messenger didn’t automatically come back. That led us to the critical realization: the webhook delivery needed fixing too.
The Fix: Manually Retrying The Failed Webhook
Stripe logs every webhook it sends out, along with their delivery status. We inspected the webhook event history for our Intercom integration and found a red “X” on the invoice.payment_succeeded event that confirmed the payment had finally gone through.
Even though Stripe had successfully charged the card on the second attempt, the event wasn’t received by Intercom’s system due to a transient delivery error. As a result, Intercom never “heard” that payment succeeded—it still believed the subscription was in arrears.
Luckily, Stripe allows you to retry webhook deliveries manually:
- Log into your Stripe dashboard
- Navigate to Developers > Webhooks
- Find the relevant event (usually
invoice.payment_succeeded) - Click on the failed delivery, then hit the ‘Retry’ button
One minute later—without needing to contact Intercom support—the messenger widget reappeared on our site automatically. Conversations resumed. Inbox activity normalized. It was as though nothing had ever gone wrong.
Why Webhook Delivery Matters
Most SaaS platforms rely on webhook infrastructure to manage subscriptions and billing-dependent features. A downed or silently-failing webhook can leave services in inconsistent states, especially when billing status directly controls feature access.
Hence, well-functioning webhook retries and clear logs are essential for:
- Consistency across systems: Ensures platforms like Intercom update internal state with real-time payment data from Stripe.
- Automated recovery: When the webhook is retried successfully, the systems can self-heal without manual intervention.
- Audit trails: Allows developers to investigate exactly what failed and when.
What Intercom Could Improve
While we resolved the issue ourselves, several points in the user experience left us disappointed—and with lessons to teach Intercom:
- More visible warnings: When a messager is disabled, there should be a proactive alert in the dashboard, not just passive email communication.
- Dashboard webhook monitoring: A mapping or log of inbound events like successful payments could reduce support tickets and make users more self-reliant.
- Grace period logic: Allow a longer recovery window before disabling critical communication features.
While we understand the need to enforce payment discipline, the cost in terms of user trust and support backlog can be greater than the overdue invoice amount.
Lessons Learned
This incident reinforced several key lessons:
- Monitor subscription payments as you monitor your uptime. A failed billing event can be just as damaging to service availability.
- Know your webhooks. Maintain observability of which critical third-party platforms rely on Stripe events or similar notifications.
- Build redundancy into user interaction paths. If a chat widget disappears, ensure fallback support channels like email or a contact form are available.
And most importantly: successfully resolving a payment doesn’t always fix the downstream effects. Webhook-driven integrations sometimes need to be nudged manually to bring services back in sync.
Final Thoughts
Our experience dealing with a failed payment in Intercom exposed a crucial but underappreciated aspect of SaaS interoperability: payment-driven automations and their reliance on webhooks. While Intercom did what it was programmed to do, the lack of transparency, inadequate alerting, and webhook silence added unnecessary delays and user frustration.
Going forward, we’ve implemented tighter monitoring of payment statuses and webhook deliveries—especially for platforms with customer-facing components. We’ve also shared these findings with our support team, in case similar issues arise elsewhere. A lesson hard learned, but one that ultimately made our infrastructure—and our team—more resilient.
