Development
8 min readSigning a customer up for a subscription is the easy part. Most commerce platforms can put a recurring price on a product & charge a card on a schedule.
The hard part is everything that comes after. An ISP customer adds a streaming add-on halfway through the month. A B2B account adds twenty seats to one service & drops another entirely. A member downgrades their plan three days before renewal, then asks customer service why their bill looks different. Each change has a price, may be affected by a promotion, must be provisioned by whoever delivers the service, & has to show up correctly on the customer's next bill.
In Broadleaf 2.3, we introduced Subscription Operation & Billing services built for that part of the lifecycle: subscription modifications, subscription pricing & offers, & workflow-based provisioning. Both ship as part of Broadleaf's extended commercial license tier, beyond the base platform.
As we designed subscription commerce for enterprise-scale businesses, a few principles kept surfacing:
When subscription management lives in a separate system from the one that handled the original sale, modifications tend to be priced & validated by different logic than sign-ups. Keeping those two sets of rules in step becomes an ongoing effort, & any drift shows up in front of the customer.
This pattern shows up anywhere a business sells recurring services that must be provisioned & billed on its own terms:
The most important design decision we made was this: every change to a subscription is handled via a cart.
When a customer edits, upgrades, downgrades, or cancels a subscription, Broadleaf generates a cart pre-populated with the subscription's current items. The customer makes the change on the same product pages & checks out the same way they signed up, & any charge due now is collected in that checkout like any other purchase.
The cart is the mechanism; centralization is the benefit. Sign-ups & modifications share one implementation of catalog rules, pricing, offers, validation, & checkout processing, so there's no second set of rules to keep in step.
Beyond the cart itself, a few behaviors keep modifications on track:
A one-time purchase has one price. A subscription has a price now, a price next month, & a price for a "typical" month, & those can all be different. Modifications make this even more nuanced.
For every subscription cart, whether it's a sign-up or a modification, Broadleaf describes:
Consider a $39/month subscription with a $10 discount on the first period. If it's prepaid, the customer pays $29 today & sees future payments of $39. If it's postpaid, they pay $0 today & see a first bill of $29 at the end of the period, then $39 thereafter. Same product, same offer, clearly described either way.
The offer engine was enhanced with subscriptions in mind as well:
Pricing can change after the sale, too: CSRs can push price changes to existing subscriptions, scoped to specific customer segments & applied from the next bill date. Every subscription change is recorded in Broadleaf's audit service.
Something has to activate the license, provision the account, notify a partner, or ship the kit, & that differs from product to product.
Each subscription product declares its fulfillment type. An order is split into fulfillments by type, & each is routed to a workflow specific to both the fulfillment type and the action being taken. Signing up for a software license is processed by one workflow, while upgrading a connectivity plan uses another, & cancelling either subscription starts yet another. Each workflow combines framework-provided steps (updating the subscription, recording the billing impact, recording fulfillment completion) with your own steps, such as calling a partner's provisioning API.
This is what makes selling many kinds of services, or selling on behalf of many providers, manageable from a single storefront. A few features make it especially robust:
Billing setups differ. Some run a long-established system of record they aren't replacing; others want invoicing closer to the commerce platform. Either way, Broadleaf is designed to know what the customer should be charged in a given timeframe & why.
Every sign-up, modification, renewal, & price change produces BillingEvents describing the charges for a defined period of time. BillingEvents are never edited in place. When a subscription changes mid-period, corrections are made by generating new, offsetting BillingEvents rather than altering history, so you have a complete, auditable record of how a charge changed over time.
Because every BillingEvent covers a defined span of time, the charges can be applied to whatever invoice windows your billing process uses, including those of an existing billing system of record.
Subscription commerce gets hard in the space between sign-ups: the upgrades, the cancellations, the services that each fulfill differently, & the bill that has to reflect all of it. Broadleaf 2.3's Subscription Operation & Billing services are built for that space.
If recurring services are part of your roadmap, talk to an expert about what this means for your subscription program, or explore the subscription ecosystem in the developer docs.