Guide · Melbourne
When Stripe webhooks fail and your CRM goes quiet
Paid in Stripe but nothing in HubSpot or Zoho? A Melbourne triage guide for failed webhooks, duplicate events, and CRM sync that stopped without warning.
The symptom that wastes a whole morning
Finance sees a successful charge in Stripe. Sales or memberships open HubSpot, Zoho, or your donor CRM and find nothing for that customer. Or worse: the contact exists twice, so the automation that should have fired never did. Melbourne teams often spend half a day arguing about “which system is wrong” when the real issue is a broken webhook or middleware path.
This guide is a practical triage for owners and ops leads. It will not replace a scoped repair, but it should get you to a clear root cause class before you rewrite your CRM.
What a Stripe webhook is supposed to do
When a payment, subscription update, or refund happens, Stripe sends an HTTP event to a URL you control (or to a connector like Zapier, Make, or a native HubSpot app). That receiver should acknowledge the event quickly, update your CRM or database idempotently (the same event twice must not create two records), and log failures where a human can see them.
When any of those steps fail, money can still move in Stripe while your CRM stays quiet. That is not “CRM randomness.” It is an integration outage.
Five failure patterns I see most often
- Endpoint returned 4xx after a deploy. Someone changed the webhook URL, auth header, or signing secret. Stripe retried, then stopped. Dashboard shows delivery errors; CRM never heard.
- Duplicate deliveries without idempotency. The webhook fired twice (or was replayed) and your handler created two contacts, two deals, or two membership flags. Follow-ups land on the wrong record.
- Test-mode and live-mode mix-up. Staging forms or an old automation still use test keys or a test webhook secret in production. “It worked yesterday” was a false positive.
- Connector silent-fail. Zapier/Make/Cloud Function hit a rate limit or auth error and has no alert. The run history is red; nobody watches it.
- Identity mismatch. Checkout used one email; the CRM lead used another (or a form created Contact A while Stripe created Customer B). The webhook “succeeded” against the wrong person.
A twenty-minute triage you can run today
Pick one known payment: time, amount, customer email, and what should have happened in the CRM.
In Stripe, open the payment and inspect Events / Webhooks for that window. Note success vs failure responses. In your CRM, search by email and read activity around the same minute. If you use Zapier, Make, or Cloud Functions, open that run log for the same timestamps.
If Stripe shows failed deliveries, fix the receiver first. If Stripe shows `200` but the CRM is empty, the break is after acknowledgement: mapping, filters, or the wrong CRM object. If both systems have partial truth, you have a source-of-truth problem; see the companion guide on Stripe vs CRM disagreement.
What “fixed” looks like
Healthy Stripe→CRM plumbing has three properties: idempotency (replays are safe), observability (failures alert a person), and clear ownership (Stripe owns “money moved”; the CRM owns relationship stage). Until those exist, spreadsheet reconciliation will keep returning.
For Melbourne businesses that need this repaired without a six-week agency project, a fixed-price workflow rescue is usually the right first step: diagnose one broken path, patch it, then decide whether hardening or a larger owned dashboard is worth it.
- I can find the Stripe webhook delivery for a test payment I just made.
- Failed deliveries notify someone within an hour, not next month.
- Replaying the same event does not create duplicate CRM records.
When to get help
Bring someone in when duplicates are systemic, when renewals succeed in Stripe but memberships stay inactive in the CRM, or when you have rotated keys and still cannot get a clean delivery. If the triage above takes more than an hour for a single payment class, the integration path needs a map, not another silent Zap.