Here's the quick version, because I know you're evaluating this right now: if your billing needs are simple and your team already lives in HubSpot, Commerce Hub will get you collecting payments today. If you need real subscription logic — metered billing, multi-currency, usage-based pricing, proration, tax compliance across borders — you need Stripe. And if you're a SaaS company past seed stage, you probably need Stripe.
But the real answer is more interesting than that, because HubSpot Commerce Hub is literally built on Stripe, and most teams end up using both. So the question isn't "which one" — it's which layer handles what.
The "powered by Stripe" secret
Most people evaluating HubSpot Payments don't realize this: HubSpot Commerce Hub uses Stripe Connect as its payment processor. When a customer pays through a HubSpot payment link, the charge is processed by Stripe. HubSpot is a Stripe Connect platform.
This matters for three reasons:
-
You're paying Stripe either way. HubSpot's processing fees (2.9% + $0.30 per card transaction) are Stripe's processing fees, passed through. You're not choosing between two payment processors. You're choosing between using Stripe directly or using Stripe through HubSpot's abstraction layer.
-
HubSpot's payment features are bounded by what Stripe Connect supports. HubSpot can't offer anything that Stripe Connect doesn't enable. When you hit a limitation in Commerce Hub — and you will — it's often because HubSpot hasn't exposed that part of the Stripe Connect API, not because the capability doesn't exist underneath.
-
Your payment data lives in both systems. Even with Commerce Hub, Stripe has a record of every transaction. If you ever outgrow Commerce Hub, your payment history is already in Stripe. The migration path isn't as painful as you'd expect.
I've talked to founders who thought HubSpot Payments was a completely separate payment processor competing with Stripe. It's not. It's a CRM-integrated interface to Stripe.
What HubSpot Commerce Hub actually handles
HubSpot rebranded "HubSpot Payments" to "Commerce Hub" in late 2023, and the feature set has grown since then. Here's what it does as of mid-2026:
Payment collection: Payment links, quotes with embedded payment, invoices, and recurring subscriptions — all created from within HubSpot's UI. No code required. A sales rep can generate a payment link from a deal record and send it in an email template. When the customer pays, the deal stage updates, a payment record is created on the contact, and revenue is attributed automatically.
CRM-native data: This is Commerce Hub's genuine advantage. Payment status, subscription state, and transaction history all live on the CRM record where your sales and CS teams already work. No integration to build, no sync to maintain, no "let me check Stripe" tab-switching.
Simple subscriptions: Monthly or annual plans with fixed pricing. You define products, set prices, and customers subscribe. It works.
ACH payments: 0.8% per transaction, capped at $10. Cheaper than card processing for larger invoices — a real advantage for B2B SaaS deals above $500/month.
What it doesn't handle:
- Metered or usage-based billing. If you charge per API call, per seat dynamically, or per compute hour, Commerce Hub can't model it.
- Multi-currency. USD only as of mid-2026. If you sell to European customers, you're forcing them to pay in dollars.
- Complex proration. Mid-cycle upgrades and downgrades produce approximate results at best.
- Automated tax calculation. No equivalent to Stripe Tax. You're on your own for sales tax, VAT, and GST.
- Advanced dunning. Failed payments get basic retry logic, but you can't configure multi-step recovery sequences with different messaging at each stage.
- Geographic availability. US-based companies only. If your entity is incorporated outside the US, Commerce Hub isn't an option.
The cost: Commerce Hub requires at minimum a HubSpot Starter plan ($20/month per seat). Processing fees are 2.9% + $0.30 per card transaction, 0.8% capped at $10 per ACH transaction. No additional subscription management fee — unlike Stripe Billing's 0.5% surcharge on its Scale plan.
What Stripe actually handles
Stripe is the default payment infrastructure for SaaS for a reason: it handles everything, and the API is good enough that you don't resent building on it.
Stripe Billing is the subscription management layer. Subscriptions, invoices, metered billing, usage-based pricing, tiered pricing, per-seat billing, proration, free trials, trial-to-paid conversion, coupons, promotional credits — all as first-class API primitives. The Billing Scale plan adds smart retries and advanced recovery tools for 0.5% of recurring charges.
Stripe Tax calculates sales tax, VAT, and GST across 50+ countries automatically. You tell Stripe what you're selling and where the customer is; it figures out the rate and adds it to the invoice. This alone saves you from integrating a separate tax engine like Avalara.
Revenue Recognition handles ASC 606 compliance — deferred revenue, recognition schedules, journal entries. If your finance team or auditors need proper revenue recognition, Stripe has it built in.
Stripe Radar is ML-powered fraud detection running on every transaction. Given the volume of payment data Stripe processes globally, the fraud models are better than anything you'd build or buy separately.
Global reach: 135+ currencies, 46+ countries, local payment methods (SEPA, iDEAL, Bancontact, and dozens more). If you sell internationally, this isn't optional.
The API and webhook architecture: Stripe fires webhook events for every state change — subscription created, invoice finalized, payment succeeded, payment failed, dispute opened. Your backend subscribes to these events and reacts. It's event-driven architecture done right, but it means your engineering team is writing and maintaining webhook handlers. A production-grade Stripe Billing integration typically handles 10-15 event types with idempotent processing, retry logic, and error handling.
Processing fees: 2.9% + $0.30 per card transaction (standard). Volume discounts available by negotiation. Billing Scale adds 0.5% on recurring charges. Stripe Tax adds 0.5% per transaction where tax is calculated. These stack — at a $100/month subscription with tax, you're looking at roughly $4.40 in total Stripe fees.
The integration question: Stripe + HubSpot together
Here's what most SaaS companies actually do: they use Stripe for billing and HubSpot as the CRM. Two systems, connected by an integration.
This is the right architecture for most teams. Stripe handles payment processing, subscription lifecycle, invoicing, and tax. HubSpot handles pipeline, customer relationships, and sales workflows. The integration syncs enough data between them that both teams — sales in HubSpot, finance in Stripe — have what they need.
The integration options, roughly ordered by complexity:
-
HubSpot's native Stripe data sync — free, limited. Syncs Stripe customers to HubSpot contacts. Doesn't sync subscription status, MRR, or failed payments.
-
Marketplace connectors ($50-200/month) — sync subscription status, MRR, and payment events to HubSpot contact properties. Good enough for most teams under 500 customers.
-
Custom webhook integration — your backend receives Stripe webhooks and pushes data to HubSpot via API. Full control over what syncs and how it maps. We wrote a complete walkthrough for building this in Python.
-
Reverse ETL / iPaaS tools — Census, Hightouch, or Zapier sitting between your data warehouse and HubSpot. More appropriate when you're syncing billing data alongside product usage, support tickets, and other sources.
The pain point with all of these: keeping two systems in agreement. A subscription upgrades in Stripe, the webhook fires, your sync updates HubSpot — but what if the webhook fails? What if the HubSpot API rate-limits you? What if the contact email in Stripe doesn't match the contact email in HubSpot? These are the 2 AM debugging sessions that generate the "Stripe says active, HubSpot says pending" tickets nobody enjoys investigating.
For a deeper look at how this plays out compared to Salesforce's Stripe integration, see our HubSpot vs Salesforce Stripe integration comparison.
Revenue reporting: where the data lives
This is the section that matters most to revenue operations teams, and it's where the HubSpot-vs-Stripe question gets genuinely painful.
If you use Commerce Hub: Revenue data lives in HubSpot. Deals, payments, and subscriptions are all CRM objects. Reporting is native — you can build HubSpot reports that show revenue by rep, by segment, by product line. The CRM is the source of truth for both pipeline and revenue. This is clean. It's also only accurate if all revenue flows through Commerce Hub, which breaks the moment someone creates a subscription directly in Stripe (through your website signup, through a custom checkout, through an API call).
If you use Stripe directly: Revenue data lives in Stripe. MRR, churn, expansion revenue, failed payment rates — Stripe Dashboard has all of it. But your CRM doesn't, unless you build the sync. Your sales team sees pipeline in HubSpot and has to tab-switch to Stripe to see what actually collected. Your RevOps lead is exporting CSVs from both systems and reconciling them in a spreadsheet every month.
If you use both: Revenue data lives in both systems, and they disagree. Not maliciously — they just model things differently. Stripe tracks subscriptions with precise billing cycles, prorated amounts, and usage charges. HubSpot tracks deals with close dates, deal amounts, and stages. A customer who signed a $24,000 annual contract (HubSpot deal amount) but pays $1,800/month with a 10% discount applied at checkout (Stripe subscription) creates a discrepancy that neither system flags on its own.
This is the actual RevOps problem. Not "which system processes payments" but "where do I go to understand my revenue, and can I trust what it says?"
Comparison table
| Dimension | HubSpot Commerce Hub | Stripe |
|---|---|---|
| Primary function | CRM-native payment collection | Developer-first payment infrastructure |
| Payment processing | Via Stripe Connect (under the hood) | Direct |
| Card processing fee | 2.9% + $0.30 | 2.9% + $0.30 (volume discounts available) |
| ACH fee | 0.8%, capped at $10 | 0.8%, capped at $5 |
| Subscription management fee | None | 0.5% on Billing Scale plan |
| Platform cost | HubSpot Starter+ ($20/mo per seat) | Free (pay per transaction) |
| Subscription billing | Basic (fixed recurring) | Full (metered, usage-based, tiered, hybrid) |
| Multi-currency | USD only | 135+ currencies |
| Geographic availability | US companies only | 46+ countries |
| Tax automation | None | Stripe Tax (50+ countries, +0.5%/txn) |
| Revenue recognition | None | Stripe Revenue Recognition (ASC 606) |
| Fraud detection | Via Stripe (inherited) | Stripe Radar (ML-powered) |
| Dunning / recovery | Basic retries | Smart Retries (Billing Scale), configurable schedules |
| CRM integration | Native (it is the CRM) | Requires integration (native sync, connector, or custom) |
| API / developer experience | Limited API, mostly no-code | Best-in-class API, full programmability |
| Webhook architecture | N/A (CRM events) | Event-driven, 15-20 event types for subscriptions |
| Setup complexity | Minutes (no-code) | Hours to weeks (engineering required) |
| Best for | Simple billing inside HubSpot | Any billing complexity beyond basic subscriptions |
Concrete recommendations
Use HubSpot Commerce Hub if all of these are true:
- You're a US-based company
- You sell 1-3 products at fixed monthly or annual prices
- Your team is non-technical and already uses HubSpot
- You don't sell internationally
- You don't need usage-based or metered billing
- You want to collect payments this afternoon, not next sprint
Use Stripe if any of these are true:
- You sell outside the US or in multiple currencies
- Your pricing model involves usage, metering, or per-seat dynamics
- You need automated tax compliance
- You want revenue recognition tooling
- Your engineering team wants to own the billing logic
- You're building a self-serve signup flow with Stripe Checkout or Elements
Use Stripe for billing + HubSpot as CRM (most SaaS companies):
- Keep Stripe as the billing system of record
- Sync subscription status, MRR, and payment events into HubSpot contact properties
- Use HubSpot for pipeline management, not payment collection
- Build reconciliation checks between the two systems — or use a tool like Fastero that monitors both and flags where they disagree
Start with Commerce Hub and migrate later if:
- You're pre-revenue and need to start collecting payments immediately
- Your billing model might get complex later but isn't complex yet
- You want to validate pricing before investing in Stripe integration
- Remember: Commerce Hub runs on Stripe under the hood, so your payment history is already in Stripe's system when you're ready to switch
The worst choice is the one that delays you. If Commerce Hub gets you to revenue today and you migrate to Stripe in six months, that's six months of revenue you wouldn't have had while your engineer was building Stripe webhook handlers. If Stripe gets you the billing model your pricing requires and you sync it to HubSpot later, that's fine too — the CRM integration can wait until your sales team is big enough to need it.
Pick the one that matches where you are today. Neither choice is permanent, and the migration path between them is shorter than most people think.
Try Fastero free — connect your CRM and billing data, get live revenue dashboards, and set up alerts that catch leaks before your next board meeting. No credit card required.
Last updated: July 2026.