Recurring Payment Processing: A Comprehensive Guide

Recurring Card Payments: How to Charge a Customer Again Correctly

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:

• What the customer actually agreed to
• Whether the card credential is being stored
• Who initiates the later payment
• Whether the amount is fixed or variable
• Whether payments happen to a fixed schedule
• How the transaction is identified to the payment provider
• Strong Customer Authentication
• What happens if a payment fails
• What happens when a customer's card changes
• How the customer cancels
• What happens after cancellation

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.

Find Your New Processor

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.

Quick answer: Can a business charge a customer's card again?

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:

• Fixed amount
• Variable amount
• Fixed dates
• Variable timing

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.

---

First: what exactly is a recurring card payment?

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:

• Continuous Payment Authorities
• CPAs
• Recurring transactions
• Recurring card payments

The FCA uses recurring card payment and Continuous Payment Authority when explaining the arrangement to consumers. 

---

Recurring payment does not simply mean “saved card”

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.

---

Find Your New Processor

CIT and MIT: two terms businesses taking recurring payments should understand

Payment providers increasingly talk about:

CIT

and:

MIT

Understanding the difference helps explain how recurring payments actually work.

Customer-Initiated Transaction — CIT

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:

• Newly entered card details
• A previously stored card
• A digital wallet

The fact that the card was stored doesn't necessarily change the fact that the customer initiated the payment.

Merchant-Initiated Transaction — MIT

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. 

---

MAS insight: Who clicked “pay” is an important question

Consider these two £100 transactions.

Transaction A

Customer logs into their account, selects an invoice and presses:

Pay £100 using saved card

Transaction B

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:

• Authenticated
• Submitted
• Identified
• Retried
• Analysed

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?

---

Find Your New Processor

How a recurring card payment should work

A simplified journey looks like this.

1. Customer agrees to the arrangement

For example:

£39 per month until cancelled

or:

Variable monthly payment based on usage, calculated according to the terms explained here.

2. Customer provides their card

Usually through a secure checkout or payment page.

3. The initial arrangement is established

The payment provider records the appropriate information that allows the stored credential to be used for future payments.

4. Card details are stored appropriately

In modern setups, this commonly involves tokenisation rather than the merchant keeping raw card information itself.

5. Future payment becomes due

For example:

1 August — £39

6. Merchant initiates the subsequent payment

The stored credential/token is used in accordance with the existing agreement.

7. Issuer authorises or declines it

Successful:

subscription/member/account remains paid

Failed:

payment-recovery process begins

That final stage is where a lot of businesses lose revenue unnecessarily.

---

Customer consent is the foundation

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:

• What they are buying
• Amount or how it will be calculated
• Frequency
• When charging begins
• Whether it automatically renews
• How to cancel
• What happens if the price changes

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?

---

Can recurring payments be for different amounts?

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:

• Usage
• Consumption
• Number of users
• Work completed
• Variable membership charges
• Other agreed calculations

But the more variable the arrangement becomes, the more important it is that the customer understands what they have authorised.

---

Find Your New Processor

Fixed recurring payments and variable merchant-initiated payments are not technically identical

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?”

---

What if the recurring price changes?

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.

Contract/customer-consent question

Does the agreement allow the price change and has it been communicated appropriately?

Payment question

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.

---

Does every recurring payment need 3D Secure?

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.

---

The first payment matters

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.

---

Can I keep the customer's actual card number?

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.

---

Can I store the customer's CVV for the next payment?

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.

---

MAS insight: If your recurring system asks you to keep CVVs, stop and investigate

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.

---

Why can a recurring payment continue after the customer gets a new card?

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:

• Account updating
• Token updating
• Network-token functionality

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.

---

Find Your New Processor

A replacement card is not the same as customer cancellation

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.

---

How does a customer cancel a recurring card payment?

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.

---

Cancelling the recurring payment is not necessarily cancelling the contract

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:

• Memberships
• Service contracts
• Instalment arrangements
• Consumer agreements

Payment teams and customer-service teams should understand the difference.

---

What if the business takes another payment after cancellation?

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.

---

MAS insight: Cancellation is a payment-system event

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.

---

Find Your New Processor

What happens when a recurring payment fails?

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:

• Expired
• Been replaced
• Reached a temporary limit
• Been blocked
• Experienced an issuer problem

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.

---

Should you retry a failed recurring payment?

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.

---

A better failed-payment journey

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.

---

Should you retry at 9am, midnight or payday?

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:

• Issuer advice
• Decline reason
• Provider rules
• Customer agreement
• Previous attempts
• Customer communication

For some regulated sectors, further restrictions apply.

---

Find Your New Processor

Recurring payments for loans and regulated consumer credit are a special case

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:

• How the CPA will be used
• How it can be cancelled
• Whether further collection attempts may occur
• The basis and frequency of further attempts

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.

---

MAS insight: Failed recurring payments should have their own reporting

Many businesses report:

Card approval rate: 92%.

That can hide the interesting information.

For a recurring business, measure separately:

First-payment approval rate

How many customers successfully establish the payment relationship?

First-attempt renewal approval

How many subsequent payments work immediately?

Recovered-payment rate

How many initial failures are later legitimately recovered?

Final failed-payment value

How much revenue remains uncollected?

Cancellation after failed payment

How many customers actually leave?

That gives a much clearer picture of recurring-payment performance.

---

Measure the value of failed recurring payments, not just the percentage

Imagine two businesses both have a:

5% recurring-payment failure rate.

Business A

5% represents:

£2,000 per month

Business B

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.

---

Find Your New Processor

Recurring payments versus subscriptions

These terms are often used interchangeably, but there is a useful distinction.

Recurring payment

The payment mechanism that allows future charges to happen.

Subscription

The wider commercial relationship.

A subscription system might need to manage:

• Plans
• Free trials
• Upgrades
• Downgrades
• Proration
• Renewal periods
• Customer access
• Cancellation

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.

---

Recurring payments versus instalments

These should also be distinguished.

Recurring arrangement

Potentially ongoing.

For example:

£30 every month until cancelled.

Instalment plan

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:

• Furniture
• Travel
• Professional services
• Education
• Higher-value purchases

---

Recurring card payment versus Direct Debit

They can produce a similar customer experience:

money is collected automatically

but the underlying payment mechanisms are different.

The FCA specifically notes that recurring card payments are not covered by the Direct Debit Guarantee. 

The right method depends on the business.

---

Find Your New Processor

Card or Direct Debit for recurring payments?

There isn't one universal answer.

Cards can work particularly well where:

• Activation needs to be immediate
• Customers are international
• The business already has card checkout
• Credit cards are relevant
• Customer onboarding is digital

Direct Debit can work particularly well where:

• Payments are primarily UK bank-account based
• Customer relationships are long term
• Amounts are predictable
• Card expiry is undesirable

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.

---

What about Variable Recurring Payments through Open Banking?

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).

---

What if a customer wants to pay manually every month using their saved card?

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.

---

What about an unpaid invoice collected from a saved card?

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.

---

Find Your New Processor

MAS insight: A token is a technical permission, not necessarily a contractual permission

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.

---

How should customers update a failed or expired card?

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:

• Email card numbers
• Send card details through ordinary messaging
• Provide payment-card data insecurely

A hosted payment page can create a much cleaner recovery process.

MAS covers these payment journeys in our guide to Payment Links for Business.

---

What happens if a card is stolen or replaced?

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.

---

Find Your New Processor

Switching payment provider when you have recurring customers

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:

• Failed renewals
• Customer friction
• Revenue loss
• Support calls
• Churn

For recurring merchants, token migration can be more important than headline pricing.

---

Questions to ask before moving recurring payments

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.

---

MAS insight: Never discover token portability after you've signed

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.

---

The recurring payment metrics larger merchants should know

For a substantial recurring portfolio, MAS would want to see more than processing rates.

Active recurring credentials

How many customers are actually being charged?

Monthly attempted recurring value

How much money should be collected?

First-attempt approval rate

What proportion succeeds immediately?

Decline reasons

Why are payments failing?

Recovery rate

How much failed value is subsequently recovered?

Final payment loss

What remains unpaid?

Card-update performance

How often are expired/replaced cards recovered without customer intervention?

Customer update success

How many customers successfully update their details after contact?

Chargebacks

Are customers disputing recurring transactions?

Cancellation-related disputes

Are payments being taken after customers believe they cancelled?

Those metrics tell you considerably more about the quality of the recurring setup.

---

Processing £250k+ per month in recurring card payments?

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.

---

MAS insight: Recurring businesses should know their payment waterfall

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%.”

---

Find Your New Processor

When should a recurring-payment business review its provider?

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:

• Recurring volumes have grown significantly
• Renewal approval is deteriorating
• Too many payments require customer card updates
• Retry tools are poor
• Reporting is inadequate
• Tokenisation is outdated
• International customers have grown
• Current tokens are difficult to migrate
• Chargebacks are increasing
• Payment costs have risen
• Existing gateway no longer fits the wider system

The trigger should be evidence, not an arbitrary calendar date.

---

Choosing a recurring-payment provider

The useful questions are not simply:

“How much per transaction?”

Ask:

How is the initial recurring relationship established?

How are credentials tokenised?

Are subsequent transactions correctly identified?

Does it support both fixed and variable charging models?

What happens when the amount changes?

What decline information is returned?

Can the business act on issuer advice?

What retry tools are available?

Does it provide account/card updating?

Are network tokens available?

How does a customer update their payment method?

How easy is cancellation to implement?

What recurring-payment reporting exists?

Can tokens be migrated if we leave?

What happens to existing recurring relationships during a gateway migration?

For a recurring business, those questions may ultimately be more valuable than a slightly lower headline processing fee.

---

How Merchant Advice Service helps recurring-payment businesses

MAS can look at both new recurring-payment requirements and existing portfolios where payment performance needs reviewing.

Setting up recurring card payments

We can consider:

• Business model
• Fixed or variable payments
• Frequency
• Customer type
• Gateway requirements
• Integration

Existing recurring portfolios

For established businesses, useful information can include:

• Monthly recurring volume
• Active customers
• First-attempt approval
• Decline data
• Recovery rate
• Chargebacks

Failed recurring payments

Rather than simply changing provider, the first step is understanding why the payments are failing.

Moving away from MOTO/manual collection

Where customers repeatedly telephone to make the same payment, there may be a more appropriate recurring or customer-entered digital journey.

Switching gateway/acquirer

Token portability and migration should be established before the replacement provider is selected.

Complex recurring requirements

This can include:

• Variable amounts
• International customers
• Multiple currencies
• Higher-risk sectors
• Larger recurring portfolios
• Complex integrations

Final acceptance, transaction configuration and underwriting remain with the relevant payment provider.

---

Find Your New Processor

Having problems with recurring card payments?

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.

Sources and regulatory references

• Financial Conduct Authority — Recurring card payments
  FCA guidance covering Continuous Payment Authorities, consent, cancellation, variable payments and replacement cards.
• FCA Handbook — Strong Customer Authentication: Recurring Transactions
  UK technical standards covering SCA when a fixed recurring-payment series is created, amended or first initiated.
• FCA Handbook — Consumer Credit and Continuous Payment Authorities
  Relevant where recurring card payments are used to collect payments under regulated consumer-credit agreements.
• PCI Security Standards Council — Tokenisation and stored credentials
  PCI SSC guidance on the use of tokens for card-on-file and recurring transactions.
• PCI Security Standards Council — Can CVV/CVC be stored for recurring payments?
  PCI SSC guidance confirming that card verification codes cannot be stored after authorisation for future recurring transactions.
• Mastercard — Transaction Processing Rules
  Mastercard rules covering recurring payments, instalments, stored credentials and issuer advice relating to declined recurring transactions.
• European Union — Strong Customer Authentication Regulatory Technical Standards
  EU rules covering Strong Customer Authentication, including the treatment of recurring transactions under Article 14.

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.

---