Ready to get started? We are, too.
alt

Sales

Monday - Friday

9:00 AM - 5:30 PM

1800 995 085

Request a sales callback

*Required fields

alt

Thank you for your submission!

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

alt

Sales

Monday - Friday

9:00 AM - 5:30 PM

1800 995 085

alt

Sales

Monday - Friday

9:00 AM - 5:30 PM

1800 995 085

The site you requested may not be relevant in your area.

country flag

Guiding you through PSD2

In light of the impact of Covid-19, and to minimise the impact on both consumers and e-merchants, the Financial Conduct Authority (FCA) has updated their Strong Customer Authentication (SCA) page to give an additional six months to implement strong customer authentication for e-commerce, to a revised date of 14 September 2021.  View statement here.

Read our Practical Impact Guide for eComm

Elavon technical partners must be accredited to EMVCo 3D-Secure  Contact us now

EU Deadline 31 December 2020

Count Down Timer

Latest thought leadership

Are you ready for PSD2

PSD2 is a game changer  

The second Payment Services Directive also known as PSD2 is a game-changer. It introduces new security measures – to make it safer to shop and bank online.

Listen to our expert on SCA

Federico Gaffney, Senior Manager Payment Strategy Risk for Elavon Europe, talks us through the implementation of Strong Customer Authentication for eCommerce merchants

Elavon PSD2 Updates

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

PSD2 explained

  • 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].

    Why do PSD2 SCA regulations make these transaction types and frameworks so relevant?

    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.

    Key principles of PSD2 SCA – a quick re-cap before we start.

    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. 

    • The intent of the PSD2 SCA regulation is to secure ALL electronic transactions, in ALL channels, with SCA.  Very few and limited exceptions to this rule exist. 
    • This SCA means EMV Chip & PIN or Contactless in your physical sales outlets. In the e-commerce channels the most widely available authentication technology will be provided by EMV 3DS.
    • As a general guideline, if the customer is ‘in-session’, present, connected on-line or in-store and therefore able to accept an authentication challenge request from their card issuing bank in real time, then they MUST be authenticated.
    • Similarly, if the customer is not ‘in-session’ and not present, an authentication challenge request from their card issuing bank CANNOT be responded to. Therefore some transaction types have been considered either exempt from authentication, or out of scope of the regulation altogether.
    • ‘In-session’ transactions, when authenticated, will shift fraud liability away from you.
    • ‘Out-of-session transactions’ when not authenticated, will shift fraud liability towards you.

    You’re going to have choices to make about:

    • How you continue or modify your engagement with your customers on first contact.
    • How you establish transaction processing procedures with them via consents and permissions supported by T&C agreements.
    • How you will balance the desire for frictionless flows with the risk of fraud liability shifts that will result from your decisions.  

    What is CIT, COF and MIT?

    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.

    CIT – Cardholder Initiation Transactions

    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.

    COF – Credential on File Transactions

    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.

    MIT – Merchant Initiated 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.

    Who can make use of these customer engagement and transaction frameworks to avoid friction?  

    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:

    • Recurring payments  - creating a series of transactions for the same amount such as a subscription or membership service
    • Instalment or pre-payments – enabling the cardholder to spread the cost of a larger purchase
    • Incremental authorisations – where cardholder spend exceeds a previously authorised amount
    • Delayed Charges – enabling you to post supplemental account charges after the original services have been rendered.
    • No Shows – where the merchant is enabled to charge for services for which the cardholder entered into an agreement to purchase, however did not meet the terms of the agreement.
    • Re-authorisations – a purchase made after the original transaction to include scenarios like delayed/split shipments or extended stays/rentals.

    Business requirements for processing COF and MIT transactions  

    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.

    COF processing requirements

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

    • Inform the cardholder that credentials are being stored, specifying how the cardholder will be notified of any changes to the consent agreement, and identifying the agreement expiration date.
    • Disclose to cardholders how those credentials will be used.
    • Notify the cardholder of the identity and location of the merchant and the transaction amount or how it will be calculated.
    • The frequency (recurring) or event (unscheduled COF) that will prompt any transactions.
    • For installment payments, the total purchase price and terms of future payments including the dates, amounts, and currency.
    • Notify the cardholder when any changes are made to the terms of use.
    • Notify the cardholder of any cancellation or refund policies.
    • Retain the agreement for the duration of the consent and provide it to the issuer upon request.
    • Where required by applicable laws or regulations, provide a record of the consent to the cardholder.
    • Inform the issuer via a transaction that credentials have been stored on file.
    • Identify and flag transactions with appropriate indicators when using stored credentials.

    MIT processing requirements

    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:

    • Submit a payment transaction (authorisation) at the time of credential capture if an amount is due to be processed at the same time. If no amount is due at the time of credential capture, the merchant (or its agent when 3rd party bookers are involved) must submit a zero-value authorisation (ZVA refers to Account Verification Authorisation by Visa, Account Status Inquiry by Mastercard).  Note that this is already an existing requirement for instalment and recurring transactions in the European region that rely upon COF.
    • Identify in the transaction that the credential is being stored. Note that if either of the first payment transaction or the ZVA is declined, the credential cannot be stored and the merchant must not use the credential for any subsequent transactions.
    • Note that an Issuer will not decline a transaction based on a missing CVV2 if the authorisation request is for a subsequent transaction after the credential is stored. This rule previously applied only to recurring transactions but is now applicable to Recurring, Instalment, Unscheduled COF and any transactions initiated by the cardholder (CIT) using COF

    The story so far…  CIT creates COF and enables MIT resulting in frictionless payment flows for your customers.

    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 story continues next month  

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

      Some authorities may need to confirm payments made using, for instance, central travel accounts, lodge cards and virtual cards – payment processes that are centralised within a given business or corporation – to guarantee levels of security in line with the PSD2 requirements.

      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:

    1. Low Value Exemption

    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.

    2. Recurring Payment Exemption

    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.

    3. Transaction Risk Analysis (TRA) Exemption

    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.

    4. Trusted Payee Exemption (or whitelisting)

    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.

    5. Secure Corporate Payments

    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:

    • 3DS1 transactions (where the issuer is only supporting 3DS2)
    • Magstripe transactions
    • Keyed customer present transactions
    • Non-authorised transactions
    • Chip fall back
    • Deferred authorisations (non-Chip and PIN transactions)
    • Unauthenticated eCommerce transactions
  • References the articles of the Regulatory Technical Standards (RTS) published by the European Bank Authority.

    Merchant Initiated Transactions (MIT)

    Merchant Initiated Transactions are payments initiated by the customer without the interaction of

    the cardholder, for example:

    • A single transaction, such as a cancellation fee
    • Recurring payments for fixed or variable amounts such as a monthly membership subscription
    • A series of transactions for a variable amount or at variable intervals – such as irregular payment instalments for a holiday, or a regular but variable amount such as a utility bill

    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.

    Mail Order/Telephone Order (MOTO)

    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.

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

    Unattended Transport and Parking Terminals

    Any payment for transport fares or parking at unattended terminals (e.g. at an airport or train station) will not require SCA.

    One Leg Out Transactions

    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.

Get your business ready for PSD2

We are committed to supporting your business in preparing for and complying with PSD2.

Request a call back