PSD2: SCA Updates

Update #2
SCA: What Have We Learned Since?

Published 28.09.2020

Since the introduction of PSD2: SCA regulatory technical standards, several additional pieces of information have surfaced from card schemes, and newly identified scope has been introduced by the European Banking Authority (EBA) since the original September 2019 deadline. We have summarised the pertinent points we feel our clients in the media subscriptions space should be aware of.

Additional Mandatory Data Points

As part of the implementation of SCA technical standards and 3DS Version 2 EMVCo. specifications, certain fields and data points are now mandatory, above and beyond those originally specified. Some of these data points have been available within eSuite APIs for some time as optional parameters, but the mandatory nature now requires eSuite to validate these exist for a 3DS Version 2 transaction not to be rejected. Additionally, there are also some new data points that are critical to the security and functionality of the 3DS Version 2 process. These data points used within a typical 3DS Version 2 request are as follows:

Mandatory Data Points	Description
Card Holder Name	The card holder name as presented on the card
Billing Address	Billing Address Line 1 Billing Address Line 2 (optional) Billing Address Line 3 (optional) Billing Address City Billing Address Postal Code Billing Address County/State (optional) Billing Address Country
Email Address	The card holder email address
Phone Number	The card holder phone number

How Will eSuite Process This Data?

For the Billing Address data points, eSuite already allows for the setting of these parameters as part of the API request to create a card wallet, and these are stored against the wallet under the Account in eSuite. It is advised that clients will update their integrations to pass in the required Billing Address data points within each API request.

However, eSuite is introducing client configuration options and business logic to control what to do if this information is not provided as required. This will give clients the flexibility to control whether to attempt to use Account level data if available, to provide into the downstream 3DS Version 2 transaction in lieu of a provided Billing Address, or to use default data values that will pass EMVCo validation, but could lead to a higher risk of a challenge to the customer.

Whilst initially the increased risk of a challenge to a customer might not sound like an ideal option, compared to the friction created by asking a customer to enter their full billing address during the purchase journey, the results could be more positive in terms of user experience. This option will also allow our clients to perform a more gradual update of Billing Address data points for any legacy card wallets already stored within eSuite, which can be handled as part of a self-care process, rather than in the purchase journey if preferred.

For the Email Address and Phone Number data points, these are being introduced as new parameters that can be passed within any of the APIs for creating a card wallet, completing a subscription/product purchase or ad-hoc payment requests as required. The key difference for these data points from the Billing Address data points, is that eSuite will only temporarily store them within the session, while the information is passed downstream to be verified by the issuer, before removing upon success.

Again, it is advised that clients will update their integrations to pass in the required Email Address and Phone Number data points within each API request. However, eSuite will include client configuration options and business logic for these data points too, allowing for Account level or default values to be passed downstream if preferred.

The provided data points, as well as being mandatory for 3DS Version 2 to initiate, will also be validated downstream by the issuers by comparing to the information they hold on record for their cardholders. This information is then used as part of the fraud analysis by the issuer to calculate as to whether to allow a frictionless or challenged 3DS Version 2 workflow to occur.

Client Contact URL

As well as the mandatory information that a client can now pass within an eSuite API request, the EMVCo. specification for 3DS Version 2 also requires the provision of a Client Contact URL data point for a transaction to be successfully initiated. This URL should be a client specific link that could be used to redirect a customer to a page to get access to any relevant client contact information, or access to information on any T&Cs related to the purchase.

How Will eSuite Store This Information?

MPP Global will require our clients to provide this Client Contact URL upfront as part of the 3DS Version 2 onboarding process, so that we can configure this as part of your implementation. We will then pass this information as part of each transaction sent downstream to the issuer, so that a link to the URL can be displayed to the customer if required as part of the 3DS Version 2 workflow. If a client needs to change this URL at any point, they should work with MPP Global customer support team to update as required.

Recurring Payments, Challenge on Initial Payment

Throughout 2019 it was widely accepted that although 3DS Version 2 is the recommended solution for achieving SCA requirements for card payments, 3DS Version 1 was a suitable and compliant alternative. Additionally, Merchant Initiated Transactions (MIT) would be exempt from SCA requirements, as the customer is not present to handle the challenge process if required, and the initial authority to store the card for future use was a suitable security mechanism.

However, over the course of 2020 it has become clear that the SCA regulatory technical standards and schemes are driving issuers towards a process of only allowing MIT transactions to be exempt from the SCA regulations if the initial request for the authority to store the card wallet was given via a challenged 3DS Version 2 transaction. This process would therefore mean that if the original transactions for a subscription purchase had gone through a frictionless workflow, any subsequent MIT transactions would be likely declined by the issuer.

How Will eSuite Handle This?

For all recurring subscription purchases, the initial Customer Initiated Transaction (CIT) will be forced to be challenged, and this can be controlled by eSuite by informing the issuer that a challenge is mandated for that transaction. By initiating this Continuous Payment Authority (CPA) in a challenged 3DS Version 2 workflow, any subsequent renewal transactions will be exempt from SCA.

For any one-off payments or non-recurring purchases, because there are no expected MIT transactions to follow, there is no need to enforce the challenge, and therefore in this scenario a frictionless 3DS Version 2 workflow could be achieved, and that decision is left to the issuer to determine.

For those clients who require the functionality to perform ad-hoc MIT transactions, eSuite have also introduced client configuration and business logic to cater for these scenarios. A client that allows a customer to create a card wallet and then the client needs to be able to make ad-hoc requests for payment against that card when the customer is not present can use this business logic to ensure that their MIT transactions process successfully. For example, in scenarios where an account balance needs to be automatically topped up, or a certain event occurs to trigger an MIT transaction, eSuite will allow the client to enforce the challenge when the card wallet is initially created.

Because of the above requirement to enforce a challenge it should therefore now be considered that 3DS Version 1 is not a suitable solution for clients wishing to offer recurring subscription purchases, or ad-hoc MIT payments. 3DS Version 1 does not allow eSuite to inform an issuer that a challenge is mandatory, and therefore the ongoing success of MIT transactions would be at risk. For all our clients MPP Global recommend moving to 3DS Version 2 to support all use cases and offer the best user experience to customers.

eSuite API Changes to Support 3DS Version 2.0

As part of our continued enhancement, MPP Global will update a series of endpoints to cater for 3DS Version 2 and the new requirements identified above. These changes will be supported with documentation on how to migrate to relevant versions.

Primary Endpoint	Description	Actions
Add Card	This endpoint provides the ability to add a new payment card (credit or debit)	Support SCA with a 11.x format only
Direct Purchase Endpoints	Description	Actions
Add Subscription	This endpoint provides the ability to initiate the purchase of a subscription	Support SCA with a new 9.x, 10.3x and 11.x format endpoint
Payments & Orders	This endpoint provides the ability to initiate a one-off purchase or payment	Support SCA with a new 11.x format endpoint
Buy Product	This internal endpoint provides the ability to purchase a product via Virtual Terminal	Out of scope as always used for MOTO scenarios
Service Credits	This endpoint provides the ability to initiate the purchase of service credits	Support SCA with a new 11.x format endpoint
Workflow Endpoints	Description	Actions
Add Subscription Workflow	This endpoint provides the ability to initiate the purchase of a subscription	Support SCA with a new 10.x format endpoint
Miscellaneous Payment Workflow	This endpoint provides the ability to initiate a purchase	Out of scope
Buy Product Workflow	This endpoint provides the ability to initiate the purchase of a product	Out of scope
Service Credit Workflow	This endpoint provides the ability to initiate the purchase of service credits	Out of scope
Additional Endpoints	Description	Actions
Move Subscription	This endpoint provides the ability to move from one account subscription to another	Support SCA with a new 11.x format endpoint
Payment Instruction	This endpoint provides the ability to create a new payment instruction	Support SCA with a new 11.x format endpoint

Please note: Any API endpoints listed as out of scope, as well as legacy eSuite integrations via SOAP, iShop and eSuiteJS, will not be updated to support 3DS Version 2. Please contact your account manager to discuss upgrade options.

 

---

Update #1
PSD 2: Strong Customer Authentication

Published 30.07.2020

Last year, MPP Global introduced a series of updates and live webinars outlining changes required by the European Payments Services Directive 2 (PSD2), in relation to Strong Customer Authentication (SCA) and its impact to MPP Global clients. These updates were temporarily put on hold due to several extensions announced by the European Banking Authority (EBA) in response to many merchants and acquirers expressing they will not be fully SCA-compliant within the timescales. More recently, the COVID-19 pandemic has also impacted these SCA enforcement dates in some markets. The EBA have now confirmed a Europe-wide deadline for Strong Customer Authentication, which will now be enforced as of 31 December 2020.*

What is PSD2: Strong Customer Authentication (SCA)?

By way of reminder, the introduction of rules surrounding PSD2 in 2018 set out to further protect consumer privacy, reduce fraud and accelerate technological innovation through payment services.

Since PSD2 came into effect, the European Commission drafted and introduced Regulatory Technical Standards (RTS), kick-starting a grace period for banks and businesses to be compliant with a series of technical payment standards on Strong Customer Authentication (SCA). SCA requirements will impact all MPP Global clients operating in, or have customers in, the European Economic Area (EEA).

SCA requires merchants to operate a more stringent, multi-factor authentication model for electronic transactions. MPP Global will support 3D Secure 2 (3DS 2) as the preferred method of compliance with the SCA standards, becoming a mandatory basis for processing payments online across the EEA.

What is 3D Secure 2 (3DS 2)?

3D Secure is an authentication protocol, developed with the intention of improving the security for electronic payments. However, several pain points have been noted about the original protocol, namely for adding unwanted friction within the purchase flow, impacting UX and abandonment rates for many merchants. Version 2, also known as EMV 3DS, introduces several enhancements, enabling customers to multi-factor authenticate via ‘frictionless’ payment flows, using more advanced technology options to minimise disruption to the user experience.

To comply with enforcement of SCA across the EEA, issuers will make risk assessments on each request to complete a purchase received on behalf of their cardholders. If the issuers deem that a challenge is required to satisfy themselves that the request is from the cardholder and not fraudulent, customers will be required to multi-factor authenticate upon purchase. The new authentication measures are split into three categories. SCA requires two of the three factors to authenticate to complete a purchase:

• Knowledge: something only the user knows, e.g. a password or a PIN code
• Possession: something only the user possesses, e.g. a mobile phone, and
• Inherence: something the user is, e.g. the use of a fingerprint or voice recognition

Opportunities for 3DS 2 include increased authorisation rates; improved customer confidence; reduced merchant fraud liability; multi-device support; exemption management to avoid unnecessary authentication; and the ability to serve up frictionless checkout experiences.

Challenged vs Frictionless Flows

3D Secure 2 requires the merchant to submit additional data points to the issuer during the checkout flow. These additional data points are made up of customer-specific details such as billing address, paired with merchant contextual data, such as their transaction history, purchase value and device information to name a few.

The issuer’s 3DS service will perform a risk assessment to determine if additional authentication is required. The issuer will then send either of the two responses back to the merchant:

1. CHALLENGE: based upon the data submitted, the risk-level is deemed high, initiating a ‘challenge’ flow, prompting the customer to provide additional authentication.
2. FRICTIONLESS: based upon the data submitted, the risk-level is deemed low, initiating a ‘frictionless’ flow, prompting the customer to proceed without the need to submit any further detail.

What are the Exemptions for SCA?

There are currently several exemptions and online transaction types out of scope for SCA. We have summarised the main exemptions below and will provide guidance in further communications. However, if you have questions in the meantime, please do not hesitate to contact your Account Manager.

• MOTO transactions (Mail Order / Telephone Order)
• ‘One leg out’ transactions - where the issuer or acquirer is outside of the EEA
• Low value transactions - where the transaction is <€30 (cumulative & consecutive limits apply)
• Low risk transactions - where an issuer or acquirer has deemed the transaction low-risk based on their own fraud checks
• Fixed amount recurring transactions - 3D Secure triggered on the initial purchase, and not for the series of payments
• Merchant Initiated Transactions (MIT) - customer-agreed fixed or variable transactions initiated by the merchant without intervention from the customer
• Trusted beneficiaries / merchant whitelisting (MWL) – where the customer can submit trusted merchants to their issuer to exempt them from SCA

You can read more about the exemptions here.

Latest Timelines

• 12th January 2016 – PSD2 regulations initially introduced
• 27th November 2017 – Regulatory Technical Standards (RTS) announced for Strong Customer Authentication (SCA)
• 13th January 2018 – Elements of the PSD2 rules to begin enforcement
• 14th September 2019 – Original EBA SCA mandate roll-out deadline
• 18th October 2019 – Mastercard mandate for all EU issuers to have adopted 3DS 2.1 begins
• 14th March 2020 – Visa mandate for all EU issuers to have adopted 3DS 2.1 begins
• 31st December 2020 – Revised EBA SCA enforcement date*
• 14th October 2022- 3DS 1.0 transactions no longer supported on the Mastercard network

*In response to the COVID-19 pandemic, the following country specific Regulators have issued further communications around the topic of potential further extensions to their own enforcement dates:

• UK: The FCA has extended the SCA transition for e-commerce until 14th September 2021
• France: Banque de France will provide additional flexibility until the 30th June 2021
• Germany: BaFin will formally maintain the EBA deadline of 31st December 2020

Whilst the EBA SCA enforcement date remains the 31st December 2020 some Regulators, such as the FCA in the UK, have agreed to extend enforcement for issuers within their market. Whilst this could be considered good news, it would only be beneficial if a client only accepts payments from customers who have an issuing bank within the UK. Any customers that are using cards issued elsewhere in the EEA would still expect to be enforcing the SCA requirements.

Failure to comply with SCA requirements by the enforcement date will likely see card issuers begin to decline non-compliant transactions. It should also be noted that although the dates given above are the deadlines for SCA enforcement, it should be anticipated that issuers will begin to test their own 3DS services with a soft ramp up of declines for transactions that don’t support SCA ahead of those deadlines.

Summary of eSuite SCA Support

Throughout 2019, MPP Global introduced several changes to support both 3DS 1 and 3DS 2, with several merchants opting to use 3DS 1 as some gateways, acquirers and issuers were not ready to fully support 3DS 2 initially. Since then, there has been more widespread adoption of 3DS 2 downstream, and support is more readily available, with some exceptions. A summary of changes eSuite has adopted to comply with SCA include:

• 3DS 1 is deemed SCA compliant and is already supported via eSuite, however it is highly recommended that 3DS 2 is used by our clients.
• 3DS 2 offers many benefits to merchants such as exemptions and frictionless experiences, and since card schemes have already announced decommission dates for 3DS 1 in the years to come, it is the recommended option
• Initial 3DS 2 endpoints and API versions were launched in 2019 to support the original SCA deadline
• Additional development for 3DS 2 is underway to introduce changes to the API in a new version to support changes we have seen since, such as mandatory data and new validation requirements introduced by EMVCo.
• 3DS 2 requires changes from the entire payment ecosystem, including merchants, PSPs, gateways, acquirers and issuers. As well as working with MPP Global to be ready, we recommend reaching out to your acquirer to ensure they will be ready to support 3DS 2 and any additional support and guidance they can also provide
• For clients using iShop, 3DS 1 is currently supported, however, this will not be upgraded to support 3DS 2. It is recommended that clients consider newer integrations via REST API to benefit from 3DS 2
• For clients processing MOTO transactions via REST API, eSuite Virtual Terminal or iShop, MOTO transactions are not in scope for SCA and will continue to function as expected. However, for clients using the legacy version of Virtual Terminal, we highly recommend they transition to the latest version to benefit from newer features.

Please contact your Account Manager or support desk to discuss any of the above changes.

What's Next?

Over the forthcoming months we will release additional communications on the changes we have seen over the extension period, and how we feel those are relevant to our clients and continue to keep you informed as new information is identified. Additionally, we will add further detail on how eSuite will deliver the integration options required to support 3DS 2 and any changes incorporated within our API endpoints.

In the meantime, if you have any questions, please do not hesitate to contact your Account Manager or reach out to our support desk.

 

---

Disclaimer 

Nothing on this page constitutes legal advice. 

The contents of this page are for general information purposes only. Whilst we endeavour to ensure that the information in this page is correct, no warranty, express or implied, is given as to its accuracy and we do not accept any liability for error or omission. 

We shall not be liable for any damage (including, without limitation, damage for loss of business or loss of profits) arising in contract, tort or otherwise from the use of this page or any material contained in it, or from any action or decision taken as a result of using or inability to use this page or any such material