Selling subscriptions, not just publishing a page
A storefront that takes an order and emails it to somebody is not selling subscriptions. The hard part is everything after checkout: creating the account, activating the service, starting the billing cycle, storing a payment method and charging it again next month.
OpenBRM deploys with an integrated open source subscription ecommerce component that sits on top of the billing engine, so the order a customer places is the order that bills them. There is no export, no nightly synchronisation, and no second product catalogue to maintain.
What happens at checkout
- The customer account is created in the billing system
- The subscription is activated, firing any provisioning hooks you have configured
- The billing cycle starts on the customer's own date
- The payment method is stored against the account for recurring collection
- Confirmation notifications go out from the same templates as your invoices
Subscription ecommerce with one catalogue and one price
Products, bundles and prices shown in the storefront come from the billing system's catalogue. Change a price or launch a promotion in the bundle manager and the storefront reflects it, because there is only one source of truth. This removes the most common ecommerce billing failure: the site advertising one price while the invoice shows another. It also keeps subscription ecommerce open source from storefront to invoice.
A self-service billing portal after the sale
The same component is a customer portal that gives existing customers a place to view invoices, make payments, change plan and update payment details — which reduces the support load that otherwise scales linearly with your subscriber count.
Payment methods and gateways
The storefront takes payments through the same payment plug-ins the billing system uses, so the card captured at checkout is the card charged on the next billing run. Supported gateways include Authorize.Net, PayPal, FirstData and Chase Paymentech. Each processor is configured as a plug-in and can be tested with test settings before you go live. Other supported gateways, such as DIBS and PayWay, are set up the same way.
Selling packages and promotions online
Because the catalogue is shared, anything built in the bundle manager can be sold online as soon as it is ready: an introductory free period, a setup fee, or several products sold as one item. Customers see the price the invoice will actually charge. Prices, packages and promotions are managed once, in OpenBRM, and the storefront shows what is there, so there is no second catalogue to update before a campaign goes live.
After the first order
Renewals, plan changes and failed payments are handled by the billing system, not by the shop. If a recurring payment fails, the collections steps you have configured take over, with retries and reminder emails, and the customer can update their payment details in the portal. That keeps the storefront simple: it sells, and the billing system handles everything that follows. A plan change made in the portal follows the same rules as one made by your staff: proration on the next billing run and a provisioning hook that tells your platform about the change.
Product bundling ·Payment processor setup · Open source BSS · Oracle BRM alternative