Recurring Revenue from Connected Hardware
Hardware is a one-time sale. The maintenance contract, the premium analytics dashboard, the predictive maintenance alert service, the tiered feature access are recurring. Manufacturers who have made the shift report that, over time, software services contribute more to operating margin than the hardware itself.
The obstacle is infrastructure: subscription billing, plan management, feature gating and payment processing are fintech problems. Integrating them into an IoT solution that wasn't designed for them takes lots of time and produces fragile integrations.
Recurring revenue models
The three models device manufacturers most commonly launch are:
- Premium remote monitoring: a subscription tier that unlocks historical data, dashboards, or real-time alerts.
- Proactive maintenance contracts: a service tier that charges for predictive alerts and scheduled interventions.
- Feature unlocks: post-purchase activation of capabilities already present in the firmware.
Each has a different billing shape, but all require the same underlying infrastructure.
The challenge with recurring revenue for connected products
When a manufacturer decides to offer connected services as subscriptions, they face a stack of infrastructure problems that have nothing to do with devices:
- Subscription lifecycle management: trials, activations, renewals, cancellations, failed payments, and upgrades all require event-driven logic that must be reliable and auditable.
- Feature gating by plan: a device or application must behave differently depending on the user's current subscription tier, premium features hidden or unlocked based on what the customer pays for.
- Multi-tenant billing: a manufacturer sells to other businesses (installers, building managers, fleet operators), each of whom may have many end users. Billing must work at both levels.
- Payment processing: integrating Stripe or any other payment providers requires a strategy to synchronize your app state with payment statuses.
- Revenue visibility: understanding monthly recurring revenue, churn, and plan conversion requires data that is spread across billing, IoT, and CRM systems.
- Compliance: VAT handling, invoicing, and data residency requirements add complexity for European manufacturers.
The risk of building all of this from scratch is to create a system that is immediately a maintenance burden.
What it takes to get it right
A recurring revenue model for connected hardware requires three layers working together:
-
Subscription management, a system that tracks which users or organizations are on which plan, handles the lifecycle events (trial start, payment success, cancellation), and exposes the current plan state to the application layer.
-
Feature authorization, the application checks the current plan before rendering UI or responding to API calls. This must be fast (cached), consistent across platforms (mobile, web, back-office), and easy to update when pricing changes.
-
Payment processing, a reliable integration with a payment provider, handling card authorization, recurring charges, failed payment retries, and webhook events.
The critical design challenge is the entitlement chain: payment state must propagate to plan state, which must propagate to IAM permissions, which must propagate to what the apps render and what the API allows.
That chain must also stay consistent when a user upgrades, downgrades, or fails to renew: this is typically where bugs, billing disputes and feature access incidents occur.
How Connhex solves it
Connhex Pay is the subscription and billing layer built into the Connhex suite. It handles:
- Subscription plans: define tiers (e.g. free, standard, premium), set pricing, configure trial periods and grace periods.
- Payment processing: Connhex is the IoT platform integrated with Stripe, handling the payment flow, webhook events and failure recovery.
- Automated renewals and notifications: upcoming renewals, failed payment alerts, and cancellation flows are managed automatically.
- Usage-based billing: charge based on the number of devices, data volume, or API calls, not just flat subscriptions.
Connhex Auth and the IAM system handle feature gating. Subscription state flows directly into the permission model: when a payment succeeds or a plan changes, the IAM policies update automatically. Every subsequent API call from the user's app is evaluated against the current plan state: premium features are enabled or rejected at the API level, not just hidden in the UI.
The result is an architecture where adding a new subscription tier or changing which features are gated requires configuration, not a new deployment. Your team can iterate on pricing and packaging without engineering work.
In practice, this means a thermostat manufacturer can launch a "Premium" tier unlocking remote scheduling and predictive maintenance alerts, a vending operator can offer a per-machine monitoring subscription to their retail customers, and a pump manufacturer can sell annual service contracts with automated anomaly notifications. All on the same Connhex infrastructure, without building a separate billing system for each model.
See how this works in practice for specific verticals: Connhex for HVAC (from hardware to subscription services) · Connhex for Vending Machines · Connhex for the Smart Home
See it in practice
I discovered Connhex after an in-depth technological scouting phase. It has proven to be by far the best solution for our needs: nothing even comes close.
CTO - Astrel Group
Astrel Group runs four distinct business units (Energy, Home, Wellness, Fire) on a shared Connhex infrastructure, each with its own branded application and subscription model. Operating four separate subscription models without four separate billing stacks was only possible because Connhex handles the plan management and IAM integration centrally.