Nowadays, the usual methods of authenticating users on portals, corporate systems, VPNs, etc. are all familiar to us.
We all know about authentication factors (what you know, what you have, and what you are), two-factor authentication, multi-factor authentication, how to implement these factors, and much more.
When it comes to payment transactions, there are many hidden pitfalls, as there are a series of fundamental differences between a normal application in a business, for example, and a payment system like a plastic card, an e-wallet, etc. .
Let’s see this in more detail.
When it comes to enterprise level authentication, we can find many proven solutions to solve the problem; protocols (such as Active Directory, SAML, RADIUS, OpenID, OAuth, a set of RFCs or a set of ISO standards), specifications, vendor software and hardware to facilitate vendor authentication, as well as software and hardware that can communicate with these providers.
Another topic of discussion concerns client authentication devices, such as tokens, MAC calculators, smart cards, NFC rings, fingerprint scanners, etc.
This huge market always tries to stay organized and create intercompatible solutions. This is great, because you can get an enterprise-level application (for example, an e-doc system) and link it to your users’ directory through Identity Management (IdM) and with various authentication methods. via a Single Sign-On (SSO) system.
The SSO system will cover your authentication requirements, while the IDM will manage users and authentication factors. It doesn’t matter which supplier provides these components for you. All will work with standardized protocols.
Learn about the different payment transaction authentication methods
The issue of a payment infrastructure is, however, much more complex. I see two main reasons for this. The first is that user management is totally different from traditional applications. The second is that there is no standard for authenticating a user or a user’s transaction through the processing of payment transactions.
As a result, every financial company (bank, fintech, e-wallet, investment platform, etc.) must invent something according to its own vision and its own risks.
Let’s say you are a regular bank. If we ignore features like the open API then you are giving two main options for a user to spend their money; using a payment card and via a remote banking system with mobile banking, online banking, etc.
When it comes to offline payments with a card, there is no problem. You work with point of sale terminals via a payment system such as Visa or Mastercard. The payment process is completely transparent and secure.
In the case of a cardless transaction (such as in e-commerce), then depending on the requirements of Verified-By-Visa and those of similar services, you, as the card issuer, must authenticate the cardholder. menu.
The transaction will be processed by specialized card processing infrastructure and software. It is usually a separate division of a bank with its own rules that combine the requirements of the payment system such as Visa and internal risk management.
These rules, infrastructures and software provide a very limited range of transaction authentication mechanisms. Usually one of the following is used; card PIN, a separate static PIN, one-time password (OTP) via SMS, or one-time password via push notification.
Can you manage the authentication methods? No. Can you use anything better and more secure than texting? No. Can you ask a treatment provider to cover your needs? Yes, but be prepared to pay. Without any guarantee. Compare that with enterprise apps and you will see the difference.
You might be asking yourself, do I really need to change something? Maybe things are going well the way they are? Let’s see.
Using a card’s PIN code to authenticate an Internet payment transaction is not a good idea. It can be diverted at many points on its way from the user to where it is being processed.
There are many tools and techniques for doing this; keyloggers, man-in-the-middle attacks, man-in-the-browser attacks, Trojans, exploits, etc. I don’t think there is any need to explain why card pin theft is a bad thing.
A separate static PIN has the same vulnerabilities, but at least the card PIN will not be stolen and the card will not be used offline by the perpetrator.
The disadvantages of an OTP via SMS have been discussed several times. It is not at all secure as it has a large number of technical and technological vulnerabilities and can be hijacked using social engineering, phishing, etc.
In addition, it is extremely expensive. And what’s more, its use is increasingly banned in more and more countries due to its drawbacks.
An OTP via push notification has the same disadvantages from a technical and technological point of view. It is, however, inexpensive.
How do you choose an authentication method for your organization?
Going forward, you have several options for setting up your remote banking system.
The first option is to build it around card processing. In this case, you will have all the authentication issues, eg security and maintenance, from the previous paragraphs.
You will become hostage to slow, very exclusive and expensive processing providers, rules of payment systems like Visa or Mastercard, etc. Forget about modern and practical services.
The second option is to create a remote banking system to your own specifications. Using modern techniques, it can be a set of back-end services and a front-end solution.
In this case, you can configure the transaction processing flow as you wish, with transaction authentication following your own rules. Of course, you can find solutions like this from trusted vendors.
If a vendor’s solution or your own internal solution allows, you can integrate IdM and SSO into your remote banking system and additional services.
I think if you could choose a payment transaction authentication method, you wouldn’t choose an insecure and expensive method with many known issues like SMS messages or a static PIN.
From my perspective, the best solution for payment transactions is to use mobile-centric confirmation solutions like PayConfirm. It has a very high level of security, is cheaper than SMS, and is much more convenient for users.
If we continue to imagine that you are a bank, you might of course prefer to combine the transaction authentication methods for cardless transactions and for a remote banking system.
Yes, you can take the simpler route and make all of your systems as bad as the worst component of it (card processing, for example). Another way, however, is to push treatment providers to meet your needs.
Such requests may dictate authentication standards, as in the corporate sector. It will be good for everyone involved: financial institutions, security providers, end users, support companies, etc.
Thus, the position of a bank is not very convenient in terms of authentication of payment transactions. But fintechs, e-wallets and other financial institutions don’t have the same restrictions as a bank.
This means they can use modern mobile-centric solutions that are cost effective, secure and convenient for end users.
Featured Image Credit: Technological photo created by rawpixel.com – www.freepik.com