
Contact us
If you would like us to contact you to discuss your payments needs, please complete this form. We’ll get in touch with you using the phone number and email address provided, to design and create the right payments solution for you.
*Required fields
Thank you for getting in touch. We will be in contact with you within 48 hours.To go back to our website, please click here.
Close
Contact us
If you would like us to contact you to discuss your payments needs, please complete this form. We’ll get in touch with you using the phone number and email address provided, to design and create the right payments solution for you.
Contact us
If you would like us to contact you to discuss your payments needs, please complete this form. We’ll get in touch with you using the phone number and email address provided, to design and create the right payments solution for you.
Business growth takes hard work, ambition and expertise. So, while you focus on your goals, you’ll need a payment partner you can trust.
As a small business, choosing a payment partner is one of the most important decisions you’ll ever make. We’re trusted by thousands of businesses across the UK.
We handle payments for large corporate businesses on a global scale, serving over 1.3 million customers in over 30 countries and handling over 5.6 billion transactions annually.
If you’re ready to unlock your online potential, we’ll help you create the payments experience your customers expect - helping you reach markets across the world.
If your business is ready to grow, don’t let payments slow you down. Explore our range of scalable payments solutions, ready to support your business as it expands.
Your customers want payments to be simple, reliable and secure. Switch to a provider who can deliver wherever and however a transaction takes place. Learn more here.
Wherever and however your business operates, give your customers a payment solution that goes beyond their expectations.
As an industry-leading provider, we help you deliver the exceptional payment experience your customers look for, every time they shop with you.
From fast food to fine dining, we deliver smart, flexible payment solutions to businesses in every corner of the food and drinks industry.
Simplicity, security and convenience: give your guests a payment experience that enhances their time with you.
Government agencies, universities, utilities and other public-sector entities can tailor our payment solutions to their precise needs.
Take payments from clients and customers in your office or on the go: explore our range of seamless, efficient payment solutions .
For over 30 years, we’ve worked side-by-side with airlines to deliver payment solutions for customers around the world. Learn how we can help you.
Give your customers the choice to pay however they want. Online, in person, in-app or over the phone: we've got you covered with simple solutions and integrated options.
Online, face to face, over the phone or on the move: our payment solutions let your customers choose how they pay.
Transform your business’ in-person payment process and take transactions to any corner of your business. Accept all major card, contactless and mobile-wallet payments.
Our on-the-go solutions give you the freedom and versatility to take payments almost anywhere - and give your customers the seamless experience they expect.
Serve your customers making payments by phone or by mail with our Virtual Terminal. No specialised knowledge to install or operate.
Our data-security products not only protect customer payment data, but help to deliver valuable customer confidence and increase brand appeal.
Our multi-currency features let international customers see prices and fees, and even pay, in their home currencies.
We build payment partnerships with banks, financial institutions, ISOs, software vendors and payment gateways in every corner of the world.
Over 550 financial institutions around the world partner with Elavon to deliver fast, reliable payment solutions that customers trust.
We’ve worked with ISO partners for over 15 years, delivering the payments solutions their customers need in a diverse commercial landscape.
We build our IPS to handle the challenges of an evolving payments landscape, and help our partners around the world meet their customers’ changing needs.
approval rates
faster checkout
reduction in shopping cart abandonment
in chargeback fraud
The deadline for PSD2 implementation remains at the 31 December 2020 for the EU and 14 September 2021 for the UK. The good news is our early adopters have experienced significantly improved performance when using 3-D Secure V2 with increased approval rates, faster checkouts and transaction speeds, and a significant reduction in shopping cart abandonment and fraud.
This is echoed by card schemes who have also seen the benefits from 3-D Secure V2. Don’t forget the other benefits of 3-D Secure;
UK Deadline 14 September 2021
Qualifying criteria based on 3-D Secure V2.X usage.
Approval and fraud rate based on Elavon customer’s transaction analysis 2020. Up to 85% faster checkout and up to 70% reduction in shopping cart abandonment when a risk-based authentication flow is used with 3-D Secure, Visa 2020.
Card Brand Compliance associated with Strong Customer Authentication
To support the roll-out of EMV 3D Secure technology, there will be programmes throughout 2020 to help with the compliance of card brands - such as Visa and Mastercard. These are to make sure that all eCommerce payments processed in the European Economic Area meet the required Strong Customer Authentication (SCA) by 31 December 2020, as part of the Payment Services Directive 2 (PSD2). SCA aims to drive down fraud and improve confidence in card payments, allowing that growing sector to continue to flourish.
It is vital you actively manage your PSD2 compliance and monitor timelines for implementation. You must have plans in place to operate to the highest version available of EMV 3D Secure. Card brand schemes, acquirers and gateways may well impose earlier deadlines to progress changes in good time to meet the official deadline.
Act now to gain certification and avoid penalties. For example transactions at devices with no Chip and PIN capability [Magnetic swipe] and those that are completed by manually entering the card details when the cardholder is present [Pan Key Entry] will incur fees for the use of these less secure payment methods in card present environments - whether excluded from the scope of PSD2 or not, i.e. Transit. There is cost associated with the introduction of PSD2, but the greatest cost will be loss of sales, as failure to comply will result in declined transactions.
Don’t forget the additional benefits to EMV 3D Secure: such as improved security, wider interoperability and flexibility to enable innovation, fewer barriers to market and greater choice to the consumer.
We will provide further updates on the impact to your business in our monthly Card Scheme Changes bulletin, and within our series of PSD2 updates. To discuss how you can mitigate those fees and amend your strategy to take best advantage of the changes, talk to us today.
The European Banking Authority (EBA) has announced today that the period for the implementation of Strong Customer Authentication (SCA) under Payment Services Directive (PSD2) will be 15 months, from the 14 September 2019. Strong Customer Authentication (SCA) must be applied to all electronic payments within the European Economic Area (EEA) by 31 December 2020.
The EBA have acknowledged the complexity and challenges in the payments environment in Europe. To help manage the difficulties the EBA have granted flexibility to the National Competent Authorities (NCAs). The additional time is needed to ensure that all the stakeholders in the ecosystem; banks, acquirers, gateway providers and merchants equip themselves with the relevant tools to fully implement PSD2. They must deliver on time and minimise impact to consumers.
During the extension period, the EBA and the European Commission (EC) will be particularly vigilant in monitoring the implementation of the directive. All players including NCAs must participate fully and assume all their supervisory responsibilities. Each player must produce and execute their migration plans in an expedited manner.
Elavon has advocated for a pan-European migration plan that is consistent, harmonised and effective across all member states. However, several NCAs have taken different approaches to date, so there is a risk of differences in implementation. If that happens, it could be difficult, expensive and time-consuming for merchants and payment providers to customise their solutions
At Elavon we will be working with the relevant NCAs to complete our migration plan. We are intensifying our communications and knowledge sharing with customers and partners.
We are pleased to report very little disruption with the introduction of PSD2 SCA. This announcement by the EBA means that NCAs will not take any enforcement actions against any impacted entities, provided the entities are executing on their migration plan and meeting each of their individual milestones.
Our aim is to enable you to carry out SCA to meet the regulations with the acceptance of 3D Secure V2 via our upgraded platforms. To deliver a smooth transition, we actively engage with all our partners and gateway providers that connect to our acquiring platform.
Meeting PSD2 SCA obligations is our top priority. Our team of experts are ready to help you optimise your customers’ experience while avoiding payment declines and lost sales.
This is a one-time implementation window and will not be extended beyond 31 December 2020.
Avail of this limited time to ensure that your eCommerce payments are ready to be authenticated using 3D Secure V2. If you have 3D Secure V1 in place, upgrade to 3D Secure V2. This is a simple upgrade and your payment gateway provider will assist you with the details.
If you have not used 3D Secure before, it might involve more work for you or your developer. Do not delay, it is important that you speak with your gateway provider or web developer to understand what is involved.
We will continue to share further details with you as we receive and digest them. In the meantime, if you have any questions relating to the above, please speak with your Relationship Manager or our customer services team.
Have you ever wondered why MIT is always COF, but not all COF is MIT, and that you don’t need either if you do CIT, but if you do want to COF and MIT you will need a CIT first anyway?
Probably Not. You have better things to do. But your customers will love your business for knowing the difference.
We’re going to break it all down for you so that you can play your part in ensuring a frictionless payments flow for your customers while at the same time putting you in control of where the liability sits in the event of fraud. If you want to minimise the impacts of PSD2 SCA regulation soon to come into force across Europe, it’s going to be worth your while understanding these concepts and making sure that all of your customer payment pathways are compliant with the card scheme frameworks and the fast approaching enforcement of PSD2 SCA regulations[i].
The new security regulations being introduced across Europe are aimed at reducing growing fraud by introducing Strong Customer Authentication (SCA), particularly in the virtual or e-commerce environment. SCA is already enabled in most physical POS systems across Europe via the use of Chip & PIN transactions. It has proven extremely effective in reducing common fraud scenarios.
That same level of cardholder and merchant security delivered by Chip & PIN in the physical space is now being mandated in the remote e-commerce channels. It is inevitable that with the benefits of increased security requirements, there is often a risk of smooth customer payment processes being threatened by the introduction of friction. We all want our customer payment experiences to be as frictionless as possible, avoiding card abandonment, increasing transaction approval rates and optimising sales while at the same time protecting the payments environment and ourselves, as both consumers and merchants, from fraudsters.
Remember that exceptions to, and exemptions from the need to perform SCA are available only in limited and strictly controlled circumstances. Otherwise, by law Issuers will now be required to challenge (step-up) all electronic transactions to SCA that arrive for authorisation approval but without proof that authentication has previously taken place.
The use of the transaction frameworks we are about to describe are going to be key to your ability to continue to provide those frictionless flows that we enjoy today, securely, well into the future and all in compliance the European laws, the card scheme rules and your obligations as a user of the payment systems networks that support your business.
SCA fundamentals are well documented elsewhere on this website but just a few key reminders will help you to navigate your options as you consider implementing any of the customer engagement and payment transaction frameworks.
You’re going to have choices to make about:
The payment transaction concepts are quite simple. However, the implementation of the framework can be a challenge as each card brand has a slightly different set of transaction types, guidance and requirements and the terminology varies a little between schemes, so let’s start by getting things defined for you.
This refers to any transaction where the cardholder actively participates in the transaction as it happens. We’re calling that ‘in-session’ and it applies to both Cardholder Present (Chip & PIN in your POS terminal) and Cardholder Not Present transactions (shopping on-line via web or app).
As per the key PSD2 SCA principles above, the cardholder is ‘in-session’ and must be authenticated, issuer approvals shift the fraud liability away from you. Typically a friction flow but frictionless flow can be enabled at Issuer discretion.
Also known as Card on File, this refers to any transaction where the cardholder has previously stored their payment card credentials with you for ease of use in future transactions. Once a COF transaction has been performed, any future CIT transactions can use this COF framework to simplify the payment experience. The cardholder can inform you to ‘Use my saved details’ and avoid re-entering payment information for subsequent purchases. COF alone doesn’t determine liability shift. Frictionless flow may or may not be available. This is because COF can be used for both CIT and MIT transactions and it’s this latter type that reveals the real benefit of COF enablement - it enables MITs to be performed when the cardholder is not actively participating in future transactions.
This refers to any transaction where the cardholder does NOT actively participate in the transaction, but is allowing you to generate transactions on their behalf via a prior consent agreement with you.
As per key PSD2 SCA principles, the cardholder is not ‘in-session’, cannot be authenticated again in real time, issuer approvals will shift fraud liability towards you. Frictionless flow results.
MIT transactions are only generated by the merchant, without the cardholder ‘in-session’ therefore if SCA is applied to these transactions it will fail. With no cardholder available to authenticate, these transaction types are one of the few considered to be Out Of Scope of the PSD2 SCA regulations.
Be warned. There are strict rules around the use of each transaction type and failure to follow the set-up requirements of each, as well as correctly flag your transactions for the same WILL result in transactions being declined or abandoned, ultimately leading to lost sales.
MIT transactions can only be used where an initial CIT has taken place (authenticating the cardholder and enabling COF in the first instance) and then using those credentials and the cardholder’s prior agreement via T&C’s to establish an MIT agreement with their Card Issuing bank. In all cases, a MIT must refer to the cardholder’s original interaction and authentication results. Each subsequent MIT submitted will be indicating to the card Issuer that the authentication process has already been completed and that this transaction is just a further MIT in a previously agreed, authenticated and approved series.
Without doubt, merchants of all shapes and sizes can benefit from the convenience of enabling COF capability for your customers to generate loyalty and simplify payments. COF can be used when the cardholder is ‘in-session’ (CIT) or not ‘in-session’ (MIT).
The combined approaches of using CIT, COF and MIT provides for a generous mix of transaction and consumer journey types across a wide range of merchant types and payment processes, all compliant with PSD2 SCA regulations - provided that the required MIT frameworks are established, transactions are correctly flagged to Issuers, and that cardholder consents are obtained.
The MIT framework varies slightly between card brands but it is comprehensive, catering for a wide range of transaction processing scenarios. Categories of common ‘standing instruction’ MITs are available to enable recurring payments, instalment transactions and unscheduled COF events and journeys.
Also defined within the MIT framework are several ‘industry-specific’ MITs which enable merchants to fulfil a new or existing business practice – following up to an original cardholder interaction that could not be completed in one single transaction. Your options here will include incremental authorisations, re-submissions, re-authorisations, applying delayed and ‘No Show’ charges according to your cancellation policies.
The MIT transaction framework is relevant to all forms of e-commerce but is particularly important to the travel and hospitality sector which relies upon the need to post charges to cardholder accounts before, during and after the provision of goods and services, typically when the cardholder is no longer ‘in-session’. These concepts are fundamental to this sector so next month we will focus our post on this topic in more detail.
For now, here a just few potential transaction use-cases where the application of CIT, COF and MIT can be used to create a frictionless flow and maintain compliance with the regulations:
Strict enforcement of PSD2 SCA regulation will be matched by equally strong card brand regulation, monitoring the correct use of MITs and other Out Of Scope exceptions and exemptions to SCA. Ensuring that transaction frameworks are correctly established in the first place requires business procedures as well as technology alignment to guarantee Issuer acceptance and approvals.
Incorrect establishment of agreements, incorrect flagging of effective transactions or miss-use of the framework in any way will result in transaction declines and lost sales.
Merchants offering cardholders the opportunity to store their credentials on file must obtain the cardholder's consent, therefore you will need to establish and maintain an agreement (T&C’s).
Enabling Merchant initiated Transactions depends upon many of the same consent and cardholder disclosures that are required under COF, which is always a pre-requisite to processing a MIT.
The MIT framework was designed to provide Card Issuers (both authenticator and approver) with more transaction context enabling them to make better informed decisions and minimise unnecessary declines.
The framework allows Issuers to identity the intent of the MIT through the use of appropriate identifiers (message reason codes). Use of the framework also provides a proof of a preceding transaction by creating a linkage with it using a unique (Transaction Identifier) of the previous or original transaction.
Merchants must link the MIT with the original transaction using a unique Transaction Identifier that was generated for the original CIT. For certain MIT types, (recurring, instalment and unscheduled COF which are all also known as ‘standing instruction’ MITs.) the Transaction Identifier generated for the previous transaction in the series can be used to link the subsequent transaction.
COF and MIT processing fundamentals – establishing frameworks
COF – when capturing a stored credential for the first time, in addition to the business processing requirements already listed, merchants will need to:
So now we can go back and answer the questions in the very first sentence of this post.
MIT is always COF – For you to be able to generate a payment transaction when the cardholder is not in session (MIT), you’re going to need the cardholder details to have been stored beforehand (COF). The cardholder cannot be authenticated because they are not ‘in session’
Not all COF are MIT – If the cardholder visits your store in person or on-line, they can ask you to use their stored details (COF). This in not MIT (no authentication required) but instead CIT (authentication must be performed as the cardholder is ‘in session’).
You don’t need either if you do CIT – by definition, if you are not using stored credentials (COF), you can’t initiate the transaction yourself (MIT), so the cardholder will have to be ‘in-session’ and authenticated each time (CIT)
But if you do want to COF and MIT you will need a CIT first anyway? – SCA is mandatory whenever a credential is first stored in your systems (COF), and also MIT agreements can only be established after a successful authentication on the very first transaction in a series. The only way that the initial authentication can take place is when the cardholder is ‘in-session’ (CIT).
The accurate use of COF and the MIT framework is key to minimising friction, avoiding declines and being in compliance with the incoming PSD2 SCA regulations.
Many of you will already be using these frameworks as they are already well established by some of the card brands. Their accurate usage and importance is now more relevant than ever as these frameworks will be essential processes to deal with the incoming regulations.
Now is the time to re-visit your payment flows to ensure that you are correctly identifying, flagging and processing these transaction types well ahead of the PD2 SCA enforcement dates in your market.
Incorrectly flagged transactions or those that do not conform to the framework rules will be declined or stepped-up to 3DS when the cardholder is no longer ‘in-session’ – either way the results will be transaction failure and lost sales.
Due to their relative importance to the Travel & Hospitality sector, next month we will be diving deeper into the MIT framework. The use of indirect booking channels brings with it new challenges for this sector where previously unengaged players like 3rd party booking engines will now need to be integrated more closely to the authentication and authorisation flows. Proof of Authentication needs to be added to each MIT submission and once again, MIT will be a pivotal success factor in your ability to continue providing frictionless flows for your customers.
Meanwhile, please continue to communicate and align closely with your PSP/Gateway/Acquirer who will be able to advise you of the processing possibilities and options available to you within the card brand guidelines for MIT and under the regulation of PSD2 SCA.
[i] The deadline for eCommerce compliance is 31 December 2020 in Europe and 14 September 2021 in the UK.
The 3-D Secure 2 (3DS 2) standard is the global benchmark of card-not-present data authentication. Our upgraded payment solutions use 3DS V2 to protect your eCommerce transactions: verify identities and payment information in a seamless security process that reduces friction and liability, without compromising the customer experience.
Stay ahead of compliance
Implement 3DS V2 to keep your eCommerce solution at the cutting edge of payment security, reducing fraud and enhancing legislative compliance.
Prepare your business for incoming regulations: 3DS V2 delivers compliance with the Strong Customer Authentication (SCA) requirement, representing the gold standard of card authentication across Europe.
Customer confidence
3DS V2 promises online customers confidence and peace of mind when they shop with you, without intrusive security precautions.
Building on password and text message security measures, 3DS V2 enables customers to authenticate their online payments via mobile shopping apps, using fingerprint or even facial recognition.
Seamless security
Streamline the online card authentication process for businesses and customers. 3DS V2 transfers more payment data elements to banks more quickly and securely, and incorporates specific contextual information, including device ID and transaction history.
No need for website redirects or excessive customer input: cardholder banks take on compliance responsibility, assessing risk levels and either greenlighting payments or challenging customers for further information.
Benefit from of upgrading to the latest version of EMV 3D Secure
· Increased cardholder confidence when transacting with your business
· Reduced fraud and chargebacks, liability protection
· Prevention of unauthenticated transaction declines
· Improved risk based decisions leading to higher approval rates
· Full support for all available exemption types and payment device types
3DS |
2.1 |
2.1+1 |
2.2 |
---|---|---|---|
SCA for connected devices and web purchase |
|
|
|
Non-payment authentication scenarios, such as payment card on-boarding to merchant apps |
|
|
|
Provides for all available SCA exemption types |
|
|
|
Europe specific scenarios in support of PSD2, such as trusted beneficiary and delegated authentication |
|
|
|
Biometric consumer user experience |
|
|
|
1 2.1+ relates to Mastercard only
How EMV 3D Secure, SCA and PSD2 have changed the liability for fraudulent chargebacks… in most cases.
It used to be the case that merchants were liable for any eCommerce chargeback deemed to be fraudulent. Such as transactions from cards that were stolen, cloned or counterfeit.
However, the widespread adoption of Strong Customer Authentication (SCA), part of the Payment Services Directive 2 (PSD2) changes that you’ve heard so much about means liability for fraudulent chargebacks now shifts to the card issuer – in most cases. There are exceptions!
In the majority of cases, liability shifts to the issuer when:
- The payment is successfully authenticated using 3D Secure protocols and
- The card involved is one of the following: Mastercard, Maestro, Visa, American Express, JCB, Diners Club International and UnionPay.
3D Secure, sometimes referred to as 3DS, provides an additional layer of security for eCommerce transactions prior to authorisation. 3D Secure 2.0 is the new generation of the protocol and is compliant with EU mandates on strong customer authentication.
3D Secure allows more contextual data to be sent to the customer's bank (including mailing addresses and transaction history) to verify and assess the transaction risk.
The cardholder would only be required to complete additional steps to prove their identity if the transaction is determined to be high risk.
In summary, in the majority of circumstances, where your business initiates 3D Secure you will be protected from fraud liability in Europe so long as the issuer authorises the transaction - even if the issuer is unable to support SCA.
As a merchant you will still remain liable for fraud if:
- You do not support 3D Secure
- You use data only - this is where you send the same 3D Secure 2 data to Mastercard, the data is used by Mastercard for risk scoring which they will then send to the issuer as part of the authorisation request. Customers will not be presented with a 3D Secure 2 challenge as no authentication was requested or took place
- PSD2 SCA exemptions are applied (see table below)
- The merchant applies an acquirer exemption through 3D Secure 2 (see table below) where one of the four exemptions are used but no challenge is applied
The table below summarises the liabilities for fraud-related chargebacks and how they apply between the issuer, merchant and the acquirer. These rules are dependent on which payment service provider (PSP) applies an exemption, and whether the transaction is submitted via 3D Secure 2.0.
PSD2 sets out its own principles of liability as a matter of regulation, but does not preclude PSPs from making additional arrangements.
If there are terms in the table you’re unfamiliar with, they’re explained below.
Terminology |
Explanation |
---|---|
Exemption |
Customers who do not need to use two factor authentication to complete the purchase. |
Transaction risk analysis (TRA) |
Is a method that observes all parties to the transaction and their attributes to prevent, detect and block fraudulent behaviour. |
Corporate processes and protocols |
These are payments made through dedicated channels within a company structure, such as lodge cards, central travel accounts and virtual cards). |
Trusted beneficiaries (whitelisting) |
The payer may add a trusted merchant to a list of trusted beneficiaries held by their issuer after the first authentication is completed. Subsequent transactions with the whitelisted merchants are likely to be exempt from future authentication. It should be noted that in order to be compliant with SCA provisions: - Only issuers can create/maintain lists of trusted beneficiaries on behalf of cardholders and use the trusted beneficiaries exemption, although issuers are allowed to outsource or delegate this solution (such as through Visa Trusted Listing). - Only cardholders can add/remove a merchant to/from a list of trusted beneficiaries, or consent to a suggested addition/removal provided by the Issuer. Acquirers cannot apply this exemption and a merchant cannot set up the list for the purpose of the SCA exemption. |
Low value |
Payments below €30* are exempt from SCA. (However, if the exemption has been used five times since the customer’s last successful authentication, or if payments exceed €100*, their bank may request authentication). * or equivalent currency |
Out of scope |
These are transactions not covered by the PSD2 mandate. The issuing bank will not apply any strong authentication and guarantees that shoppers will not be presented with an authentication challenge, unless you specifically ask for 3D Secure in your payment request. |
Merchant initiated transaction (MIT) |
Merchant initiated transactions are payments that are initiated by you, the merchant (not your customer), pursuant to an agreement that you have in place with your customers allowing you to initiate payments on their behalf. |
MOTO |
A 'Mail Order/Telephone Order' transaction. |
One leg out |
A transaction where either the bank or PSP (issuers or acquirers) is located outside the EEA. |
SCA |
Strong Customer Authentication is a requirement that a payer is authenticated by a PSP (payment service provider), through at least two of the following factors: - Knowledge: Something only the payer knows – such as a password. - Possession: Something only the payer has – such as a preregistered mobile phone. - Inherence: Something the payer is – such as a biometric fingerprint or facial recognition. |
SCA required |
Strong customer authentication process is required to complete the transaction. |
PSD2 |
Payment services directive 2, is a European regulation for electronic payment services. It seeks to make payments more secure in Europe. |
CIT |
A customer-initiated transaction. |
CAVV |
Cardholder authentication verification value. This is a unique value generated by the issuer (or by the card scheme on the issuer’s behalf) and is passed on to the acquirer to prove that the transaction has been authenticated. The use of CAVV helps secure the integrity of the 3D Secure transactions by enabling end-to-end traceability. |
TAVV |
Visa’s name for the secure cryptogram generated by the 3D Secure process done with a stored payment token rather than a card number. |
ECI |
The electronic commerce indicator indicates the level of security used when the cardholder provided payment information to the merchant. It must be set to a value corresponding to the authentication results and the characteristics of the merchant checkout process. The merchant commerce server transmits the authorisation request message, including the ECI, to the acquirer or its processor. |
The following are the main exemption categories which can be applied by Elavon and/or the issuer:
Remote transactions up to €30 (or equivalent in other currencies) and contactless transactions up to €50 (or equivalent in other currencies) do not require SCA up to a maximum of five consecutive transactions or a cumulative limit of €100 (€150 for contactless). If the cardholder initiates more than five consecutive low value payments, or if the total payments value exceed €100 (€150 for contactless), SCA will be required. Please note that currently, only Visa and Mastercard have released their requirements to support exemptions. The monitoring of the consecutive transactions and cumulative limits will be the responsibility of the issuer.
Some transaction types are initiated without the cardholder being present or in-session. In these cases, SCA cannot be performed and there are exemptions designed to accommodate these flows. In the case of recurring transactions (same amount) or other customer initiated transactions (variable amount), the initial capture of card details for storing on file must be authenticated using SCA – this results in a unique identifier that is used in subsequent transactions within a series to indicate to issuers that SCA has already been performed. To ensure that these transactions are exempted from
SCA step-up requests, customers and their service providers must ensure that the card scheme MIT
frameworks are followed and that all transactions are appropriately flagged as recurring with reference to the original transaction via the trace/transaction ID value.
Issuers and acquirers’ may use TRA on customer’s partners’ behalf to exempt transactions from the need to have SCA performed. This effectively means that Elavon would analyse the transaction to determine the likelihood of it being genuinely performed by the cardholder and exempt it from 3DS. TRA will be available via two channels. Elavon will offer its own TRA service where Elavon will analyse transactions to determine if the transaction can be exempted from cardholder authentication. In addition Elavon will support TRA conducted by approved third parties. Further details on both services will be made available in due course. The issuer however will always have the final say, so for example, where Elavon were to apply the TRA exemption on our customers/partners’ behalf, the issuer retains the right to require SCA (known as step-up). The rules around TRA exemptions are complex and Elavon can only control how the transaction is handled up until the point that it is sent to the issuer. There are three threshold levels of exceptions – €100, €250 and €500. Elavon will be providing more guidance on TRA in the coming months.
With later levels of 3DS, cardholders will have the option to whitelist’ a business they trust with their card issuer. This means that the cardholder can elect to make a business a‘trusted payee’ and therefore transactions at a ‘whitelisted’ business are to be exempt from future SCA. Whether a cardholder’s elected wishes are upheld is totally the decision of their issuer, as the card issuer may reject the initial request or subsequent exemption requests if it has cause to do so. Furthermore, it is not known at this stage whether issuers will be ready to support whitelisting by 14 September 2019. Elavon are staying very close to developments regarding the Trusted Payee Exemption and will keep our customers/partners’ informed of the latest situation regarding this exemption category as they develop. It should be noted that a business (or their acquirer) cannot elect to be whitelisted themselves, this can only be done between the cardholder and their issuer.
Payments made through dedicated corporate processes and protocols (e.g. lodge cards, central travel accounts and virtual cards) which are initiated by business entities, not available to cardholders and which already offer high levels of protection from fraud may be exempted from SCA. Elavon is working closely with the card schemes to understand the determination of these transactions and will inform customers/partners once it becomes available.
We expect that card issuers may decide to ask for extra confirmation through the use of voice referrals or an immediate refusal of the transaction. The transaction types currently not supporting the SCA functionality that are most at risk are:
References the articles of the Regulatory Technical Standards (RTS) published by the European Bank Authority.
Merchant Initiated Transactions are payments initiated by the customer without the interaction of
the cardholder, for example:
These transactions must be governed by an agreement between the cardholder and customer that, once agreed, allows the customer to initiate subsequent payments without any direct involvement of the cardholder However, SCA should be applied to the first transaction/action mandating the customer to initiate payment.
MOTO transactions are not in scope for SCA, as the customer is not in the flow. However, there is a growing trend of fraud and chargebacks on MOTO transactions, and Elavon strongly recommend trying to find ways of taking transactions via eCommerce – perhaps using a Pay by Link type functionality.
MOTO should only be used where the cardholder details have been provided via mail or phone and is not intended to cover customer present interactions via eCommerce or keyed transactions.
Due to their very nature, payments made through the use of an anonymous payment instrument, such as anonymous prepaid, for example, gift cards, are not subject to the obligation of SCA.
Any payment for transport fares or parking at unattended terminals (e.g. at an airport or train station) will not require SCA.
It may not be possible to apply SCA to a transaction where the Issuer is located outside the EEA1 and is therefore considered out of scope of SCA. SCA should be applied to these transactions on a ‘best effort’ basis.
Since the introduction of PSD2 we have been actively monitoring approval rates to identify any impacts to your business.
We notice that some banks have started to decline or ‘step-up’ contactless payments that require strong customer authentication (SCA). This happens after a customer has made five contactless payments in a row (or once the payments have totaled €150). The card will decline and the customer will be asked to insert their card in the machine and enter their PIN. If the transaction is still declined, advise the cardholder to contact their bank and request another payment method in that instance.
Checkout our ‘Practical Impact Guide for Face to Face’ to assist you through this transition period.