DAF Trucks sells subscriptions to connected-fleet features — enable a service on one truck, or on an entire fleet, and get billed correctly for it. GrandVision sells recurring plans for glasses and lenses across 7,200+ stores in 40 countries. We built both, and neither runs its billing inside a commerce platform: both run on Zuora with a commerce and self-service layer in front. Meanwhile, a coffee brand selling a bag every four weeks genuinely doesn’t need any of that machinery.
The difference between those situations is the actual decision, and it’s routinely obscured by the fact that everyone involved says the same word: subscriptions.
One word, two problems
Recurring fulfilment is a commerce problem: the same cart, executed on a schedule. Ship coffee every four weeks, charge the stored payment method, allow skip and pause. The unit of work is an order.
Recurring monetization is a finance problem: a contract that changes over time. Mid-cycle upgrades that must be prorated, usage-based charges, consolidated invoices across a fleet, payment retries and dunning, taxation per billing period, revenue recognition rules your auditors will actually read. The unit of work is a subscription state machine, and orders are merely one of its outputs.
Platforms are honest about this split; buyers often aren’t. Most “we need subscriptions” projects that go wrong picked tooling for one problem while quietly having the other.
What commercetools covers natively
commercetools added Recurring Orders for exactly the first problem: a recurrence policy on a cart, and the platform generates a normal order each cycle. The strength of that model is the word normal — every generated order flows through the same pricing, promotions, inventory, and integrations as a one-off order. One catalog, one discount engine, no second system to reconcile, payment handled by tokens stored with your PSP.
One naming trap to avoid when you read the docs: the commercetools feature historically called Subscriptions has nothing to do with any of this — it’s the eventing mechanism that delivers platform messages to your queues. The customer-facing capability is Recurring Orders. More than one project has scoped itself around the wrong noun.
If your model is replenishment — fixed cadence, physical goods, price changes are just price changes, cancellation means “stop shipping” — this native route plus your PSP’s stored credentials is the whole architecture. Adding a billing engine to a subscribe-and-save box would be pure overhead.
Where the native model runs out
Walk through what DAF’s business actually requires and the boundary becomes concrete:
- A fleet manager enables a feature on 40 trucks on the 17th of the month — the charge must prorate.
- Features are added and removed continuously; finance needs one consolidated invoice per customer entity, not 40 order confirmations.
- Failed payments enter a retry-and-dunning sequence with defined escalation, not a cancelled order.
- Contracts span years and amendments; revenue has to be recognized against delivery, and reported that way.
- Pricing includes commitments and usage components, not a flat cycle price.
None of that is order generation. It’s contract lifecycle accounting, and rebuilding it on top of carts means reimplementing a billing engine one edge case at a time — proration math, calendar oddities, partial credits, tax across periods. That category of rebuild is exactly what dedicated platforms exist to prevent.
The split architecture: commerce in front, billing behind
What we run in production for both DAF Trucks and GrandVision (built together with Subscription Factory, the Zuora specialist in our group’s partner network) is a clean division of labor:
- Catalog and acquisition up front. The storefront or portal presents plans; commercetools or a custom layer owns the browse-and-buy experience. Product-to-rate-plan mapping is maintained deliberately, in one direction — the commerce catalog references billing’s rate plans, never the reverse.
- Zuora owns the contract. Checkout creates the subscription; from then on amendments, proration, invoicing, payment retries, and revenue recognition live in the billing engine.
- Self-service is its own surface. The differentiating build in both projects was the portal: DAF’s lets fleet managers switch features per truck or per fleet and cut subscription-management effort by up to 50%; GrandVision’s lets customers view invoices, pay, and change plans, and lets 40 countries’ worth of care staff do the same without engineering tickets.
- Events keep the edges honest. Billing state flows back out through events — entitlements switch off when dunning exhausts, accounting systems and audit trails stay synchronized through the integration layer rather than point-to-point calls.
The pattern generalizes beyond Zuora — the point is the seam, not the vendor: commerce owns what you sell and how it’s bought; billing owns what the customer owes and why.
How to decide
Stay native (Recurring Orders + PSP) when all of these hold:
- Fixed-cadence replenishment of physical goods
- Charge equals the order total; no proration, usage, or commitments
- Cancellation and skip are the only lifecycle events that matter
- Finance is content with order-level records
Bring in a billing engine when any of these hold:
- Mid-cycle changes must prorate, or pricing has usage/commitment components
- Customers need consolidated or entity-level invoicing
- Dunning, retry logic, and involuntary-churn recovery materially affect revenue
- Revenue recognition or audit requirements exceed order history
- Subscriptions gate entitlements (features, access, service levels) rather than shipments
A useful smell test: write down the three hardest support tickets your subscription business will generate. If they’re about parcels, stay in commerce. If they’re about invoices, you’re building on the wrong side of the seam.
Two mistakes we keep seeing
Double-mastering the catalog. The product exists in commerce and as a rate plan in billing, and each team edits its own copy until prices disagree in production. Decide which system masters commercial terms, generate the other side from it, and alarm on drift.
Treating billing edge cases as post-launch polish. A payment that fails during a mid-cycle upgrade, a plan change on the 31st, a partial refund against a consolidated invoice — these aren’t rare, they’re Tuesday. They belong in the test plan before go-live, because retrofitting correctness into money flows is the most expensive kind of rework there is.
This seam — commerce in front, billing behind, events between — is the core of our subscription economy practice. If you’re weighing recurring orders against a billing engine for a concrete product, bring the product; the answer usually falls out of one whiteboard session with your catalog and your finance requirements on the same board.
