HubSpot Commerce and Payments Integrations
The first decision in a commerce integration is whether an order belongs in the CRM as a deal, and for most businesses running transactional volume the answer is no.
A deal is an object built to carry a sales process: a stage, an owner, a forecast and a close date. An order that arrived through a checkout has none of those and never will. Creating one deal per order produces a pipeline that is a transaction log, and every pipeline report built on it is meaningless.
9 systems in this category, 1 of them documented in a published case study.
Orders, deals, and the difference between them
The useful pattern is to let orders remain orders, associated to the customer record, and to reserve deals for the situations where a human is working an opportunity: a wholesale enquiry, a renewal being negotiated, a quote requested off-catalogue.
What the CRM needs from the commerce system is a rolled-up view against the customer, not a mirror of it. Lifetime value, last order date, order frequency and category mix are four properties that change how a conversation runs. The individual line items do not.
Subscription billing adds a second consideration, because a subscription has a state that changes without anyone touching it. A card that fails at renewal is a commercial event and it happens inside the billing system, silently, unless something is listening for it.
Where a commerce integration sits between a full mirror and a referenced link
Which records stay in the commerce system and what crosses into the CRM
Systems in this category
Orders and lifetime value joined to the contact, refunds included.
Subscription and payment state on the record, priced server-side.
Store data mapped to objects rather than dropped into properties.
Catalogue and order history reconciled to one customer.
Order events resolved against an existing contact before creating one.
Subscription lifecycle events written to the deal and the company.
Churn and dunning state visible before the renewal conversation.
Point-of-sale activity attached to the customer record.
Payment confirmation joined to the deal it settles.
Documented engagements
Each of these is a published study of one build, with the object model, the decisions taken and what the approach does not establish.
Common Questions
Frequently Asked Questions
Only where a person works the order. For transactional volume, creating one deal per order fills the pipeline with records nobody manages and makes every stage report unusable. Associate orders to the customer and reserve deals for opportunities a human owns.
Rolled-up values rather than the order history: lifetime value, first and last order dates, order count and the categories bought. Those change how someone is spoken to. A full line-item mirror rarely does and is expensive to keep accurate.
As an event the CRM listens for rather than one it discovers. A failed renewal payment is a churn signal with a short window, and it only becomes actionable if the billing system pushes it out rather than waiting to be polled.
Further reading
Long-form already published on the argument this category turns on.
Related categories
A system in this category that is not listed
The directory shows range rather than limits. A scoped build is quoted from the object model on each side and the fields that have to cross between them.