Modernizing billing and payments for 60,000 merchants

What happens when thousands of merchants rely on one broken billing flow across all billing tools?

HubSpot Commerce lets businesses accept payments directly in their CRM. When I joined, the billing summary, the part of every quote and invoice that shows what a buyer owes, had been built and maintained by three different teams. Changes were slow, patterns didn’t match, and the design was built for one-time payments, leaving subscription businesses underserved. Reps used it every day and found it confusing and error-prone.

Three teams, three versions

I studied how reps used these tools to build quotes and talk with buyers. The backend could handle complex billing, but the interface couldn’t show it clearly. Adding a subscription meant doing mental math, key details like future payments were hidden, and inconsistent patterns made a simple quote feel complicated.

Agreeing on words before pixels

Before designing anything, I brought all five teams together to agree on what the summary should show and what to call it. We defined shared terms like Due now, Future payments, and Total contract value, so every tool described a buyer’s bill the same way. That shared language unblocked the design work and kept teams from building their own versions again.

Aligning on terminology and billing needs shaped my early design explorations, focusing on progressive disclosures and price adjustments that gave reps confidence that the math was always right.

One summary that adapts to any billing model

After conducting research, we launched one billing summary to 60,000 merchants, now shared by five product teams. Adoption grew fastest in Invoices and Subscriptions.

• 20% more future-dated subscriptions

• $75K in new monthly transaction revenue

• One shared billing component across five teams, replacing three separate versions

  
  

Designing for scale is never finished

Working on this new summary taught me to focus on what matters most to the people using it. Reps spend most of their day selling, not reading bills, so the summary needed a clear mental model they could trust at a glance. The less time they spend checking the math, the more time they spend closing deals.

It also taught me how hard designing for scale really is. Even with one shared summary in place, newer tools like Contracts and CPQ started building their own totals, drifting from the platform version. No design fully future-proofs a platform. What helps is shared definitions and a component that’s easier to adopt than to rebuild, and that’s what I’d push for even earlier next time.