How do I automate HubSpot workflows after a payment or invoice?
Enroll on the payment associated to the deal or the contact, stamp a date property, then branch. That covers the owner notification, the onboarding kickoff and the plan label read from the line items. It needs Commerce Hub with a connected processor, and workflows at a Professional tier. The trap is recurring billing: one payment record per charge, so without a guard property month two notifies the owner again and restarts onboarding.
The 12 specs, in build order
Each spec states its minimum tier. Free ones open in full; the others show their public preview and the date their full spec lands.
What a spec looks like
Every spec follows the same nine sections, so a team reads one and knows how to read all of them.
- Outcome, when to use it and when not to
- Prerequisites: properties, lists, tiers, with the JSON to create them
- Enrollment and re-enrollment, then every step with its parameters
- Known pitfalls, a test plan, variants, and the YAML build spec
What breaks, and how the specs prevent it
Copy property value reads the enrolled record, so a deal workflow cannot pull the amount off the associated payment into a deal property. The payment spec says so and gives the two ways out: build the workflow on the payment object and copy down to the deal, or use a custom coded action at Operations Hub Professional. Settle that before you promise finance an amount paid to date field that is always right.
Recurring billing creates one payment record per charge. Without the payment received date is unknown filter, the owner gets pinged on every renewal and the paid status flips back and forth. On the onboarding side the same guard, onboarding start date is unknown, is the only thing stopping month two from restarting the kickoff for an existing customer. Do not remove either one to fix an unrelated problem.
Refunds create their own record. The deal keeps reading paid in full, and the plan label keeps sitting on the contact, because a refunded payment can keep its paid status. Both specs carry the companion workflow in their Variants and neither pretends the base version handles it. If refunds are common for you, build the reverse before you switch the forward version on.
What this bundle builds
Money landing in the portal is a signal most teams waste. The receipt sits in a shared finance inbox, the rep finds out on Thursday, onboarding starts whenever someone forwards the email, and the plan the customer bought lives in the billing system where marketing cannot segment on it.
These twelve specs close that gap on the CRM side. A successful payment stamps a date and a paid status on the deal and tells the owner within minutes. The same event, read on the contact, flips the lifecycle stage, creates the kickoff task, opens the onboarding ticket and sends the welcome email fifteen minutes later so it does not race the processor receipt. A coded action walks the payment to its line items to their products, then writes the plan label and start date onto the contact. Around that sit the quote alerts that precede the payment, the line item checks that keep the deal amount honest, and the renewal and dunning specs for when a charge fails.
The native template gallery confirms the demand: telling deal owners about a payment, onboarding after one, and reminding customers to renew each carry more than 800 installs. Setting the product plan from payments carries over 100. These specs go further, with guard properties, a partial payment branch and a failure path.
How the pieces fit together
Start with the payment stamp on the deal. Everything downstream reads the property it writes, and building it tells you within an hour whether your portal exposes payment filters on deal workflows. If it does not, build the payment object workflow from its Variants first and let the rest trigger on the stamped date.
Onboarding comes second. Same enrollment answer, plus a guard property of its own, plus a decision about the welcome email, since automated marketing emails need Marketing Hub Professional and a sequence needs an owner with a connected inbox.
The plan lookup comes third, because it needs a plan name property on each product in the library before the code has anything to read. The line item checks pair with it: one flags a deal heading for close with no line items, the other compares the amount against the line item total.
Quotes and renewals sit at either end. Quotes feed the payment. Dunning and the billing signal react after it, and both depend on something outside the portal writing a payment status property.
What you get
- 12 specs, each with outcome, prerequisites, enrollment, steps, known pitfalls, a test plan and variants
- Each spec ships as PDF and Markdown
- Properties JSON, 28 properties across contacts, companies, deals, quotes and products, plus one custom object
- Workflow JSON for all 12, in Automation API format, switched off on import
- 3 custom coded actions as JavaScript files, with inputs, outputs and secret names in the header
- A test plan per spec, each written for a processor in test mode and a test card, not a live charge
- The fallback enrollment path documented per spec, for portals without associated payment filters
- Install in one click for Full and Agency buyers
Who it is for, and who should skip it
Take this if you collect money inside the portal through payment links, quotes with payment or invoices, and the CRM currently learns about it last. Self serve and low touch businesses get the most: payment really is the start signal, so the onboarding spec alone removes a manual step from every sale.
Skip it if billing lives entirely outside the portal with nothing synced back. No payment or invoice record means nothing to enroll on, and the honest answer is to sync a plan and a status property from the billing system directly, then build the dunning and renewal specs on those. Skip it too on a Starter tier. Simple automation cannot run any of this.
Questions admins ask
Do I need Commerce Hub to automate on a payment?
You need a connected payment processor, because without one no payment record is ever created and the workflow has nothing to enroll on. Payments, quotes with payment and invoices are the Commerce tools that produce those records. Availability and the per transaction fee depend on your subscription and on the processor you connect, which the plan spec flags as something to check rather than assume, since it has changed more than once.
Does this work outside the United States?
There are two processing paths and only one is US only. HubSpot payments requires a business based in the United States. Everywhere else, you connect Stripe payment processing through the portal and the payment records behave the same way for automation. Both payment specs name this and mark the exact country coverage as something to confirm in your own payments settings before building.
Can a workflow enroll on a payment or an invoice record?
That is the one thing to verify first, because the whole build order depends on it. If payment and invoice properties appear as associated object enrollment filters on your deal and contact workflows, enroll directly. If they do not, each spec carries the same fallback: a workflow on the payment object whose only job is to stamp a date onto the deal or the contact, and the main workflow then triggers on that property becoming known.
Can a workflow set the product plan from the line items?
Yes, with code. Line items are children of the payment, the invoice, the quote or the deal that created them, not of the contact, so a plain contact filter cannot see them. The plan spec uses a custom coded action at Operations Hub Professional to walk those associations and read a plan name property off the product, which is what keeps a product rename from breaking the mapping. It also ships a no code version, one active list per plan, that costs one workflow per plan and breaks when a contact buys two.
Are all twelve specs published already?
No, and the release dates are public. The quote reminder, the renewal amount and the missing line items specs land in late September and October. The payment failure alert and the finance notification land in November. The three Commerce Hub specs at the heart of this page, the payment stamp, the onboarding kickoff and the plan from line items, are scheduled for 25 December 2026, with the subscription object and the amount validation earlier in December. Buying the full library gets you each one on its date.