How to report on Stripe failed payments and past-due subscriptions in HubSpot
A Stripe™ subscription's payment fails, and finance wants to know before it turns into a churned account — but ask HubSpot to show every subscription currently past_due or unpaid, and there's no report to run. There's no native property for it, no default view, and nothing surfaces the failure unless someone happens to check Stripe directly. The fix is mechanical, not exotic: two Stripe webhook events, a couple of properties HubSpot already lets you create on any tier, and one of HubSpot's own automation tools layered on top — which one depends on the plan you're already paying for.
Why it happens
HubSpot's own first-party Stripe Data Sync app doesn't give Subscriptions a destination below Enterprise. It can sync Customers, Invoices and Products on any tier, but the app's own listing states that syncing Subscriptions requires Enterprise, because they land as Custom Objects. Below that tier, a subscription's status field — including past_due and unpaid — has no first-party destination in HubSpot at all.
Even on Enterprise, the sync doesn't distinguish "failed once, retrying" from "genuinely at risk." It lands the raw status; nothing native notifies anyone when it changes.
On the Stripe side, a failed recurring payment doesn't fail the subscription immediately. Stripe fires an invoice.payment_failed event and, unless retries are disabled, attempts the charge again on its own schedule — tracked in the invoice's attempt_count and next_payment_attempt fields. The subscription only moves to past_due, and later to unpaid or canceled, once your account's retry settings say so. A HubSpot view that only checks Deal stage, and never listens for the Stripe event or the resulting status change, keeps showing an account as fine through the entire retry window.
Stripe's own guidance treats these as two separate signals, not one — monitor invoice.payment_failed for the failures themselves, and the subscription's status transitions separately for the outcome. It's easy to wire up only one of the two.
The retry window itself is longer than most teams assume. Stripe's own recommended default for its Smart Retries feature attempts a failed payment several times over roughly two weeks before the subscription's configured outcome (canceled, marked unpaid, or left past due) takes effect — all of it configurable per account in the Stripe Dashboard. A HubSpot workflow built to fire once, on the first failure, and never check again misses everything that happens for the rest of that window.
What you can do about it today
- Create two properties — Contact, Company or Deal, wherever your team already tracks the account — something like
stripe_subscription_statusandstripe_last_payment_failed_at. This works on every HubSpot tier; only Custom Objects are Enterprise-gated, not ordinary properties. - Subscribe to
invoice.payment_failedand the subscription-status webhook events (Stripe Dashboard → Developers → Webhooks), and write the resulting status onto those properties through a script calling HubSpot's Properties API, or a Zapier/Make automation pairing their native Stripe trigger with a HubSpot "Update record" action. - Build a HubSpot active list filtered on
stripe_subscription_statusispast_dueorunpaid. Active lists update their own membership as the property changes, and — unlike Custom Objects — they aren't gated to Enterprise. - Layer a workflow on top, if your plan includes one, to send an internal notification or create a task the moment a record enters that list. Workflows themselves need a Professional or Enterprise Marketing, Sales, Service or Data Hub subscription; the property and the list underneath don't.
- Build the report with a standard list view, or a custom report builder view on Professional or Enterprise, filtered the same way — or, on lower tiers, export the list on a schedule and treat the export as the report.
- Store the Stripe subscription ID on the record, not just the status, so a support or finance conversation can jump straight to the right subscription in Stripe instead of searching by customer name.
Where this breaks down
Nothing verifies the write landed. A missed webhook, a script that silently stops running, or a Zapier task that fails quietly leaves the property showing its last successful status — confidently wrong, with no visual difference from a record that's actually current.
Retries can leave a subscription looking fine when it isn't resolved yet. A subscription can sit through several retry attempts while correctly still past_due, and a property that only flips on the terminal outcome misses the whole window where outreach would actually help.
Deleted or re-created subscriptions can break the join. If a customer's subscription is canceled and a new one created for the same account, a status property keyed only on the latest webhook received can end up describing the wrong subscription unless the write logic checks the subscription ID, not just the account.
This reports one subscription's worst state, not account-level risk. An account with several subscriptions, one fine and one past_due, needs a rollup — a single property overwritten by whichever webhook arrived last can't represent that.
An unverified webhook endpoint is a liability of its own. Any handler receiving these events should confirm each one actually came from Stripe before writing anything to HubSpot; skipping that check to save a step turns a reporting gap into a way for anyone who finds the endpoint URL to write arbitrary status values onto live customer accounts.
What Trueness does about it
Trueness's free Drift Report already surfaces this without any of the wiring above: subscriptions that are past due, and invoices that can't be finalized, are flagged with their dollar value the same day the report runs, checked against your Stripe data directly — on every HubSpot tier, Free and Starter included. Writing the status onto a property in your portal automatically is on our roadmap; today, the report gives you the list, and updating HubSpot itself is still a step you take yourself.