Strong Authentication for Payments – PSD2, 3-D Secure

Why you need strong authentication for web and mobile payments

inWebo access security for web and mobile payments  

Authenticating the payer as the owner of the method used for a payment makes sense from a fraud reduction perspective, but not just that. For online payments made with cards, the liability of the payment is transferred from the merchant to the bank (or the issuer) if the user is authenticated by the bank (or the issuer). Banks and issuers therefore need to enforce secure authentication in order to limit their risks. However, making the payment too complex leads to a higher percentage of purchases being dropped, which is even worse than fraud from the merchants perspective. The convenience of the authentication mechanism is key. Finally, in regulations such as PDS2 in Europe, strong authentication is increasingly required for online payments. Limiting fraud, shifting liability, and ensuring compliance are the main reasons for enforcing secure and convenient user authentication during payments. Also, as specialists have found out, fraud always shifts from the best protected payment methods to the least protected ones.

Strong authentication for PSD2/RTS compliance

The PSD2/RTS specifications mandate that payment initiation service providers (PISP) enforce a strong authentication of the payer unless the transaction characteristics make it eligible to an exemption. For this purpose, PISP can implement an MFA solution or they can rely on the MFA solution implemented and made available on its API by the account servicing payment service provider (ASPSP) i.e., the bank.

In short: banks must implement MFA solutions for the payment accounts of their customers and make these solutions available through an API. PISP must enforce strong authentication for payment transactions – unless a transaction is eligible to an exemption – and can use the MFA solution made available by the user’s bank, or their own.

inWebo MFA solution meets all requirements set out in the PSD2 / RTS document, including but not limited to

  • Authentication codes are based on at least 2 elements (security credentials) of different types among possession, inherence, and knowledge
  • Authentication codes can be dynamically linked to the transaction amount or, if it is not known at the time of authentication, to the maximal amount authorized by the paying user. This feature is called transaction sealing.
  • Security credentials cannot be inferred from authentication codes or from one of the security credentials that would have been compromised. They are protected so that they can’t be extracted from an authentication device and re-used.
  • Authentication codes cannot be replayed.
  • After a maximum of 5 consecutive failed attempts can happen before an authentication method is blocked temporarily or definitely

PISP and ASPSP can therefore achieve PDS2 / RTS compliance by implementing inWebo MFA.

Strong authentication for 3-D Secure

As per 3-D Secure, card issuers should be able to enforce a dynamic authentication of the payer during a card payment online (Card Not Present mode), at least if the merchant requires it. If the dynamic authentication is successful, the responsibility for the payment shifts to the card issuer, therefore protecting the merchant against charge-back.

In short: card issuers (and/or banks when they distribute cards) must implement MFA solutions.

3-D Secure requirements extending to the authentication solution have varied over time and have also been influenced by local regulators. It is usually admitted that the card holder authentication must be done with a transaction-specific and dynamic code. Although short-text messages have been the main authentication method used with 3-D Secure, it is now being replaced with more advanced and secure authentication methods.

inWebo MFA exceeds by far security requirements sets out for 3-D Secure and can therefore be used by card issuers and banks to achieve 3-D Secure compliance.

Strong authentication for Android Pay and Apple Pay

With Apple Pay and Android Pay SDKs, the user authentication doesn’t rely on inWebo MFA. However, it is recommended to implement a consistent user experience for authentication across all channels – proximity payments, 3-D Secure or PSD2 online payments, and the bank accounts. Talk to us to know more how about inWebo can help you achieve this.

inWebo strong authentication for web and mobile payments

Our MFA solution for payment applications consists of

  • Client-side OTP-generation libraries, inWebo mAccess and inWebo Helium.
    • These libraries turn the interfaces to your payment applications – your mobile payment App or SDK, your mobile wallet App, as well as web browsers – into trusted devices, i.e. strong authentication methods.
    • Validating a payment on behalf of the user requires a valid One-Time Password (OTP) generated from one of the user’s trusted devices. Therefore, this defeats attackers who don’t have access to one of the user’s trusted device(s), while making the payment extremely easy for the legitimate user, since the OTP is generated locally (it is not sent to the user) and is provided automatically (the user doesn’t have to copy-paste it).
    • inWebo authentication libraries can dynamically be used for 1-factor (trusted device), 2-factor (trusted device + a secret or a biometric factor), or even 3-factor authentication (if combined across channels / devices). A transaction data, such as an authorized amount, can dynamically be linked into the authentication code (transaction sealing) to keep track of a payer consent on that data. You can use these libraries to design and implement efficient protection strategies across all online payment channels.
    • Unlike other MFA vendors, 100% of user devices – laptops, tablets, smartphones – are supported. Integrating the library into your web and/or mobile applications is all what it takes, there’s no physical token to provide or manage, no App or plugin to download. It’s a very efficient approach to MFA.
    • The libraries provide an abstraction layer for user credentials management. Your developers don’t need to worry about platform specific security integration.
  • A back-end authentication service and full API. The API’s obvious purpose is to validate OTPs received by your mobile and web payment applications and to enforce the security policies that you have defined. It also allows you to fully automate credential management, user enrollment (to MFA), and trusted device management. Only with such an automation can you implement security at scale.

What are your options

To get a deeper understanding of our solutions, you may

  • Sign up for free for a basic account and start implement inWebo access security for your web and mobile payment applications. You’ll be able to upgrade this account at any time to get more licences or options. Nothing to lose but an item on your to-do-list.
  • Evaluate inWebo for free and without commitment for 30 days. Note that we have project management, consulting, and integration partners trained in our solutions whom you can ask for an evaluation and a PoC.
  • Request a customized demo. We’ll be happy to show and explain the basics of our solution and answer your questions.