Products

Service

Online payments

Drive sales across desktops, smartphones and in-app.

Payment gateway

Safe and secure payment gateway.

Full stack payments

All-in-one payment solution with payment gateway and acquiring.

Products

Payment Links

Accept payments using a secure online link.

Fraud prevention

Detect and prevent fraudulent activity.

Authentication

Provide secure and seamless customer authentication.

Featured news

Understanding Incremental Authorisation in payments
Read more
Best practices for implementing 3DS2: Keeping your online payments secure
Read more
See all articles
Solutions

Industries

Mobility

Drive growth with our all-in-one payment solution.

Hospitality

Delight your customers with quick and simple checkouts.

Consumer finance

Seamlessly integrate payments into your finance business.

Healthcare

Flexible, secure payments for clinics, pharmacies & care providers.

Stage

SME

Seamless payment solutions for small and medium businesses.

Featured content

How Apple Wallet is transforming the hospitality experience.
Read more
7 steps for making your small business greener.
Read more
See all articles
About

About

We are the leading mobile payments solution. A part of Fabrick's open finance ecosystem, we provide flexible, secure and innovative payments for a range of different business.

Company

About

Learn more about Judopay.

Customer stories

Discover how we work with our clients.

Careers

Join the team.

Featured news

An interview with KFC

Digital transformation is coming.

Read more
Case study: Remitec

A proactive partnership to support strategic growth.

Read more
See all articles
Developer

Documentation

Developer Docs

Start your payment integration.

Quick Start

Quickly integrate and perform a test payment.

API Reference

Details on all available endpoints.

Sandbox Account

Sign up for an account to process test transactions.

Resources

Video Tutorials

Step-by-step tutorials.

Changelog

Latest updates to our Transaction API.

Status Page

The status of all of our services.

Support Centre

Help & support for Judopay customers.

Developer hub

Payment Services Directive 3 - An Evolution: not a Revolution...
Read more
Creating a data analytics powerhouse.
Read more
PartnersPricingBlog
SupportLoginGet in touch

What are “Exemptions for Strong Customer Authentication”?

What are SCA exemptions?

As you may know, from 14th March ‘22 in the UK (and since December ‘20 in most of Europe) online payments have to be compliant with Strong Customer Authentication (or SCA for short). Need a quick recap on SCA? Visit this page.

But, as with most regulations there are exceptions and in this case they’re called “SCA Exemptions”.

SCA exemptions are several different payment types which can be exempt from SCA or are out-of-scope; meaning your customers won’t have to experience the additional authentication when paying. 

What are the exemptions? How do I enable them?

Keep reading…

‍

Small caveat to start: The easiest way to comply with SCA is by enabling something called 3D Secure 2 on your transactions. When this is in place you’ll benefit from what’s called a “liability shift” on your transactions. Which means, should fraud occur, the bank (as opposed to you) will be liable to cover the costs as they authorised the transaction. Putting SCA exemptions in place moves this “liability shift” back to you, the business. So, it’s important you discuss with us whether adding an exemption is worth losing this liability shift.

‍

What are the exemptions?

The following transaction types are exempt or out-of-scope for SCA. 

Exempt = you can choose to tell the card Issuer that you want these transaction types to be exempt from SCA (bearing in mind the liability shift mentioned above).

Out-of-scope = these transactions won’t be checked by the card Issuer for compliance with SCA if you send data with the transaction that shows that they’re out-of-scope (more on that below). 

Note - SCA is an evolving regulation so exemptions may be updated, get in touch if you have any questions.

‍

#1 Merchant-initiated transactions (MIT) / Recurring payments (out-of-scope).

‍An MIT is a payment that is initiated by the merchant at a later date with the consumer’s consent i.e. where a cardholder has pre-agreed (and pre-authenticated) a future transaction/s but may not be available to authenticate the payment when it is initiated.

Some examples:

  1. Recurring payments (e.g. you may set up a fixed, regular payment for a gym membership)
  2. Delayed charges (e.g. a hotel may charge you a fee for a late check-out)
  3. Taxi fare increases (e.g. a taxi may need to charge more than originally estimated for a fare if the destination changes, journey takes longer etc.)
  4. No shows (e.g. a restaurant may charge your card a small fee if you fail to show up for a booking)

MITs need to be correctly tagged in order to let the card Issuers know they’re out-of-scope from SCA. More details on correctly setting up MIT transactions are available here.

Note - SCA should be applied where a customer initiates any agreement/authorisation for future MITs (e.g. recurring, subscription, unscheduled card on file transactions etc.) For example, the customer will be expected to go through SCA when initially adding their card, so that all future transactions can be MITs (meaning future transactions can be processed by the merchant, without any input needed from the customer).

‍

#2 Low-value payments (exempt).

Low value payments are those under £45 (or €50). This is useful if you’re selling products or services that are typically low-value. But if you tend to struggle with fraud you should weigh up whether it's worth removing the liability shift you get from 3DS2. If in doubt, get in touch.

Note - This exemption takes place until the customer makes more than 5 exempt payments in a row, at which point the card Issuer will require the transaction to be authenticated, just to check it definitely is the cardholder making the purchase.

‍

#3 ‘Whitelisted’ eCommerce websites / Trusted beneficiaries (exempt).

Customers will be able to select online shopping sites they trust and regularly use. Which means, SCA will only be required when they make a first purchase. 

For example:

- Consumers doing their weekly food shop could select that they trust this website and SCA will only be required to authenticate the transaction during their first shop. 

How does this work? When making a payment on a website there may be a checkbox that gives the consumer the option of adding the business to their personal whitelist. The consumer will need to go through SCA in order to add the website to this whitelist but, the next time that they use that website their purchase will be exempt from SCA. 

‍

#4 Mail orders & Telephone orders (MOTO) (out-of-scope).

SCA only applies to online payments. As MOTO transactions are not classed as electronic payments they are out-of-scope of SCA. 

‍

#5 Low risk payments / Transaction risk analysis (TRA) (exempt).

Certain transactions can be exempt from SCA, provided they are low risk and below target fraud thresholds. 

‍

#6 Direct debits (out-of-scope).

Payments that are initiated by merchants (such as subscription payments) typically require SCA on the first payment, but with direct debits this isn’t the case as you create a standing order; giving the merchant permission to take funds directly from your bank account. 

For example: 

- Monthly household bills. 

How is this different from recurring payments? Direct debits are standing orders set up using your bank account details, whereas recurring payments are set up using card details. 

‍

#7 Corporate payments (exempt).

Payments made between 2 corporate companies can also be exempt from SCA if the payment is made using a dedicated B2B payment method e.g. a company travel booking platform, internal purchasing system etc.

Note - company cards issued to employees for expenses do not fall under this exemption. 

‍

What should you do next?

If you process any of the above payments and would like to ensure that they’re out-of-scope or are considering using exemption flags, get in touch. There may need to be some technical work to ensure this, or you’ll need to consider whether it’s worth losing your liability shift from 3DS2 to add an exemption.

Recent posts.

Product

Mobility taxi image for payments

Understanding Incremental Authorisation in payments

Read morePurple background blob

Insights

Judopay and Mobo2Go case study imageTeal background blob

‍7 steps for making your small business greener

Read more

Insights

Strong Customer AuthenticationPink background blob

Take your business to the next level with our payment tips.

Read more
Trustpilot

Company

AboutCareersBecome a partnerGet in touch

Products

Online paymentsMobile paymentsPayment linksGateway onlyFraud protection

Solutions

MobilityHospitalityConsumer financeHealthcare

Resources

BlogDocumentationSupport CentrePress & MediaStatus pageLegal hub
© Judopay 2025.
Service AgreementTerms & conditionsCookie policyPrivacy policyCertificates
Alternative Payments Limited (Company Number 07959933) t/a Judopay is wholly owned by Fabrick S.p.A., part of the Banca Sella Group.