Written or reviewed by Libby James, founder of Merchant Advice Service and specialist in merchant payments and complex provider requirements.
Tell us about your business, current payment setup and what you're looking to change. We'll use it to understand your requirements before identifying providers that may be suitable.
A subscription business does not simply charge the same customer every month.
It has to manage what happens when that customer:
joins → starts a trial → becomes paying → upgrades → adds users → changes billing date → renews → pauses → downgrades → cancels
And every one of those events can affect what should be billed.
That is what makes subscription payment processing different from simply accepting repeat card payments.
The payment itself might take seconds.
The subscription relationship could last five years.
For a simple membership charging £20 every month, the setup can be relatively straightforward.
For a business offering:
The difficult part can become deciding what the customer should be charged, when, and why.
A good subscription setup therefore needs more than a payment gateway.
It needs the billing logic, payment infrastructure and customer lifecycle to agree with each other.
Subscription businesses are not automatically classed as high risk, but recurring billing, annual prepayments, chargebacks and future customer obligations can influence underwriting. Our High-Risk Merchant Accounts guide explains how these wider risk factors can affect provider appetite and merchant account approval.
This guide explains how that should work. As subscription volumes grow, provider choice can affect far more than the transaction rate. Our Payments Strategy Library covers recurring-payment migration, fees, payment performance and wider provider strategy for established businesses.
Subscription payment processing is the combination of systems used to bill customers repeatedly for an ongoing product or service.
It can involve:
subscription management + billing rules + payment processing + customer account + reporting
For example:
Customer chooses £49/month plan
↓
Billing system creates subscription
↓
Customer makes initial payment
↓
Subscription becomes active
↓
Next billing date calculated
↓
Payment collected
↓
Account remains active
But a mature subscription system also needs to know what happens when the customer:
That is why subscription billing and recurring-card processing should not be treated as exactly the same thing.
Recurring billing requires the right combination of payment gateway functionality, tokenisation, stored credentials and provider support. Our main Payment Gateways guide explains the wider factors businesses should consider when comparing gateway and payment-provider options.
This is the first distinction to make.
The payment mechanism.
It answers:
“How can I legitimately charge this customer's card again?”
MAS covers this separately in our guide to Recurring Card Payments, including:
The commercial logic around the customer relationship.
It answers:
“How much should this customer be charged today?”
For example:
Customer joined:
Professional – £80/month
Then added:
3 additional users
Then upgraded halfway through the month.
The recurring-payment system can process whatever transaction it receives.
The subscription system needs to decide what that transaction should actually be.
This becomes important as a subscription business grows.
Your billing system should know:
Your gateway should then process the appropriate payment.
If your finance team is manually calculating subscription amounts in spreadsheets and then typing transactions into a payment system, the problem is not simply the merchant account.
It is the subscription architecture.
Subscription businesses should assess the wider PSP relationship as well as recurring-payment functionality. Our Ecommerce Payment Providers UK guide covers provider selection across subscriptions, fees, integrations, international payments, settlement and future switching.
A useful way to design subscription payments is to stop thinking about individual transactions and instead map the customer's whole lifecycle.
For example:
Visitor
↓
Trial customer
↓
Active subscriber
↓
Renewing subscriber
↓
Upgrade / downgrade / pause
↓
Cancellation requested
↓
Subscription ends
↓
Former subscriber
↓
Potential reactivation
Payment events happen throughout that lifecycle.
The billing system should know which state the customer is in before asking the payment provider to collect money.
The first stage is deciding exactly what the customer is agreeing to.
For example:
£29 per month until cancelled
is different from:
£290 for a 12-month contract paid monthly
and different again from:
14 days free, then £29 per month until cancelled.
Those structures may all create monthly-looking payments.
But commercially and contractually they are not identical.
This distinction is particularly important.
Consider:
£50/month. Cancel according to the subscription terms.
versus:
12-month commitment costing £600, collected as 12 × £50 payments.
The card transactions may look almost identical.
The customer's contractual commitment is not.
Businesses should make this very clear at sign-up.
The CMA is currently investigating whether certain early cancellation fees and the way they are presented on one company's “annual billed monthly” software plan comply with consumer protection law. Importantly, the CMA has not made a finding that the company breached the law; the investigation illustrates why contract length, monthly billing and cancellation charges need to be communicated clearly.
Free trials are one of the areas where subscription design can easily create customer disputes.
For example:
30 days free
becomes:
£19.99/month
unless the customer cancels.
From the business's perspective, this is a conversion mechanism.
From the customer's perspective, the important questions are:
When does the free period end?
What will I be charged?
When will the first payment happen?
Will it continue automatically?
How do I stop it?
A trial that converts into a paid subscription should not rely on the customer forgetting that they signed up.
That is particularly important given the new UK subscription-contract regime coming in 2027.
This is an important update for subscription businesses.
The Digital Markets, Competition and Consumers Act 2024 contains a new statutory regime specifically for consumer subscription contracts.
As at July 2026, those subscription-contract provisions are not yet in force.
Following its consultation, the government said in April 2026 that it anticipates the new regime commencing in spring 2027 and intends to publish implementation guidance.
So businesses should distinguish between:
Existing consumer law continues to apply, including rules on fair and transparent contract terms and existing distance-selling/cancellation requirements where relevant. The CMA's unfair-contract-terms guidance was itself updated on 22 July 2026.
Expected from spring 2027.
Businesses designing subscription systems now should therefore consider whether their technology will be capable of supporting the forthcoming requirements.
The new regime is aimed at consumer subscription contracts, rather than every B2B commercial agreement.
The Act's definition includes relevant consumer contracts where:
That means businesses operating:
should pay close attention.
A B2B software contract is not automatically brought into this consumer subscription regime simply because it is billed monthly.
Some implementation details still depend on secondary legislation, so businesses should monitor the final rules and guidance.
But the framework already contains some significant changes.
Customers will need relevant information before entering the subscription contract.
The regime requires reminder notices to help consumers understand that their subscription is continuing and another renewal payment is approaching. The government has confirmed these notices will need to be provided in writing on a durable medium, with their purpose immediately apparent.
The Act requires subscription cancellation arrangements to be straightforward and not involve unnecessary steps.
Where a subscription is entered into online, the regime also requires an online cancellation route.
The government intends the regime to include an initial 14-day cooling-off period and, in relevant cases, a further renewal cooling-off period after a free trial or a contract of 12 months or more automatically renews.
The government's April 2026 response confirms its intention for consumers cancelling during relevant renewal cooling-off periods to receive full or proportionate refunds depending on what has already been supplied.
This is where the regulatory change becomes relevant to MAS.
Businesses may initially see this as:
“We need some new legal wording.”
But there are operational consequences too.
Your systems may need to know:
when a trial ends
when a renewal happens
when a reminder must be triggered
when the customer enters a cooling-off period
when cancellation becomes effective
whether a refund is due
how much should be refunded
whether future payments must stop
So this is not only a Terms & Conditions exercise.
For larger subscription businesses, it is a billing, CRM and payments implementation project.
The billing system should know precisely when:
trial
becomes:
paid subscription.
For example:
1 July — trial begins
14 July — trial ends
15 July — £30 charged
15 August — next £30 charge
That sounds simple.
But businesses need to decide what happens where:
Those rules should be designed rather than improvised.
There are two common approaches.
Customer enters the trial without giving payment details.
At the end:
Add payment method to continue.
This reduces surprise billing but creates another conversion step.
Customer enters card details when the trial starts.
At the end, the agreed paid subscription begins automatically unless cancelled.
That creates less payment friction at conversion but makes transparency about the upcoming charge particularly important.
Neither model is universally better.
The right choice depends on:
Pricing is often presented as:
£40/month
or:
£400/year
Annual billing can improve cash flow for the subscription business.
But it also changes the customer and payment relationship.
A £400 annual payment is not merely a larger version of a £40 monthly payment.
The business receives more money upfront while continuing to owe the subscription service for the rest of the year.
Annual renewals can also be easier for customers to forget.
That makes:
particularly important.
Again, these are different.
Customer pays:
£1,200 today
for 12 months.
Customer commits to:
12 months
but pays:
£100 each month.
Customer pays:
£100 each month
with a rolling monthly contractual arrangement.
A good subscription checkout should make the difference clear.
The billing platform also needs to understand it because:
billing frequency ≠ necessarily contract duration.
Suppose a customer pays:
£50/month
for Standard.
Halfway through their billing period they upgrade to:
£100/month Pro.
What happens next?
Several models are possible.
Customer receives Pro immediately and pays for the additional value for the remainder of the period.
Service changes now but the adjustment appears on the next invoice.
Customer remains on Standard until the next billing date and then moves to Pro.
None is automatically correct.
What matters is that:
Proration is the process of adjusting a subscription charge to reflect only part of a billing period.
For example:
Customer's existing plan:
£30/month
New plan:
£60/month
They upgrade exactly halfway through the month.
A billing system might calculate a credit for the unused part of the old plan and a charge for the remaining part of the new one.
The precise method varies.
The important point is that the business should not have employees manually deciding each time what seems fair.
At 100 subscribers, manual adjustments may feel manageable.
At:
10,000 customers + 4 plans + add-ons + annual/monthly billing + mid-cycle upgrades
it becomes extremely difficult.
Subscription complexity grows faster than subscriber numbers.
That's often the point at which a dedicated billing layer becomes more important than adding another feature to the payment gateway.
Downgrades create a different question.
If the customer moves from:
£100/month Pro
to:
£50/month Standard
does it happen:
immediately
or:
at the next renewal?
If immediate, does the customer receive:
What happens to features or usage above the lower plan limit?
Again, this is not really a card-processing question.
It is subscription logic that determines the next payment.
Many B2B and SaaS subscriptions charge according to users or licences.
For example:
£20 per user per month
Customer begins with:
10 users = £200
Then adds five people.
The billing system needs rules for:
The gateway should not need to understand why the amount changed from £200 to £300.
But the subscription platform absolutely should.
Some subscriptions no longer have one fixed price.
For example:
£100/month platform fee + £0.02 per API call
or:
£50/month + storage consumed
or:
Subscription + transaction usage
Now the billing process needs an additional component:
metering.
The system must know what the customer actually consumed.
A simplified flow becomes:
customer activity
↓
usage recorded
↓
usage rated according to price
↓
invoice generated
↓
payment requested
This introduces new failure points.
For example:
What if usage data arrives late?
What if it is duplicated?
What if the customer disputes the usage?
What happens if usage creates a bill ten times larger than normal?
Imagine a customer normally pays:
£500/month
but unexpectedly consumes enough service to generate:
£12,000
that month.
Commercially the invoice may be correct.
But the payment profile has suddenly changed dramatically.
Businesses offering uncapped variable usage should think about:
before an enormous automated transaction suddenly appears.
A growing number of subscription products combine several charging models.
For example:
£200 monthly base
£10 per active user
1% of certain activity
premium support add-on
This can be commercially attractive.
It also means the billing system needs to assemble several different components into one invoice.
For more complex subscriptions, the question becomes:
Which system is the source of truth for what the customer owes?
That needs a clear answer.
This is where the technology stack becomes important.
Typically manages:
Typically handles:
May control:
May need:
The more sophisticated the subscription business becomes, the more important it is that those systems talk to each other.
Consider:
CRM says customer cancelled
billing platform says active
gateway says card charge scheduled
Which one is correct?
That is not a theoretical question.
It is how customers end up being charged after they think they have cancelled.
Every subscription business should know which platform is the source of truth for subscription status and how that status updates all connected systems.
Pause functionality can be useful where customers do not necessarily want to cancel permanently.
Examples include:
But pause needs rules.
Does a paused subscriber:
Again, the payment processor can only act on instructions.
The business needs to define what paused actually means.
Subscription businesses often use:
20% off for three months
or:
£1 first month
or:
founding customer price
The billing platform should know:
Promotions that automatically convert into higher-priced ongoing subscriptions also need especially clear customer communication.
The forthcoming UK subscription regime expressly includes relevant arrangements where a free or reduced-price period rolls into full or increased pricing unless the consumer takes action.
Subscription businesses often change pricing without moving existing customers.
For example:
New customers: £49
Existing customers: £29
Three years later, the billing system may contain:
This becomes important when changing billing platforms.
A migration that simply says:
“Move everyone onto the current £49 plan”
could create a very serious commercial problem.
The subscription state includes more than:
customer + card.
It can include:
customer + plan + price + renewal date + discount + credit + contract status
Cancellation should be considered when designing the subscription — not added later.
The business needs to decide:
Can customers cancel immediately?
Does cancellation take effect at period end?
Do they retain access until then?
Is there a fixed minimum term?
Is a refund due?
What happens to unused credits?
Can they reactivate?
For UK consumer contracts, current law already requires contract terms to be fair and transparent. CMA guidance stresses that auto-renewal and cancellation terms should not create unfair barriers for consumers.
The forthcoming subscription regime will go further by requiring straightforward arrangements for customers to end in-scope subscription contracts, including an online route where the contract was entered into online.
We covered this in more detail in our Recurring Card Payments guide.
But subscription systems need to understand the distinction.
A customer might:
cancel the subscription correctly
and therefore the billing system should stop future payments.
Or they might:
ask their card issuer to stop the recurring card authority
without resolving the underlying subscription contract.
Those situations need different operational handling.
The FCA confirms that cancelling a recurring card payment does not necessarily terminate the underlying contract.
This needs to be designed.
For example:
Customer pays monthly on the 1st.
They cancel on the 15th.
Does access:
stop immediately
or:
continue until the 31st?
Both models exist.
The right answer depends on:
But the product, billing and payment systems should all reach the same answer.
Otherwise you can end up with situations such as:
customer refunded but still has premium access
or:
customer paid until month-end but was locked out immediately.
Subscription refunds can become complicated because they may involve:
Businesses should decide whether a credit and a refund are interchangeable.
They are not necessarily the same thing.
A credit normally remains inside the subscription relationship.
A refund returns money to the customer.
The billing system and payment gateway need to record them correctly.
The government's current implementation plan says consumers covered by the new regime will have a 14-day renewal cooling-off period following a free trial or the auto-renewal of a contract lasting 12 months or more.
For services already partly supplied during that period, the government intends businesses to be able to retain the amount proportionate to the part already delivered, with the remainder refunded.
That means businesses affected by the rules may eventually need systems capable of calculating:
What proportion of this renewed subscription has actually been supplied?
This is another reason not to leave subscription refunds as a manual afterthought.
Payment failure matters, but we should not duplicate the recurring-payment article here.
The subscription-specific question is:
What happens to the customer's subscription status when payment fails?
Possibilities include:
Payment fails → access stops.
Payment fails → customer retains access for seven days.
Some functionality remains available.
Payment recovery takes place before the subscription is terminated.
Particularly relevant to B2B customers.
The right policy depends on the product.
But it should be deliberate.
A failed transaction is a payment event.
It does not automatically tell the product what to do with the customer.
The business has to define that.
For example:
Payment failed
↓
Subscription moves to Past Due
↓
Customer notified
↓
Recovery process begins
↓
Successful:
Active
or:
Unsuccessful after agreed period:
Suspended / Cancelled
That is much cleaner than:
Card decline = delete customer.
Subscription businesses often talk about churn as though it is one metric.
But customers leave for different reasons.
Customer deliberately cancels because of:
Customer is lost because payment failed and could not be recovered.
Customer remains but pays less.
Customer temporarily stops.
These should not necessarily be treated as the same commercial event.
The recurring-payments article deals with recovering failed transactions.
The subscription system needs to tell the wider story about why the customer relationship changed.
Payment volume alone is not enough.
Useful operational metrics can include:
Active subscribers
New subscribers
Trial conversion
Renewals
Cancellations
Downgrades
Upgrades
Paused accounts
Average subscription value
Annual/monthly mix
Payment failure
Recovered payments
Refunds
For more sophisticated businesses, it can be useful to connect those events back to:
This lets the business see whether it has a payment problem, a pricing problem or a product problem.
Suppose cancellation increases because customers think the subscription is poor value.
More aggressive retry logic will not solve that.
Likewise, if otherwise happy customers are disappearing because their renewal cards fail, redesigning the pricing page will not solve that.
Subscription businesses should distinguish:
customers who don't want to pay
from:
customers who want to pay but couldn't.
That's an important commercial difference.
Physical subscription goods create additional questions.
For example:
Payment date: 1st
Box packed: 4th
Box dispatched: 6th
What happens where:
The subscription system now needs to coordinate:
payment + inventory + fulfilment
rather than simply payment + account access.
This is why a subscription-box business may need different technology from a digital membership even though both charge £30 per month.
Digital products often have a much faster service relationship.
Examples include:
The system can potentially grant and remove access immediately.
Current UK distance-selling rules also contain specific requirements around digital content, including customer agreement where immediate access means losing the normal 14-day cancellation right.
Digital subscription businesses therefore need their:
checkout + consent + billing + access
journey to work together.
Business subscriptions can work very differently from consumer subscriptions.
Examples include:
B2B subscriptions may involve:
The forthcoming DMCC consumer subscription regime does not automatically turn every commercial B2B subscription into a consumer subscription contract.
But the billing architecture challenges still exist.
A SaaS business might have:
£99/month automatically charged to card
and:
£50,000 annual contract invoiced on 30-day terms
inside the same product.
That means the subscription platform may need to support different payment methods without creating separate customer-management systems.
The subscription state might still be:
Active
even though one customer pays by card and another pays against an invoice.
Subscription billing should ideally be designed independently of one payment rail.
A business might use:
For immediate online activation and international customers.
For predictable UK recurring collections.
For larger B2B invoices.
The subscription system should know:
customer owes £X on date Y
while the payment infrastructure handles how that money is collected.
That separation can make the business much easier to scale.
This can become an expensive problem later.
A business builds:
plans + customer accounts + renewal logic
directly inside one gateway integration.
Then three years later it wants to:
and discovers that the gateway has effectively become the subscription database.
For a very simple business, combined billing/payment functionality may be perfectly adequate.
For a larger subscription business, it is worth understanding how portable the architecture is before growth makes migration difficult.
This is another topic the article should own.
Imagine you have:
40,000 active subscribers
spread across:
Moving them involves much more than transferring payment tokens.
You may need to migrate:
customer
subscription state
plan
price
renewal date
trial date
discount
credits
payment credential
billing history
cancellation status
This is a subscription migration, not merely a gateway migration.
Examples include:
Customers get billed earlier or later than expected.
A £29 customer becomes £49.
The trial-end date was migrated incorrectly.
Subscription status does not map properly.
Promotional customers suddenly receive full-price invoices.
Payment details need updating.
Customer balances do not transfer.
This is why a major billing migration should be extensively reconciled before the old platform is switched off.
Don't merely ask:
“Did 40,000 customers migrate?”
Ask:
How many active monthly?
How many active annual?
How many trials?
How many cancelled-but-still-active-until-period-end?
How many paused?
How many past due?
How many discounted?
How many legacy-price customers?
The totals should make sense before and after migration.
That is much more likely to expose problems.
Not every subscription company does.
If the model is simply:
£20 every month until cancelled
a payment provider's built-in recurring functionality may be sufficient.
Specialist subscription billing becomes more useful when the business introduces several of these:
The decision should be driven by actual complexity.
Once a business has a substantial subscriber base, the payment architecture becomes much more important.
At that point, ask:
Can we change our pricing without rebuilding payments?
Can customers upgrade and downgrade automatically?
Do we know exactly why customers leave?
Can we switch gateway without rebuilding the subscription product?
Can we comply with the forthcoming 2027 subscription rules?
Can we calculate refunds properly?
Can finance reconcile subscriber activity to actual settlements?
Could we migrate 10,000 customers safely tomorrow if we needed to?
Those are bigger questions than:
“What's the transaction rate?”
For UK consumer subscription businesses, I would start this work before the new regime actually commences.
Not because businesses should pretend rules are already in force.
But because changing subscription architecture takes time.
Areas to review include:
Is the contract and auto-renewal structure clear?
Can the system identify when each trial converts?
Does the business accurately know when customers renew?
Can reminders be generated at the required stages?
Can customers end subscriptions straightforwardly?
Can an online subscriber cancel online?
Can the system identify relevant cooling-off periods?
Can full or proportionate refunds be calculated correctly?
Does cancellation immediately stop future scheduled payment requests where appropriate?
The government's latest position is that the new subscription regime is anticipated to commence in spring 2027, with further regulations and guidance to follow.
Instead of simply comparing transaction price, start with the subscription model.
Ask whether the setup supports:
Can the business create the products it actually wants to sell?
Can trial duration and conversion be controlled?
Can both coexist?
Can an annual commitment billed monthly be represented accurately?
What happens mid-cycle?
How are adjustments calculated?
Can variable consumption be billed?
Can promotions expire automatically?
Can a subscription be paused without destroying the customer record?
Can end dates and customer access be managed correctly?
How are adjustments recorded?
How does payment status affect subscription status?
Can different customers use cards, Direct Debit or bank payments?
Can the subscription state communicate with the product?
Can finance explain what has been billed and what has actually been paid?
What happens if the business wants to change provider?
MAS can help businesses understand the payment side of subscription architecture, particularly where the requirements have become more complex.
We can consider:
Where simple monthly charging has evolved into:
the payment setup may need reviewing.
It is important to establish whether the issue is actually:
billing logic
recurring-payment configuration
acquiring
failed-payment recovery
or:
the integration between them.
Stored credentials are only one part of migration.
The subscription state and billing rules may be equally important.
For substantial portfolios, MAS can also look at:
Final provider acceptance, pricing and technical configuration remain with the relevant payment provider.
Tell MAS:
what you sell
consumer or B2B
number of active subscribers
monthly and annual mix
pricing model
whether you offer trials
whether customers can upgrade/downgrade
current billing platform
current payment provider
monthly payment volume
and:
what is currently causing difficulty.
For larger subscription businesses, it is useful to understand the whole customer lifecycle, not just the transaction rate.
Choose an area below and we'll take you to the relevant guide, where you can understand your options and find suitable providers.
Understand merchant accounts, acquiring and card processing options.
Online payments, ecommerce, recurring payments and complex integrations.
Explore options for taking face-to-face card payments.
Explore EPOS, POS and integrated payment setups for your business.
Guidance for businesses with more complex underwriting or payment requirements.
Explore business funding linked to your card sales.
Tell us how your business takes payments and what you're looking to change. We'll use your answers to understand your requirements and identify providers that may be suitable.
Merchant Advice Service helps businesses understand their payment requirements before approaching providers.
How Merchant Advice Service works →If your business already takes card payments, you may be able to access funding linked to your future card sales.
Explore merchant cash advance →Tell us about your business, how you take payments and what you're looking to change. We'll use your answers to identify providers that may be suitable.
Libby James is the founder and Managing Director of Merchant Advice Service. Since 2016, she has worked directly with businesses and payment providers across merchant accounts, card processing, payment gateways and complex provider requirements.
Libby specialises in high-risk, declined and harder-to-place merchants, as well as businesses requiring specialist payment methods, integrations or international support. She writes and reviews Merchant Advice Service content, drawing on practical experience gained from real merchant enquiries and provider relationships.
