1 Accepted solution
Hi @annecaylin , this isn’t that unique actually, I’ve seen this pattern a lot with events and hybrid revenue models.
You’re thinking about it the right way. You do not want to force e-commerce behavior into your main sales pipeline, and you also don’t need to touch contracts at all. The cleanest HubSpot-native approach is exactly what you hinted at: a separate Deals pipeline dedicated to badge purchases, treated as transactional revenue rather than sales-managed revenue.
From a HubSpot perspective, Deals are just revenue records. There is no requirement that a deal comes from a quote, contract, or sales workflow. If your badge system can emit events or expose an API, you can create deals programmatically with a fixed stage like “Closed won – badge purchase,” set the amount, close date, currency, and associate them to a contact or company if you have identifiers. HubSpot’s Deals API is built for this and does not require Sales tools to be involved at all: https://developers.hubspot.com/docs/api/crm/deals.
Where teams usually go wrong is trying to store this as properties on contacts or companies. That breaks down quickly for reporting, forecasting, and revenue attribution. Using a dedicated pipeline keeps lifecycle logic clean and lets you roll up total revenue across pipelines in reports, which HubSpot fully supports (https://knowledge.hubspot.com/object-settings/set-up-and-customize-pipelines )
One design decision to make early is whether you want one deal per badge purchase or batched deals per order or per day. Both work, but it affects reporting volume and attribution later.
Small disclosure since I’m close to this space: I work on Stacksync. In setups like this, teams often use it to keep external purchase systems and HubSpot deals continuously aligned without custom scripts, especially when purchases can be refunded or updated later. Mentioning it only because that ongoing sync problem tends to show up a few months after the first import.
Hope this gives you a solid starting point without having to redo your system.
Did my answer help? Please mark it as a solution to help others find it too.
 | Ruben Burdin HubSpot Advisor Founder @ Stacksync Real-Time Data Sync between any CRM and Database |
 | |
Hi @annecaylin , this isn’t that unique actually, I’ve seen this pattern a lot with events and hybrid revenue models.
You’re thinking about it the right way. You do not want to force e-commerce behavior into your main sales pipeline, and you also don’t need to touch contracts at all. The cleanest HubSpot-native approach is exactly what you hinted at: a separate Deals pipeline dedicated to badge purchases, treated as transactional revenue rather than sales-managed revenue.
From a HubSpot perspective, Deals are just revenue records. There is no requirement that a deal comes from a quote, contract, or sales workflow. If your badge system can emit events or expose an API, you can create deals programmatically with a fixed stage like “Closed won – badge purchase,” set the amount, close date, currency, and associate them to a contact or company if you have identifiers. HubSpot’s Deals API is built for this and does not require Sales tools to be involved at all: https://developers.hubspot.com/docs/api/crm/deals.
Where teams usually go wrong is trying to store this as properties on contacts or companies. That breaks down quickly for reporting, forecasting, and revenue attribution. Using a dedicated pipeline keeps lifecycle logic clean and lets you roll up total revenue across pipelines in reports, which HubSpot fully supports (https://knowledge.hubspot.com/object-settings/set-up-and-customize-pipelines )
One design decision to make early is whether you want one deal per badge purchase or batched deals per order or per day. Both work, but it affects reporting volume and attribution later.
Small disclosure since I’m close to this space: I work on Stacksync. In setups like this, teams often use it to keep external purchase systems and HubSpot deals continuously aligned without custom scripts, especially when purchases can be refunded or updated later. Mentioning it only because that ongoing sync problem tends to show up a few months after the first import.
Hope this gives you a solid starting point without having to redo your system.
Did my answer help? Please mark it as a solution to help others find it too.
| | Ruben Burdin HubSpot Advisor Founder @ Stacksync Real-Time Data Sync between any CRM and Database |
| | |
