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 customer pays you today.
Can you keep their card details and charge them again next month?
Potentially, but the fact that a customer has made one successful card payment does not automatically give a business permission to charge that card again whenever it chooses.
This is where recurring card payments become more complicated than they first appear.
A business needs to consider:
It is also easy to mix together terms that mean slightly different things:
recurring card payment, Continuous Payment Authority, card-on-file, stored credential, customer-initiated transaction, merchant-initiated transaction, subscription payment and instalment payment.
They are related.
They are not all interchangeable.
This guide explains what businesses actually need to know when taking repeat card payments.
Merchant Advice Service is an independent UK payments information and provider-matching service with experience researching payment setups for subscription and recurring-revenue businesses. For these businesses, choosing a provider involves more than checking whether recurring card payments are supported. The wider setup can include subscription billing, tokenisation, failed-payment recovery, Direct Debit, reporting, integrations and international requirements.
Yes, where an appropriate recurring or stored-credential arrangement has been established and the customer has consented to it.
The FCA says recurring card payments — sometimes called Continuous Payment Authorities or CPAs — allow a business to charge a customer's card on a recurring basis without obtaining permission separately for every payment.
The payments can potentially be:
but only where the customer has agreed to the arrangement.
The FCA says customer consent must be clear, specific and informed, with enough information about the amount and frequency for the customer to understand what they are agreeing to.
The important distinction is:
Having the technical ability to charge a stored card does not necessarily mean you have the customer's permission to do so.
Both matter.
A recurring card payment allows a business to collect future payments from a debit or credit card according to an agreement with the customer.
Examples could include:
£40 every month for a gym membership
£250 every year for software
monthly maintenance-plan payments
or potentially:
a varying monthly amount calculated according to usage
where that variable charging arrangement was appropriately agreed.
These payments are sometimes called:
The FCA uses recurring card payment and Continuous Payment Authority when explaining the arrangement to consumers.
This is one of the most important distinctions in this article.
Imagine a customer shops with an online retailer.
They choose:
Save this card for next time.
Three months later, the customer returns, adds something to their basket and clicks:
Pay £75
The card credential may already be stored.
But the customer has actively initiated this new purchase.
That is different from:
Business automatically charges £75 on the first day of every month without the customer returning to checkout.
In the second example, the later transaction is being initiated by the merchant under a pre-existing agreement.
So:
Card-on-file does not automatically mean recurring payment.
A stored credential can support different types of future transaction.
Payment providers increasingly talk about:
CIT
and:
MIT
Understanding the difference helps explain how recurring payments actually work.
A CIT is triggered by the customer.
For example:
Customer visits checkout → selects product → confirms £100 payment
The customer is actively participating in that transaction.
The customer might use:
The fact that the card was stored doesn't necessarily change the fact that the customer initiated the payment.
An MIT happens where the merchant initiates a subsequent payment under an earlier agreement with the customer.
For example:
Customer joins gym
↓
Customer agrees to £49 monthly card payments
↓
Initial payment/setup occurs
↓
Next month the gym initiates £49 payment without the customer returning to checkout
That later payment can fall into the merchant-initiated transaction framework when correctly established and submitted.
European regulatory guidance similarly recognises that subsequent recurring card transactions can be initiated by the payee where the customer has previously given the required mandate and does not take a specific action to trigger every subsequent transaction.
Consider these two £100 transactions.
Customer logs into their account, selects an invoice and presses:
Pay £100 using saved card
Merchant automatically collects:
£100 renewal payment
while the customer is asleep.
Both might use exactly the same stored card credential.
But the transaction journeys are different.
That matters when payments are:
When a recurring-payment setup performs badly, one of the first things worth understanding is:
Are the transactions being classified and submitted according to what is actually happening?
A simplified journey looks like this.
For example:
£39 per month until cancelled
or:
Variable monthly payment based on usage, calculated according to the terms explained here.
Usually through a secure checkout or payment page.
The payment provider records the appropriate information that allows the stored credential to be used for future payments.
In modern setups, this commonly involves tokenisation rather than the merchant keeping raw card information itself.
For example:
1 August — £39
The stored credential/token is used in accordance with the existing agreement.
Successful:
subscription/member/account remains paid
Failed:
payment-recovery process begins
That final stage is where a lot of businesses lose revenue unnecessarily.
Before worrying about gateway settings, retries or tokenisation, establish:
What did the customer actually agree to?
The FCA says valid consent for a recurring card payment should be clear, specific and informed. Customers should receive enough information about the amount and frequency of payments to understand the arrangement.
That means a recurring arrangement should not be hidden in vague wording that leaves the customer surprised when money leaves their account.
A useful customer journey makes clear things such as:
The precise requirements depend on the business and contract.
But the basic test is simple:
Would a reasonable customer understand when and why you are going to charge their card again?
Yes, potentially.
This is another common misconception.
A CPA does not necessarily have to be:
£50 every month forever.
The FCA expressly says recurring card payments can be for varying amounts and can potentially occur at varying times — provided that this is what the customer agreed to.
That could be relevant to businesses charging according to:
But the more variable the arrangement becomes, the more important it is that the customer understands what they have authorised.
This is where the terminology starts to matter.
The UK Strong Customer Authentication technical standards specifically address a series of recurring transactions with:
the same amount + the same payee.
SCA is applied when the customer creates, amends or initiates the series for the first time. Subject to the relevant conditions, subsequent transactions in that fixed series can then be initiated without SCA being applied each time.
Variable recurring charges need to be handled according to the appropriate stored-credential/MIT framework rather than simply pretending that they are fixed recurring transactions.
Mastercard's own gateway documentation, for example, distinguishes a fixed-amount recurring-payment exemption from merchant-initiated transactions that can include variable amounts.
MAS insight: the merchant does not need to become an expert in scheme messaging.
But its payment provider should be.
If your business has variable recurring billing, tell the provider exactly what is happening rather than simply asking:
“Do you support subscriptions?”
Imagine the customer agreed to:
£30 per month.
The business later increases its membership to:
£35 per month.
Do not simply assume that because a card is stored, the business can change the amount however it wishes.
Consider two separate questions.
Does the agreement allow the price change and has it been communicated appropriately?
Does the change affect the way the recurring payment series or merchant-initiated arrangement needs to be handled?
Under the UK SCA recurring-transaction provisions, creating or amending a fixed recurring series is specifically relevant to SCA.
Your gateway or acquiring provider should therefore understand how changes to an existing recurring mandate are handled.
No.
This is another area where merchants can become confused.
A correctly established recurring arrangement does not necessarily require the customer to complete a 3D Secure challenge every month.
For a fixed recurring series with the same amount and payee, the UK technical standards require SCA when the customer creates, amends or initiates the series for the first time, while allowing subsequent transactions in that series to proceed without SCA being applied each time, subject to the relevant requirements.
This is logical.
If a customer had to return to checkout and authenticate every monthly payment manually, it would no longer operate like an automatic recurring payment.
A recurring payment should not be treated as:
“We obtained a card number once, so now we can run transactions against it.”
The initial customer interaction establishes the payment relationship.
Visa's stored-credential framework, for example, describes an initial customer-initiated transaction used to establish storage of the credential, with future use then identified according to the type of subsequent transaction.
In practical terms, businesses should make sure their provider understands that the initial transaction is being used to establish future recurring or stored-credential payments.
A recurring-payment business does not necessarily need to store raw card details itself.
Modern payment providers commonly use tokenisation.
Instead of your system retaining:
16-digit card number
the payment provider can associate the credential with a token that can be used for appropriate future transactions.
PCI SSC confirms that certain acquiring tokens can be used for card-on-file and recurring payments.
This can reduce unnecessary handling of payment-card data.
It does not automatically remove all PCI DSS responsibilities, because the scope depends on the payment environment.
No.
This is worth giving a direct answer because it is frequently misunderstood.
The card verification value — the three or four digit code normally printed on the card — must not be stored after authorisation for use in future card-on-file or recurring payments.
PCI SSC specifically states that card verification codes cannot be retained for card-on-file or recurring transactions.
Even if the customer says:
“Yes, you can save my CVV.”
that does not make storing it permissible under PCI DSS.
A properly configured recurring-payment system should not need the merchant to save the CVV and resubmit it every month.
A business should not need a spreadsheet containing:
customer name + card number + expiry + CVV
to operate recurring payments.
If that resembles your current process, the issue is bigger than finding a cheaper merchant account.
The payment architecture needs reviewing.
Customers sometimes assume:
“My card expired, so the subscription must stop.”
That is not necessarily true.
The FCA warns consumers that recurring payments may continue when they receive a new payment card, although this is not always the case.
Payment infrastructure can include services that help update or maintain stored credentials as cards change.
Depending on the provider, these can include:
This can be useful for legitimate recurring businesses because an otherwise happy customer does not necessarily need to disappear just because their physical card expired.
This distinction matters.
Imagine:
Customer's card expires
but:
customer still wants the service.
Keeping an appropriately authorised recurring arrangement working can improve customer experience.
Now compare:
Customer explicitly cancels the recurring payment authority.
The business cannot treat those as equivalent events.
One is a change in payment credential.
The other is withdrawal of payment authority.
For UK consumers, the customer can cancel by contacting:
the business
or:
their card issuer.
The FCA says a card issuer must stop the payments when instructed and cannot insist that the consumer first contacts the merchant.
That's important for businesses.
Do not build a recurring-payment operation around the assumption:
“The customer can only cancel through us.”
They can't.
This is a subtle but very important point.
A customer could tell their card issuer:
“Stop this recurring card payment.”
That stops the payment authority.
It does not necessarily mean that the customer's underlying contractual obligations have disappeared.
The FCA makes this distinction explicitly: cancelling a recurring card payment does not necessarily end the customer's contract with the business, and the customer may still owe money under that contract.
So businesses need to separate:
payment authority
from:
contractual obligation.
This is especially important for:
Payment teams and customer-service teams should understand the difference.
That creates a serious problem.
The FCA says payments taken after a valid cancellation of the recurring card payment are considered unauthorised transactions, and the customer's card issuer must refund them and related charges.
For the merchant, cancellation therefore needs to flow into the payment system properly.
A dangerous setup is:
customer cancels in CRM
but:
gateway still thinks subscription is active.
or:
customer service marks account cancelled
but:
finance spreadsheet continues submitting card payments.
These systems should communicate.
Many businesses treat cancellation entirely as a customer-service task.
For recurring card payments, it should also create a payment event:
customer cancels
↓
recurring authority stopped
↓
future payment schedule updated
↓
account/contract status handled separately
That reduces accidental post-cancellation payments, refunds, complaints and chargebacks.
This is where recurring payments become commercially interesting.
Imagine a customer who has happily paid:
£50 every month for three years.
Payment number 37 declines.
Does that customer suddenly hate your service?
Probably not.
The card may have:
Automatically treating every failed payment as a lost customer can create involuntary churn.
But blindly retrying it over and over is not the answer either.
Sometimes.
Not every decline should be retried.
Payment providers and card schemes can return information that helps determine what should happen next.
Mastercard's current transaction rules, for example, contemplate issuer merchant advice codes for declined recurring transactions and say merchants should be able to receive and act on that advice.
The principle is useful even if your provider presents the information differently:
Use the information attached to the decline rather than treating every failed payment as “try again tomorrow”.
Some payment failures may be recoverable.
Others indicate that another card or customer action is required.
Instead of:
payment fails
↓
retry
↓
retry
↓
retry
↓
chargeback/complaint/cancellation
consider:
payment fails
↓
identify failure type/advice
↓
appropriate retry if supported
or:
customer contacted
↓
secure payment-update link
↓
new credential established
↓
future recurring payments continue
That's a payment-recovery process.
Be careful with simplistic “smart retry” claims.
There are providers that offer retry optimisation and billing systems that attempt to choose more appropriate times.
But businesses should not assume that repeatedly guessing when money may appear in a customer's account is automatically a good payment strategy.
A better recurring setup considers:
For some regulated sectors, further restrictions apply.
Do not take the general recurring-payment guidance on this page and assume it is sufficient for regulated credit collection.
FCA Consumer Credit rules contain additional requirements around Continuous Payment Authorities.
Current CONC provisions include requirements concerning disclosure of:
and particular types of consumer credit can have tighter restrictions.
That means:
gym membership CPA
and:
regulated loan repayment CPA
should not simply be treated as the same compliance problem.
Many businesses report:
Card approval rate: 92%.
That can hide the interesting information.
For a recurring business, measure separately:
How many customers successfully establish the payment relationship?
How many subsequent payments work immediately?
How many initial failures are later legitimately recovered?
How much revenue remains uncollected?
How many customers actually leave?
That gives a much clearer picture of recurring-payment performance.
Imagine two businesses both have a:
5% recurring-payment failure rate.
5% represents:
£2,000 per month
5% represents:
£150,000 per month
The percentages are identical.
The commercial problem is not.
For higher-volume recurring businesses, one of the first questions MAS would ask is:
How much recurring revenue is attempted each month, and how much ultimately remains uncollected because the payment failed?
That can be much more useful than focusing immediately on a 0.1% reduction in processing fees.
These terms are often used interchangeably, but there is a useful distinction.
The payment mechanism that allows future charges to happen.
The wider commercial relationship.
A subscription system might need to manage:
The recurring card payment is only one part of that.
MAS has a separate guide to Subscription Payment Processing, which looks at the wider subscription business model.
These should also be distinguished.
Potentially ongoing.
For example:
£30 every month until cancelled.
Usually a finite series linked to a particular purchase.
For example:
12 monthly payments of £100 for a £1,200 purchase.
The card schemes distinguish between recurring and instalment billing, and they should be configured accordingly rather than simply submitting every repeat card charge as “recurring”. Mastercard's current transaction rules, for example, expressly distinguish recurring-payment and instalment transactions.
That distinction can become particularly important for:
They can produce a similar customer experience:
money is collected automatically
but the underlying payment mechanisms are different.
| Recurring card payment | Direct Debit | |
|---|---|---|
| Uses | Debit/credit card | Bank account |
| Customer gives | Card credential/authority | Bank mandate |
| Payment runs through | Card infrastructure | Direct Debit scheme |
| Direct Debit Guarantee | No | Yes |
| Can customer ask card issuer/bank to stop? | Yes | Yes |
| Card expiry/replacement relevant? | Yes | No |
| Card authorisation required? | Yes | No card authorisation |
| International use | Can be useful | Scheme/geography dependent |
The FCA specifically notes that recurring card payments are not covered by the Direct Debit Guarantee.
The right method depends on the business.
There isn't one universal answer.
Cards can work particularly well where:
Direct Debit can work particularly well where:
Some businesses offer both.
The commercial comparison should look at:
payment success + customer preference + collection timing + failure handling + reconciliation + cost
rather than just the transaction fee.
Variable Recurring Payments — VRPs — are a different payment concept again.
They allow authorised account-to-account payments within agreed parameters using Open Banking infrastructure.
They should not be confused with a variable recurring card payment.
So we potentially have:
Recurring card payment / CPA
versus:
Direct Debit
versus:
Open Banking VRP
all solving variations of the question:
How can the business collect money again without asking the customer to manually make every payment?
MAS has a separate guide to Variable Recurring Payments (VRPs).
That isn't necessarily a merchant-initiated recurring transaction.
For example:
customer receives invoice
↓
logs into portal
↓
clicks Pay
↓
chooses saved card
The customer has actively initiated that payment.
That may be a stored-credential customer-initiated transaction rather than an automated recurring MIT.
This illustrates why:
stored card
and:
recurring payment
should not be treated as synonyms.
Again, don't assume that merely possessing a token means the merchant can initiate any payment it chooses.
The question becomes:
What did the customer authorise when the credential was stored?
An agreement to:
“Save my card so I can check out more quickly next time”
is not necessarily the same as:
“You may automatically charge outstanding invoices to this card.”
This is exactly why payment consent and payment technology need to match.
This distinction is worth remembering.
A gateway may technically allow your system to send a payment request against a token.
That tells you:
the payment can technically be attempted.
It does not by itself tell you:
the customer agreed that you could make this particular charge.
Businesses need both sides correct.
A useful journey can be:
recurring payment fails
↓
customer receives genuine notification
↓
secure update-payment-method link
↓
customer enters new card
↓
new credential/token established
↓
outstanding payment dealt with appropriately
↓
future recurring payments continue
Avoid asking customers to:
A hosted payment page can create a much cleaner recovery process.
MAS covers these payment journeys in our guide to Payment Links for Business.
Depending on the provider and card infrastructure, recurring payments can sometimes continue after a replacement card is issued. The FCA explicitly warns consumers that obtaining a new card does not necessarily stop existing recurring arrangements.
For businesses, the relevant question is:
What credential-updating technology does our payment provider support?
This is particularly important for portfolios containing:
10,000, 100,000 or more active recurring customers.
Small improvements in credential continuity can have a material effect on revenue.
This deserves much more attention than it normally receives.
Suppose a business has:
50,000 active recurring customers
and decides to switch gateway.
A sales presentation might focus on:
“We'll save you 0.15%.”
But the first question should be:
“What happens to the 50,000 stored payment credentials?”
If they cannot be migrated appropriately, the business may suddenly need thousands of customers to re-enter card details.
That can create:
For recurring merchants, token migration can be more important than headline pricing.
Before signing the replacement contract, establish:
Who currently stores or controls the token?
What type of token is it?
Can the credentials be migrated?
Will the existing and new providers cooperate?
Can migration be completed compliantly?
Will customers need to provide card details again?
What happens to existing MIT/recurring relationships?
What happens to refunds on old transactions?
Can both systems operate during migration?
Only after understanding this should the business compare the commercial saving.
For a normal ecommerce merchant, switching gateway can already be a technical project.
For a recurring merchant with tens of thousands of active stored credentials, it can become a revenue migration.
That deserves board-level attention where the portfolio is large enough.
For a substantial recurring portfolio, MAS would want to see more than processing rates.
How many customers are actually being charged?
How much money should be collected?
What proportion succeeds immediately?
Why are payments failing?
How much failed value is subsequently recovered?
What remains unpaid?
How often are expired/replaced cards recovered without customer intervention?
How many customers successfully update their details after contact?
Are customers disputing recurring transactions?
Are payments being taken after customers believe they cancelled?
Those metrics tell you considerably more about the quality of the recurring setup.
At scale, a small improvement to recurring-payment performance can become commercially meaningful.
Imagine:
£2 million monthly recurring card volume
with:
90% first-attempt approval.
The interesting question isn't just:
“Can we reduce the acquiring rate?”
It is:
“What is happening to the other £200,000?”
Some may be genuine hard failures.
Some may be recovered.
Some may represent expired cards.
Some may require customer action.
Some may reveal poor transaction configuration.
The opportunity is to understand that payment waterfall rather than simply treat every decline as lost revenue.
A useful monthly view might be:
£2m recurring payment value due
↓
£1.8m successful first attempt
↓
£200k initially failed
↓
£80k legitimately recovered
↓
£20k updated by customer
↓
£100k final failed value
Now the business can ask:
Why did that final £100k fail?
That is far more actionable than:
“Our approval rate is 90%.”
Not simply every two years — which is advice I would remove from the old MAS article.
Review the setup when there is a commercial reason.
For example:
The trigger should be evidence, not an arbitrary calendar date.
The useful questions are not simply:
“How much per transaction?”
Ask:
For a recurring business, those questions may ultimately be more valuable than a slightly lower headline processing fee.
MAS can look at both new recurring-payment requirements and existing portfolios where payment performance needs reviewing.
We can consider:
For established businesses, useful information can include:
Rather than simply changing provider, the first step is understanding why the payments are failing.
Where customers repeatedly telephone to make the same payment, there may be a more appropriate recurring or customer-entered digital journey.
Token portability and migration should be established before the replacement provider is selected.
This can include:
Final acceptance, transaction configuration and underwriting remain with the relevant payment provider.
Tell MAS:
what customers are paying for
whether the amount is fixed or variable
how often you charge
how the first payment is taken
how later payments are submitted
monthly recurring volume
first-attempt approval rate, if known
and:
what happens when a payment currently fails.
For an established recurring portfolio, transaction data can help us identify whether the problem is primarily:
payment configuration + failed-payment recovery + gateway functionality + acquiring performance + stored credentials
before assuming that you simply need a new provider.
This article provides general payment information and is not legal, regulatory or PCI DSS advice. Recurring-payment configuration, card-scheme requirements and provider functionality vary.
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.
