In this section, we discuss who is responsible - and accountable - for implementing SCA, and provide guidance on how affected businesses can become compliant.
Who is responsible for implementing SCA?
Businesses taking online payments are not directly responsible for meeting SCA. That responsibility falls to intermediary Payment Service Providers (assuming relevant online transactions fall under that provider’s remit) and to the banks.
To be more precise, the payer’s bank is responsible for ensuring transactions are SCA compliant (and denying transactions that aren’t compliant). To do that, it must collect the authentication information as prescribed in the SCA framework.
However, the bank needs somewhere to collect that information from, which is where the PSPs come in. They must capture the information securely, as part of the payment flow, and then securely pass that information on to the banks using the banks’ secure mechanisms for doing so. The banks then have the final say on whether that particular transaction is compliant.
Whilst it is the responsibility of the PSP to apply SCA, there can be practical difficulties given the degree of control one PSP may have over the activities or compliance of another PSP. Ultimately, each PSP has to ensure its own compliance which could, in some cases, lead to a more draconian approach being taken to SCA by a payer's PSPs than has necessarily happened in the past.
However, the impact of SCA that we have already outlined, including potential conversion drop-offs, primarily falls on the shoulders of merchants.
Working with a PSP that is either prepared and proactive about SCA will be critical.
If you want to talk in more detail about SCA and the implications for your payments, we’d be happy to chat.
Updating your checkout flow
The process of complying with SCA means an extra step during the checkout flow. This will be the most obvious change your end customers will see. Depending on the payment method, this additional step may be very obvious or almost unnoticeable. For example, mobile payments already use fingerprint scanning or facial recognition to approve purchases, and these are acceptable ‘inherence’ authentication measures.
As we have already mentioned, SCA will primarily affect credit and debit card transactions. To update your checkout flows for card transactions, 3D Secure 2 (3DS2) - a widely supported method of compliant authentication has already been released.
In a recent article for Forbes, Jordan Mckee, Research Director at 451 Research pointed out that “merchants best able to integrate SCA into their checkout flow and effectively apply exemptions will separate themselves from the pack by minimizing customer impact.”
3D Secure 2
3D Secure (3DS) is a method of authentication first deployed by Visa, made for credit and debit card purchases completed online. end customers are required to provide a password in order to complete the payment transaction. Online businesses typically gain access to 3D Secure through a relevant PSP.
3D Secure 2 (3DS2) is a new version that will meet SCA requirements by: Introducing authentication requirements e.g. requiring end customers to input a one-time password/passcode or provide biometric authorisation Allowing the issuer to evaluate whether to accept or decline the transaction.
However, testing and rollout by all parties is unlikely to be fully finalised by 14 September.
The key goal for 3DS2 is to create ‘frictionless authorisation’ even in the face of additional security checks required by SCA. If the transaction is deemed exempt, 3D Secure 2 should bypass these checks. One key improvement compared to the original 3D Secure (3DS) protocol is the ability to carry out the necessary checks without redirecting away from the checkout page.
Potential problems of 3D Secure 2
The original 3D Secure (3DS) was fraught with problems for merchants, including the dreaded conversion drop because of the aforementioned redirects and perceived poor user experience. A study by Ravelin found that 22% of all transaction authenticated using 3D Secure are lost.
While the new version has been designed to minimise the original’s drawbacks, including a better user experience designed for smartphone users, it will require a wider rollout to evaluate whether it has been successful.
3DS2 support and consumer recognition
3D secure 2’s success in managing SCA conversion concerns will hinge on its adoption by both banks and end customers. Despite the impending implementation of SCA, a number of banks have yet to start supporting the 3DS2 protocol.
As for end customers, usage of the original 3DS protocol has been limited in Europe. According to PYMNTS, by late 2017, only 50% of end customers are enrolled and only 25% of transactions are verified.
SCA Regulatory Technical Standards (RTS)
The Regulatory Technical Standards (RTS) of SCA set out the full specifications of exactly what SCA covers and what is expected of all stakeholders. The final version was completed and distributed by the EU Commission in November 2018.
Much of this guide is aimed at putting key aspects of the RTS into plain English. However, the full version is useful if you want to see the complete details of SCA.‹ View table of contents Next page ›