When a merchant on your platform starts selling subscriptions, the first payment runs through you. The second one usually does not. The merchant signs up with a billing engine, and from that day on, that engine decides when the renewal is charged, how many times it is retried, and what the customer sees when it fails.
The reason is historical. Billing engines were built for merchants, and they sit on top of a payment provider. They keep the plan and the customer, run the schedule and hand each charge down to whichever PSP the merchant connected. They have no notion of a PayFac, a program manager or a portfolio. NORBr's Subscriptions module runs the recurring lifecycle inside the operator's own platform instead. Offers, rebills, retries, pauses and cancellations are switched on merchant account by merchant account, under the operator's brand, on the acquiring connections already in place.
What follows is what subscription merchants actually need from a billing layer, how that layer is delivered today, where it breaks for an operator, and what changes when it lives inside the payment platform.
Why the second charge is the one that leaves your platform
The platforms that win in payments are the ones that keep their merchants' recurring volume. In the quarter ended June 2026, Shopify Payments carried 68% of Shopify's gross merchandise volume, and Merchant Solutions revenue, which is mostly payments, reached $2.8 billion against $802 million of software subscriptions. At Lightspeed, transaction-based revenue came to $815 million in fiscal 2026, more than twice its subscription revenue. Payments is where a software platform earns, and recurring payments are the part of it that renews on its own.
Subscription merchants are also a different kind of customer. According to Antenna's 2025 year in review, the weighted average monthly churn of premium US streaming services was 4.6% in 2025, and 42% of the people who canceled in 2024 came back within twelve months. A subscriber is not lost when a charge fails or a plan is canceled; the stored credential, the offer history and the customer record are what make the return possible. Whoever holds them holds the relationship.
The volume at stake is not marginal. The UK government counts about 155 million active consumer subscriptions in the UK alone, worth around £26 billion a year. Every one of those renewals is a payment that either stays on the operator's platform or leaves with the billing tool.
Why 2026 subscription rules turn billing into a platform feature
Subscription merchants now carry obligations that live in the billing layer, and regulators have started pricing them. On September 25, 2025, Amazon agreed to a $2.5 billion settlement with the US Federal Trade Commission over Prime enrollment and cancellation, including an obligation to let customers cancel "using the same method that consumers used to sign up". In March 2026, Adobe settled a federal case over early termination fees and trial conversions for $150 million, with new duties to disclose fees before enrollment and remind customers before a trial converts.
The rules are spreading. Since June 19, 2026, under Directive (EU) 2023/2673, B2C contracts concluded online in the EU must offer a withdrawal function no harder to use than the sign-up. The European Commission's own fitness check found that 69% of consumers had run into technical difficulty cancelling an online contract and 62% had seen an inactive subscription renew without a reminder. In the UK, the subscription regime of the Digital Markets, Competition and Consumers Act, scheduled for spring 2027 in the government's April 2026 response, will require reminders at least every six months, a second cooling-off period at renewal and cancellation through the sign-up channel; the same document estimates 9.7 million unwanted subscriptions costing UK consumers £1.6 billion a year.
Reminders, same-channel cancellation, trial notices and pauses are billing events, and merchants will expect their payment platform to run them.
How recurring billing reaches merchants today
Three models cover almost every case. In the first, the merchant integrates a standalone billing engine. The engine stores the plan and the customer, calls the payment provider for each charge with the saved credential, and runs its own retry schedule and reminder emails. The payment provider sees each rebill as a merchant-initiated transaction on a stored credential. It has no view of the plan behind it, the retry sequence it belongs to, or what the customer was told.
In the second, the payment provider exposes a recurring API. The merchant saves the payment method, keeps a reference to the stored credential and schedules the charges itself, typically with a job that sends the amount on each billing date. The provider may offer stored-credential handling and smart retries, but the plan, the end rules and the customer communication stay in the merchant's code.
In the third, the platform builds its own subscription layer. The largest subscription businesses do exactly this, and their help pages show what the layer has to do. Netflix states that it "will automatically retry failed payments periodically during the course of your billing cycle" and puts the account on hold in the meantime; Spotify says a failed monthly payment does not end Premium at once and that it "will try to take the payment again over the next few days". Netflix also documents its billing anchor: a subscription signed up on the 31st is billed on the last day of shorter months. Building those behaviors takes a team and a year, then a rebuild for every acquirer the platform adds.
Where these models break for a PSP, PayFac or ISV
None of the three was designed for an intermediary. A standalone billing engine knows one merchant and one payment provider. It has no concept of the program manager above the merchant, of the rights each level should hold, or of the routing rules the operator applies across its acquirers. Retries are decided by the engine's model, outside the operator's view, and the operator cannot explain to its merchant why a renewal was attempted four times or never.
Connected-account billing models from mainstream providers document their own limits. Only sub-accounts with full dashboard access can manage their customers' subscriptions, a subscription created on one side cannot be updated from the other, and subscriptions are not canceled when an account disconnects from the platform. Each of those limits is a situation an operator will have to handle by hand, and in the meantime recurring revenue sits in the billing tool while one-off payments sit in the payment platform, with the merchant reconciling the two.
What changes when the module runs inside your platform
NORBr's Subscriptions module keeps the four objects a subscription needs, offers, retry policies, subscriptions and subscribers, inside the same platform that processes the payments. The merchant sends the customer to checkout with an offer ID. The first payment runs, and the schedule writes itself from the offer: amount, currency, rhythm, first-payment rule and end rule live in the offer, not in the merchant's code. Each rebill is charged on its date, on the payment method saved at checkout, through the connections the merchant already uses, and shows up next to every other payment at every level of the hierarchy.
The module is switched on per merchant account. An operator offers it to the merchants who bill on a recurring basis and keeps it off for the others, and decides what its own team, its program managers and its merchants can each configure, from offers to retry policies. Program managers can publish retry policies as templates that merchants duplicate and adapt. A retry policy sets how many attempts follow a failed rebill and how far apart they fall, and what happens after the last one: the subscription is left past due with the missed occurrence dropped, paused for a set number of cycles, or canceled with payment failure as the reason. There is no separate billing provider to integrate and no new acquiring contract. The module can run on its own, and when it runs with the rest of the platform, rebills follow the operator's routing rules.
Some choices are deliberate limits. Payment methods are saved through the hosted payment page only. A subscription's amount cannot be edited by hand; it comes from the offer, and a change creates a new offer version that every subscription follows from its next charge. Pauses are counted in billing cycles, not dates, so the paid period and the service period never drift apart. Moving a subscription to another offer applies at the next billing date, with no proration. These constraints are what keep a whole portfolio's subscriptions legible from the top of the hierarchy.
What merchants see in a white-label subscription console
Your merchants see offers, subscriptions and subscribers in their console, under your brand, with your menu names and your fields. They see each subscription's status, its next charge date, its order history with the offer version each order was billed under, and the payment method it is bound to, with its expiry date. They pause, migrate, cancel or add a one-off charge from the same screen.
They never see NORBr. The hierarchy, the rights, the routing and the retry logic are yours to configure and yours to explain. When a merchant asks why a renewal failed and what was attempted, the answer is in your platform, in a decision tree your team can read: the Retry matrix.
What else do operators ask about white-label subscription billing?
Does a merchant need a separate billing provider to sell subscriptions on NORBr?
No. The Subscriptions module runs inside the operator's platform and is switched on per merchant account. Offers, rebills, retries, pauses and cancellations run on the acquiring connections already in place, so the merchant integrates no standalone billing engine and signs no new acquiring contract.
Who decides which merchants can use subscriptions?
The operator. It activates the module merchant account by merchant account and sets what its own team, its program managers and its merchants can each configure, from offers to retry policies. Merchants who do not bill on a recurring basis simply keep the module switched off.
How is the amount of a subscription set?
By the offer. The merchant sends the customer to checkout with an offer ID, and the amount, currency, rhythm, first payment and end rule are read from that offer. The amount cannot be edited by hand; changing it creates a new offer version that applies from the next charge.
Can retry policies differ from one merchant to another?
Yes. Program managers can publish retry policies as templates that merchants duplicate and adapt within the rights the operator grants. Each policy sets the number of attempts, the delay between them and what happens after the last one: past due, a pause for a set number of cycles, or cancellation.
A subscription your merchant sells under your brand should not have its second charge decided by someone else's software.
Subscriptions is a module of NORBr's white-label payment infrastructure, activated per merchant account by the PSPs, PayFacs, ISOs and ISVs that run their payment platform on NORBr.
_%252520a%252520game%252520changer%252520for%252520digital%252520transactions_-Cover.webp)
