Development

8 min read

After "Subscribe": Rethinking Subscription Commerce for the Full Lifecycle

Chris Kittrell

Written by Chris Kittrell

Published on Oct 06, 2026

subscriptions blog

Signing 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.

Why We Built It

As we designed subscription commerce for enterprise-scale businesses, a few principles kept surfacing:

  • Sign-ups & modifications deserve consistent logic. Customers add seats, upgrade or downgrade tiers, add add-ons, & cancel. Every one of those interactions deserves consistent & cohesive pricing, offer handling, & validation beyond the original purchase.
  • Recurring services rarely fulfill the same way. Activating a software license, provisioning a network service, & shipping a welcome kit are different processes, & a business selling on behalf of multiple providers may have dozens. The platform can't assume one fulfillment path.
  • Billing depends on a precise record of every charge. Whether invoices are produced by a long-established billing system of record or closer to the commerce platform, the subscription layer's job is to describe each charge accurately, including how charges changed over time.

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.

Who It's For

This pattern shows up anywhere a business sells recurring services that must be provisioned & billed on its own terms:

  • Telecommunications & ISPs selling their own plans alongside partner services
  • Subscription marketplaces selling recurring services on behalf of other providers
  • Utilities & energy providers bundling services & add-ons
  • Media & entertainment bundles spanning multiple content sources
  • B2B service contracts, where accounts add, change, & remove services over the life of a contract
  • Memberships that combine digital access with fulfilled goods or services

Subscription Modifications Run Through the Cart

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:

  • Customers only see actions they can actually take. Broadleaf evaluates which actions are available for each subscription based on its status & business rules, & records a reason when an action isn't available, so the UI can explain why.
  • Upgrades produce a valid cart from the start. When a customer upgrades, Broadleaf carries over their quantity, adjusts it to the new product's limits, & automatically adds any add-ons the new tier requires.
  • Bundles behave as one subscription. Multiple subscription products can be combined into a single bundle with one subscription & billing lifecycle.
  • Prepaid customers keep what they paid for. A mid-period downgrade or item removal on a prepaid subscription is scheduled as a delayed action & applied at the next billing period, instead of revoking access already paid for.
  • Cancellations follow policy, not guesswork. Cancellation policies, assigned to products or resolved via rules, declare whether cancellation is immediate or at renewal, whether remaining time is prorated, whether a grace period or fee applies, & whether the remainder of a contract term is charged.

Pricing & Offers Built for a Recurring Relationship

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:

  • What's due now. Including prorated amounts for the remainder of the current period, credits for prepaid time that's being replaced, & prior unbilled charges for postpaid access the customer has already used.
  • Estimated future payments. A projection of upcoming bills, including how discounts play out across future periods.
  • The typical recurring subtotal, before & after the change. A customer upgrading can see exactly how their regular bill is changing.
  • Discounts that will be lost. If a modification removes something that was qualifying for an offer, the customer sees that before they commit.

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:

  • Period-based discounts, like "50% off for the first 3 months."
  • First-time subscriber offers, limited based on a customer's active & former subscriptions.
  • Offers targeting specific flows: sign-up, edit, upgrade, or downgrade.
  • Free trials & discounts that survive modifications: if a customer upgrades two months into a six-month promotion, the remaining four months carry over.
  • Cross-subscription offers, like "Subscribe to A, get B free." If the customer later cancels A, the discount on B is removed automatically.
  • CSR-applied offers: customer service can add a discount to an existing subscription and choose whether it applies to the current period or starts at the next bill date.

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.

Workflow-Based Provisioning: One Storefront, Many Fulfillment Paths

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:

  • Subscriptions are locked while fulfillment is in progress. While a change is being provisioned, no other action can be taken against that subscription, so a customer can't submit a second change before the first one lands.
  • Changes are staged until fulfillment completes. Modifications are made in a sandbox copy of the subscription & only applied once the workflow finishes successfully. If it fails, nothing half-applied leaks into the live subscription.
  • Customer service can recover stuck fulfillments. If a partner's API is down or a step fails, CSRs can see exactly where the workflow stopped & repeat or skip steps to recover it, rather than escalating to engineering. This recovery tooling & the audit trail both run on Workflow Services & Audit Services, which are still in Beta.
  • Lifecycle transitions use the same machinery. Renewals at the end of a term, scheduled cancellations, scheduled price changes, & delayed prepaid actions all run through workflows too.

How It Fits With Billing

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.

Wrapping Up

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.

Related Resources