Subscriptions you actually own

The subscription you own, and the one you only rent

There are two ways to run recurring billing, and from the customer's seat they look identical. A card is charged every month, an email arrives, the product ships. Underneath, one of those two shops owns its subscriptions and the other only rents them, and the difference is invisible right up until the day the shop wants to change something. Then it decides everything.

I build custom shops on Solidus, the open source Rails commerce framework, and I wire each one to a payment processor the client owns outright. That one decision, taken before a line of checkout code is written, is what makes a subscriber base portable. When the recurring billing runs inside your own processor account, you can change your storefront, your framework, even your whole technology stack, and the subscriptions keep charging through the switch without a single customer being asked to do anything. When it runs inside a platform's subscription app instead, leaving the platform can break the billing, and the only way out is to ask every subscriber to sign up again.

This article is the positive mirror of one I have already written about the pain: migrating subscriptions and recurring payments, which is the story of a shop trying to rescue a subscriber base from a platform that owned it. Here I want to show the other path, the one where that rescue is never needed, because the subscriptions were built to be yours from the start. It sits under the broader case I make in owning your payment stack. Every fact about how the mechanics work carries a footnote to a primary source. The businesses are invented so I can show the whole decision in numbers.

Where a subscription actually lives

When someone says "move the subscriptions", they usually picture a table of rows. In practice a single live subscription is four things that have to stay in step, and where those four things live is the whole question.

The first is the plan and price: what the customer pays, for what, and how often. The second is the schedule: when the next charge runs and the cadence after that. The third is the mandate: the customer's standing agreement that you may charge them when they are not sitting at the checkout. The fourth is the token: the usable reference to the card or the bank account, which stands in for details your shop never holds itself.

With processor native billing, all four sit in your processor account. On Stripe, for example, a subscription is an object that contains the subscribed customer, the product and the price, and Stripe itself generates the invoices, attempts collection and manages the subscription through its lifecycle, handling the retry logic and the dunning along the way.¹ Your shop does not own the clock. Your processor account does. The storefront is just the thing that created the subscription and that reads its status back.

That is why a native, owned subscription survives a change of shop. Point a new storefront at the same processor account, give it the same API credentials, and the schedules that were already running keep running, because they never lived in the old storefront in the first place. Nothing is migrated, because nothing has to move. The subscriptions were never in the box you are replacing.

Contrast the rented version. A platform subscription app, or a platform that runs recurring billing only through its own bundled payments product, keeps the schedule, and sometimes the vaulted tokens too, inside the platform. While everything stays put this is invisible. The day you try to leave is the day you discover the schedules were the platform's, not yours, and that is exactly the guillotine I describe in the migration subscriptions spoke. Owning the account is how you never meet it.

The mandate and the token are two different things

This is the distinction most people miss, and it is the one that decides whether anything is portable at all. A recurring charge needs two separate things to be valid, and they travel on different roads.

The mandate is the customer's agreement to be charged on a schedule. The token is the usable reference to the actual card or bank account. You can have one without the other, and then nothing works: a token with no valid agreement behind it is an unauthorised charge waiting to happen, and a perfect agreement with no usable token has nothing to charge against. I take the token half apart in full in how card tokenisation works, and the portability of the whole bundle in payments that move with you. Here the point is narrower: owning the processor account is what keeps both the mandate and the token usable through any change of storefront, because both live in the account, not in the shop.

One thing never moves and never should: the card security code. PCI DSS prohibits anyone storing it once the first payment has been authorised, even for card on file and recurring use, even with the customer's consent.² You do not need it to charge a saved card, so this costs you nothing, but it is a useful reminder that "just keep everything" is never literally true. I set out what the standard asks of a shop, and how a tokenised checkout keeps that ask small, in PCI DSS explained.

Cards: the stored credential and the agreement behind it

For a card subscription, the agreement is not a loose promise. The card schemes have a formal frame for it, and owning your account is what keeps you inside that frame.

Under the stored credential rules, the very first payment in a series is treated as initiated by the cardholder, and the merchant must keep the transaction identifier the scheme returns from that first payment and send it with every later charge in the series.³ Mastercard runs the same model: a merchant initiated transaction is a follow on to an initial cardholder action, and it has to reference the original stored credential.⁴ That chain of identifiers is the proof that the customer agreed. When billing lives in your own processor account, the chain stays intact across a storefront change, because the account that holds the original identifier is the account still doing the charging. When billing lives in a platform's app and you leave, the chain can snap, and a snapped chain means the customer's bank may treat the next renewal as brand new.

That matters because of Strong Customer Authentication. Under PSD2, the European Banking Authority confirmed that payments initiated by the payee alone, without the payer doing anything to trigger them, are not subject to SCA, and merchant initiated subscription charges fall into that category.⁵ So a renewal on a properly held agreement normally runs quietly in the background. Two parts still need authentication, and it is honest to say so: setting up the mandate through a remote channel is subject to SCA, and a card on file payment that the customer themselves triggers stays in scope.⁵ Stripe's own guidance matches this. It marks subsequent off session charges on a saved card as merchant initiated transactions, which require an agreement, also called a mandate, between you and the customer, covering their permission, the expected frequency and how the amount is set.⁶ And it is blunt about the limit: exemptions are not guaranteed, and an off session payment can still be sent for authentication by the bank.⁶ Owning the account does not exempt you from the rules. It keeps you on the right side of them without re papering every customer when you change shop.

A direct debit mandate that travels with you

Cards are only half the story for a recurring business, and in the DACH region they are often the smaller half. The other path is the SEPA direct debit, and it is where the rules are kindest, if you follow them. I cover the regional payment mix in full in DACH payments in Solidus.

A SEPA mandate is not tied to a single payment processor the way a card token is. It is an agreement between the creditor and the debtor, carried by two mandatory elements: a Unique Mandate Reference and a Creditor Identifier.⁷ Both belong to you, the creditor, not to whichever processor happens to submit the collection.

The European Payments Council has been explicit that a change on the creditor's side does not automatically destroy the mandate. A change of the party referenced by the creditor does not affect the validity of the mandate and needs no new mandate, and a change of the creditor itself is handled through an amendment that carries the original reference alongside the new one, rather than by asking every customer to sign again.⁸ In plain terms: as long as you keep collecting under your own Creditor Identifier, your direct debits can continue through a change of storefront or even a change of processor without re papering a single payer. The debtor still has to be given notice, and the scheme's notification rules apply, but the agreement itself survives. That is a genuine advantage of direct debit over cards for a recurring business, and a reason I lean on it where it fits.

Dunning and retries you own, not rent

A subscription business does not live or die on the happy path. It lives or dies on the failures: the expired card, the bank that declines a renewal, the account that is short on the first of the month. Owning your processor account means owning the machinery that handles all of that, rather than renting it from an app that can change its behaviour, or its price, under you.

On a processor you control, the recovery tooling is yours to configure. Stripe's Smart Retries, for instance, uses a model to choose when to reattempt a failed charge, retrying according to a schedule you set in your own dashboard, up to a limit you choose, and it is enabled by default for new accounts at up to eight retries over two weeks.⁹ Direct debit retries follow the payment method's own rules rather than the card schedule, which you also set in your account.⁹ None of that logic lives in your storefront, so none of it breaks when the storefront changes.

Two quieter features do most of the work of keeping a subscriber base alive, and both sit at the processor, not the shop. A card account updater retrieves and updates saved card details automatically, because, as Stripe puts it, card numbers and expiration dates regularly change and outdated card information is a common source of declines.¹⁰ Network tokens are payment credentials that stand in for the card number and can keep processing with the most up to date credentials even when the underlying card data has changed, which lifts the success rate on exactly the renewals that would otherwise fail silently.¹⁰ Because these ride on the token layer in your account, a customer who was issued a new card in the post never even notices, and you never had to email them. Rent your billing from a platform app and these are switches someone else owns. Own the account and they are yours.

The honest tradeoffs

This is an architectural argument, not a sales pitch, so here is the other side of it plainly. I take no processor kickback and I am not claiming one processor is simply best. What I am claiming is that owning the account is worth its costs, and the costs are real.

Native billing is build work, not a one click install. A platform subscription app is a few minutes to switch on. Wiring a custom shop to your processor's billing, with the webhooks, the dunning rules, the mandate text and the reconciliation all done properly, is engineering, and I charge for it. The trade is that you buy an asset you keep rather than a dependency you pay forever.

You also own the strategy and the compliance. The dunning schedule, the retry limits, the way an expiring card is handled, the wording of the mandate: these become your decisions, where a platform made them for you. Processor fees are a genuine cost of taking money, and they do not vanish because you own the account. Strong Customer Authentication applies to your European cards whatever you build on. And a single processor is a single point you have to plan around: if you want a fallback, that is more work again. I would rather name all of this than pretend owning your stack is free. It is not free. It is just yours, and the portability is what you are buying.

One sharp point is worth making, because it is true and verifiable. Some platform payment products are the very same processor underneath, only locked. A merchant on such a product gets the processor's engine without owning the account it runs in, so they carry the processor's fees and rules but keep none of the portability. The engine is not the asset. The account is.

Doing it on Solidus, owned

Here is how the owned version actually fits together, and why the build is worth it. Solidus talks to a payment method, which is a helper class wrapping one processor's API, and a refund is always processed back through the original payment's own method, so an old and a new processor can sit side by side during any transition.¹¹ Recurring orders themselves are handled by the solidus_subscriptions extension, which creates a subscription for each group of subscribable items in an order and processes the due installments on a schedule, retrying failed installments on later runs.¹²

The important part is where the authority lives. In the owned design, Solidus holds the subscription's shape, the plan, the cadence, the customer link, while the actual charging, the vaulted token, the mandate and the retry machinery sit in your processor account. So the storefront is replaceable and the billing is not disturbed by replacing it. You can rebuild the shop, go headless for a mobile app as I describe in headless and API first Solidus, or change framework entirely, and point the new front end at the same processor account. The schedules never paused. That is ownership expressed as architecture, and it is the opposite of the lock in I warn about in the hidden dangers of switching payment gateways.

A worked example: a Brighton box that changes its shop and charges no one twice

Let me put real shape on it. Kelpwell is an invented wellness subscription in Brighton, trading at kelpwell.example, run by Mara. It ships a monthly box of seaweed based supplements. It has 3,400 UK subscribers paying £24 a month by saved card, and another 600 customers across the euro area paying by SEPA direct debit. From the first day, I built it on Solidus wired to Mara's own Stripe account. The subscriptions, the saved card tokens, the SEPA mandates under Kelpwell's own Creditor Identifier, the retry rules: all of it lives in the account Mara owns.

Two years in, Kelpwell outgrows its first storefront. Mara wants a faster, headless front end and a redesigned shop. On a rented platform this is the frightening moment, the one the migration spoke is about. For Kelpwell it is close to a non event. I build the new Solidus storefront, point it at the same Stripe account, and the 3,400 card subscriptions and 600 direct debit mandates keep charging on their existing schedules throughout, because they were never in the old storefront. The stored credential chains are intact, so no card renewal is bounced back into authentication.³ The SEPA mandates are untouched, because the Creditor Identifier did not change.⁷ Nobody is asked to re enter a card. Nobody is charged twice. The dunning, the card account updater and the network tokens carry on exactly as before, because they sit in the account, not the shop.¹⁰ Mara's launch risk is a front end launch risk, not a billing one.

Now the shop that did not do this. Imagine a rival, Dunewater, an invented box of the same size on a rented platform whose subscriptions run only through its bundled payments app. When Dunewater's owner wants the same redesign, the schedules and the vaulted tokens turn out to belong to the platform. Moving means either staying put or asking all 4,000 subscribers to enter their card again, with the churn that implies. That is not a redesign decision any more. It is a hostage negotiation, and it is exactly the trap I walk through in the migration subscriptions spoke. Same customers, same products, same monthly box. The only difference is who owned the subscriptions, and that difference was decided two years earlier, at the checkout, before anyone was thinking about redesigns at all.

The table below is the whole contrast in one view.

Question	Owned on your processor account (Kelpwell)	Rented through a platform app (Dunewater)
Where the schedule lives	Your processor account	The platform
Where the card token lives	Your processor account, portable processor to processor	Often the platform's gateway
Where the SEPA mandate lives	Your own Creditor Identifier	Tied to the platform setup
Change storefront	Point the new shop at the same account, no disruption	Schedules can break, re enrol every subscriber
Who owns dunning and retries	You, in your account	The app, on its terms
Who sets the fees and rules later	A processor you can leave	A platform you may not be able to

What I settle before I build

Because the portability is decided at the start, the questions that matter come before the first payment, not after. On a build like Kelpwell's I settle these, in writing, with the client and the processor:

The processor account is the client's own, in the client's name, not mine and not a platform's. Recurring billing runs on the processor's native billing in that account, not through a storefront app that would hold the schedules. Card agreements are set up as proper merchant initiated transactions, with the mandate text and the stored credential handling correct from the first charge, so the scheme identifiers exist to carry.⁶³ SEPA collections run under the client's own Creditor Identifier.⁷ Dunning, retries, the card account updater and network tokens are configured in the client's account and documented, so the client knows what they own.⁹¹⁰ And the processor is one with a published export path, the same test I apply to any processor, because a processor you can leave is worth more than a slightly lower fee from one you cannot.

Settle those, and the subscription base is an asset the business owns and can carry anywhere. Skip them, and it becomes something the business merely rents, on a lease it did not read, that comes due the day it wants to grow.

The honest position

Subscriptions you actually own are not a product I sell. They are a consequence of one architectural choice: run the recurring billing in a processor account the client holds, on a custom store that treats the storefront as replaceable and the processor as the home of the schedule, the token and the mandate. Do that, and a change of shop is a front end project, not a billing crisis, and a better processor deal is always yours to take. Do the opposite, and you can build a healthy subscriber base that you do not actually control, and only find out the day you try to move it.

The build costs more than switching on an app, and I have been honest about that and about the fees, the compliance and the single point you carry. What you get for it is a subscriber base that is portable by design, because the card vault, the mandates and the schedules were never locked inside the shop in the first place.

If your revenue runs on recurring payments and you want to know, before you build or before you move, whether your subscriptions are ones you own or ones you only rent, bring it to a free workshop and I will map exactly where your plans, schedules, mandates and tokens live. The first two weeks of the work are on me.

Stripe, How subscriptions work (a subscription contains the subscribed customer, product and price, and Stripe generates invoices, attempts collection and manages the lifecycle, retry logic and dunning), Stripe Billing documentation, 2026, https://docs.stripe.com/billing/subscriptions/overview ↩
PCI Security Standards Council, FAQ 1280: Can card verification codes be stored for card on file or recurring transactions? (no, prohibited even with the customer's consent once the payment is authorised), 2026, https://www.pcisecuritystandards.org/faqs/1280/ ↩
Visa Acceptance Solutions, Support for merchant initiated transactions and credential on file for Visa, Mastercard and Discover (the initial transaction is cardholder initiated under the stored credential framework, and its transaction identifier is carried on later merchant initiated transactions), 2026, https://support.visaacceptance.com/s/article/Support-for-Merchant-Initiated-Transactions-and-Credential-on-File-for-Visa-Mastercard-and-Discover ↩ ↩² ↩³
Mastercard, Credential on file transactions (a merchant initiated transaction is a follow on to an initial cardholder action and must reference the original stored credential), Mastercard Gateway documentation, 2026, https://na.gateway.mastercard.com/api/documentation/integrationGuidelines/supportedFeatures/pickAdditionalFunctionality/storedCredentials.html ↩
European Banking Authority, Single Rulebook Q&A 2018_4031 (payee initiated transactions are not subject to SCA, setting up a mandate through a remote channel is subject to SCA, and card on file payments triggered by the payer remain in scope), final answer 1 March 2019, https://www.eba.europa.eu/single-rule-book-qa/qna/view/publicId/2018_4031 ↩ ↩²
Stripe, Strong Customer Authentication readiness (off session charges on a saved card are merchant initiated transactions that require an agreement, also called a mandate, between you and the customer; exemptions are not guaranteed and an off session payment can still be sent for authentication by the bank), Stripe documentation, 2026, https://docs.stripe.com/strong-customer-authentication ↩ ↩² ↩³
European Payments Council, SDD mandate layout guidelines (the Unique Mandate Reference and the Creditor Identifier are mandatory elements of the mandate), EPC392-08 version 11.0, October 2025, https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2025-10/EPC392-08%20v11.0%20SDD%20Mandate%20Layout%20Guidelines_0.pdf ↩ ↩² ↩³
European Payments Council, Clarification paper for the SEPA Direct Debit Core and SEPA Direct Debit B2B rulebooks (a change of the creditor reference party does not affect the validity of the mandate, and a change of creditor is handled by amendment carrying the original reference), 2026, https://www.europeanpaymentscouncil.eu/document-library/guidance-documents/clarification-paper-sepa-direct-debit-core-and-sepa-direct ↩
Stripe, Automate payment retries (Smart Retries configured in the Dashboard, model chosen retry timing, up to eight retries over two weeks by default, direct debit retries follow the payment method rules), Stripe Billing documentation, 2026, https://docs.stripe.com/billing/revenue-recovery/smart-retries ↩ ↩² ↩³
Stripe, Payments optimisation and Authorization Boost (card account updater retrieves and updates saved card information automatically because outdated card information is a common source of declines; network tokens substitute for the card number and keep processing with up to date credentials when the card data changes), Stripe documentation, 2026, https://docs.stripe.com/payments/analytics/authorization-boost ↩ ↩² ↩³ ↩⁴
Solidus, Payments and refunds (a payment is tied to its payment method and a refund is processed through the original payment's method), Solidus Guides, 2026, https://guides.solidus.io/advanced-solidus/payments-and-refunds ↩
Solidus, solidus_subscriptions extension (a subscription is created for each group of subscribable line items, due installments are processed on a schedule, and failed installments are retried), solidusio on GitHub, 2026, https://github.com/solidusio/solidus_subscriptions ↩