We are starting a series of articles about security in payment technologies. The topic is large, this article will be the first, introductory one. We decided to talk about security with Igor Goldovsky, the chief architect and director of the department, a person who knows everything about payment systems and their protection.
Security issues in card payment technologies play a key role. The bank card itself is a means of providing remote authentication of its holder when making a non-cash purchase or receiving cash. The security of card transactions in general, and, consequently, the trust of users in cards as a means of payment, largely depends on the reliability of the cardholder authentication methods used.
On the other hand, payment technologies do not blindly follow the slogan “There is no such thing as too much security.” Technologies that provide a high level of security, but are inconvenient to use and/or require significant costs/efforts to implement, turn out to be unclaimed in practice.
One example that illustrates this point is the unsuccessful attempt to implement the Secure Electronic Transaction (SET) protocol, which was practically flawless in terms of the security it provided for processing e-commerce transactions. The standard appeared in 1998 and began to be used by banks, but by 2001 it became clear that its rapid mass implementation was impossible due to the high cost of solutions offered on the market, as well as problems on the side of cardholders associated with the need remote installation and configuration of client software on their personal computers. As a result, payment systems gradually abandoned the use of SET and began to implement the 3-D Secure protocol, which was much easier to use and cheaper for banks/stores.
Previously, the “armor and projectile” model was implemented on the market - in response to the next projectile received from scammers, armor of the required thickness for this projectile is installed. But card payments are a commercial business, in which countermeasures must be sufficient from a security point of view, as well as as unburdensome and convenient for banks and users as possible.
I will give one example of such a competition between armor and projectile. By the end of the 90s, leading payment systems came to the conclusion that, despite all the efforts they had made, to effectively combat counterfeit cards it was necessary to switch to a completely new technology of microprocessor cards. Microprocessor cards have made it possible to radically improve the security of so-called Card Present transactions, in which the card is located at the point of transaction, by providing 2-factor dynamic authentication of the card holder by its issuer. With their implementation, the level of fraud on counterfeit cards dropped to almost zero, but the level of fraud began to increase for CNP (Card Not Present) transactions, that is, those where there is no card at the point of execution of the operation. First of all, we are talking about e-commerce operations, recurring payments, Card-on-File operations, etc. Currently, technologies have emerged that make it possible to ensure a level of security for CNP operations comparable to operations using microprocessor cards. This includes a new version of the 3-D Secure 2.0 protocol, in-app payments in phones, tokenization of cards, and remote payment operations using Secure Remote Commerce systems.
At the same time, the 3-D Secure protocol leaves out the procedures for conveniently choosing a payment instrument for the buyer and making a purchase, as well as organizing (if necessary) the procedure for authenticating the buyer by his bank. Certain attempts to fill the gap were previously made by leading PSs that created their own wallets for making remote payments. But today we can already admit that these attempts were not successful enough to win the hearts of cardholders. The Secure Remote Commerce (SRC) protocol is a new attempt to solve the problem of creating a convenient and secure wallet for the buyer, designed for remote payments.
The mechanism is formalized as a standard of the EMVCo association and was promptly adopted by leading PSs. Some international payment systems have already created their SRC platforms and launched them in a pilot project in the United States at the end of last year. The SRC mechanism is implemented on the basis of a technical platform that provides the user with payment for a purchase using the “one-click checkout” principle. In addition, SRC increases the security of online transactions by eliminating the need to enter card details (or rather, minimally using this procedure) and tokenizing payment instruments.
SRC allows the cardholder, when performing an EC transaction, to use a “single button” on the merchant website to make a payment using any of his payment instruments registered on the platform. To do this, SRC itself identifies the user, selects the user’s payment instruments suitable for paying for a purchase at a given merchant, and allows the buyer to choose one of them. After registering with SRC, when performing a transaction, the user does not need to enter information about himself, the payment instrument and the delivery address of the goods. All this data is entered once during registration and then stored on the SRC platform.
The procedure for making a purchase through the SRC system is described below in a very simplified form.
The advantages of implementing the SRC system for the buyer are obvious:
For merchants, the advantage of implementing SRC is that the issues of organizing secure non-cash payments are comprehensively and universally resolved for them. The store is only required to integrate some client software of the SRC system into its software, ensuring its integration with SRC. As an example, a solution to a store’s problems is the use of tokenized Card-on-File payments offered to the store by the SRC platform. Also on the merchant side, a reduction in the number of customer refusals from online purchases (abandonment rates) is expected due to the buyer’s distrust of the payment method offered to him.
In short, payment systems and their participants have high hopes for the implementation of SRC, rightly assuming that this new remote payment mechanism will be as convenient as possible for the buyer.
Security issues in card payment technologies play a key role. The bank card itself is a means of providing remote authentication of its holder when making a non-cash purchase or receiving cash. The security of card transactions in general, and, consequently, the trust of users in cards as a means of payment, largely depends on the reliability of the cardholder authentication methods used.
On the other hand, payment technologies do not blindly follow the slogan “There is no such thing as too much security.” Technologies that provide a high level of security, but are inconvenient to use and/or require significant costs/efforts to implement, turn out to be unclaimed in practice.
One example that illustrates this point is the unsuccessful attempt to implement the Secure Electronic Transaction (SET) protocol, which was practically flawless in terms of the security it provided for processing e-commerce transactions. The standard appeared in 1998 and began to be used by banks, but by 2001 it became clear that its rapid mass implementation was impossible due to the high cost of solutions offered on the market, as well as problems on the side of cardholders associated with the need remote installation and configuration of client software on their personal computers. As a result, payment systems gradually abandoned the use of SET and began to implement the 3-D Secure protocol, which was much easier to use and cheaper for banks/stores.
Previously, the “armor and projectile” model was implemented on the market - in response to the next projectile received from scammers, armor of the required thickness for this projectile is installed. But card payments are a commercial business, in which countermeasures must be sufficient from a security point of view, as well as as unburdensome and convenient for banks and users as possible.
I will give one example of such a competition between armor and projectile. By the end of the 90s, leading payment systems came to the conclusion that, despite all the efforts they had made, to effectively combat counterfeit cards it was necessary to switch to a completely new technology of microprocessor cards. Microprocessor cards have made it possible to radically improve the security of so-called Card Present transactions, in which the card is located at the point of transaction, by providing 2-factor dynamic authentication of the card holder by its issuer. With their implementation, the level of fraud on counterfeit cards dropped to almost zero, but the level of fraud began to increase for CNP (Card Not Present) transactions, that is, those where there is no card at the point of execution of the operation. First of all, we are talking about e-commerce operations, recurring payments, Card-on-File operations, etc. Currently, technologies have emerged that make it possible to ensure a level of security for CNP operations comparable to operations using microprocessor cards. This includes a new version of the 3-D Secure 2.0 protocol, in-app payments in phones, tokenization of cards, and remote payment operations using Secure Remote Commerce systems.
Let's talk about Secure Remote Commerce
The 3D-Secure secure e-commerce protocol (v.1.0 and v.2.0), used for two decades by payment systems (PS), provides the issuer with the ability to authenticate the holder of his card at the very beginning of the payment procedure for an online purchase, before the issuer begins to authorize the payment in the payment system. The introduction of the first version of the protocol has significantly improved the security of purchases in online stores. The new version of the 3-D-Secure v.2.0 protocol has expanded the capabilities of the first version, allowing purchases from the store’s mobile application on the buyer’s smartphone, as well as ensuring the operation is completed without direct authentication of the client by his bank (in the so-called frictionless mode). In the latter case, the 3-D Secure v.2.0 platform assesses the risks for the transaction being performed and, on behalf of the issuer, decides on the possibility of authorizing the transaction without direct authentication of the buyer by his bank. When making a decision, the purchase parameters are taken into account, as well as information about the device from which the transaction is made and about the buyer.At the same time, the 3-D Secure protocol leaves out the procedures for conveniently choosing a payment instrument for the buyer and making a purchase, as well as organizing (if necessary) the procedure for authenticating the buyer by his bank. Certain attempts to fill the gap were previously made by leading PSs that created their own wallets for making remote payments. But today we can already admit that these attempts were not successful enough to win the hearts of cardholders. The Secure Remote Commerce (SRC) protocol is a new attempt to solve the problem of creating a convenient and secure wallet for the buyer, designed for remote payments.
The mechanism is formalized as a standard of the EMVCo association and was promptly adopted by leading PSs. Some international payment systems have already created their SRC platforms and launched them in a pilot project in the United States at the end of last year. The SRC mechanism is implemented on the basis of a technical platform that provides the user with payment for a purchase using the “one-click checkout” principle. In addition, SRC increases the security of online transactions by eliminating the need to enter card details (or rather, minimally using this procedure) and tokenizing payment instruments.
SRC allows the cardholder, when performing an EC transaction, to use a “single button” on the merchant website to make a payment using any of his payment instruments registered on the platform. To do this, SRC itself identifies the user, selects the user’s payment instruments suitable for paying for a purchase at a given merchant, and allows the buyer to choose one of them. After registering with SRC, when performing a transaction, the user does not need to enter information about himself, the payment instrument and the delivery address of the goods. All this data is entered once during registration and then stored on the SRC platform.
The procedure for making a purchase through the SRC system is described below in a very simplified form.
- Merchant (marketplace, payment service provider), after the buyer selects the SRC Triger button, sends to the SRC system data about the buyer (for example, biometric data of the buyer, ID of the mobile application from which the payment is made), his device (for example, MAC address of the device, version OS, OS identifier and other parameters, in general up to several dozen characteristics) and the merchant itself (for example, the name of the merchant, the merchant category code, etc.). It should be noted that each payment system has its own SRC system. Therefore, the merchant sends requests to all SRC systems belonging to the PS whose cards are accepted by the merchant.
- All SRCs that receive a merchant request perform recognition (identification) of the cardholder and determine his identifier. If a clear identification cannot be made, the buyer will be asked additional questions to definitively identify him (for example, the buyer will be asked to enter his email address)
- SRC searches for platform participants who store information about all payment instruments (cards) of an identified buyer registered with SRC. Such SRC participants are called DCF (Digital Card Facilitator). Information about the payment instrument includes information about the alias of the payment instrument, its scope (in which stores it can be used), as well as instructions for performing the buyer authentication procedure. Today, the role of DCF is performed by payment systems themselves.
- The merchant receives from the SRC system a list of all payment instruments available to the buyer for payment in this merchant and displays this list to the buyer, who selects one of them
- The merchant sends a request to the SRC system containing the payment data and the payment instrument selected by the buyer
- The SRC system sends a request to the DCF representing the user's selected payment instrument
- DCF displays to the user a digital card for the selected payment instrument and, in accordance with the issuer's instructions, arranges for buyer authentication
- DCF responds to the SRC system with a message containing the customer authentication result, and the system prepares data for the authorization request. This data may include dynamic transaction data calculated using cryptographic algorithms
- The SRC system informs the merchant with the data necessary to generate an authorization request, and the merchant initiates the transaction authorization procedure
- After the merchant receives a response based on the authorization result, the merchant returns this result to the SRC system, and the system further uses it in risk management procedures when processing future transactions of the buyer.
The advantages of implementing the SRC system for the buyer are obvious:
- the desired “One click purchase” model is implemented: the buyer is identified by the SRC system by his device and/or payment application, he is given the opportunity to select a card, he does not need to enter the details of the payment instrument and delivery address
- some transactions are carried out without the buyer being authenticated by his bank using risk management procedures supported by the SRC
- provides a universal way to make a purchase and authenticate it (same familiar screens, same actions)
- a wide selection of payment instruments (in the future not only cards).
For merchants, the advantage of implementing SRC is that the issues of organizing secure non-cash payments are comprehensively and universally resolved for them. The store is only required to integrate some client software of the SRC system into its software, ensuring its integration with SRC. As an example, a solution to a store’s problems is the use of tokenized Card-on-File payments offered to the store by the SRC platform. Also on the merchant side, a reduction in the number of customer refusals from online purchases (abandonment rates) is expected due to the buyer’s distrust of the payment method offered to him.
In short, payment systems and their participants have high hopes for the implementation of SRC, rightly assuming that this new remote payment mechanism will be as convenient as possible for the buyer.
