3-D Secure and MPI Integrations

In this article we are going to discuss in greater detail 3-D Secure program as a cardholder data protection instrument. Particularly, we are going to focus on 3-D Secure implementation aspects within a payment system.

It should be reminded that 3-D Secure is a special protocol, providing additional protection for payment card data within e-commerce transactions. More detailed information about 3-D Secure program can be found in our respective article.

The purpose of this article is to explain how to incorporate 3-D Secure into your payment processing system (exploring the matter from the payment gateway viewpoint).

Any transaction, involving 3-D Secure verification includes two basic phases.

3-D Secure verification through MPI

The first phase is card verification through MPI (merchant plug-in). An MPI is a special module, designed to facilitate 3-D Secure verification and prevention of payment card fraud. On the basic level, MPI verifies the card number with the card issuing bank, and checks if it is enrolled in the 3-D Secure program. More detailed information on merchant plug-ins can be found here.

Initially a query is sent to the issuer to check if the card is enrolled in 3-D Secure program (it is called Enrollment Verification Request, or VeReq). In order for the card to be enrolled, the issuing bank itself must be enrolled in the 3-D Secure program, and the cardholder must have a unique password or some other verification method on file for this particular card. Unless these two conditions are met, 3-D Secure verification cannot be performed.

If MPI indicates that the card is enrolled in the program, the next step is the actual verification of the cardholder identity. In many cases, it involves entering of the password that the cardholder previously (at the time of enrollment) assigned to this card. During the transaction, the cardholder is required to enter the password again and confirm his identity to perform the transaction.

Because the confidentiality of the password must be maintained, the cardholder has to be redirected to the website of the issuing bank, where he or she will enter the actual value, which will then be verified by the issuing bank’s underlying system. The result of the verification (called PARES) is going to be returned to the software that made the original MPI verification query, using a previously supplied notification callback URL. PARES contains three values (or fields): ECI (a field, which indicates if transaction was 3DSecure, Attempted or Normal SSL), CAVV, and XID (the last two fields are to be sent to the acquiring bank for authorization). ECI indicates the result of 3D-secfure authentication process (verification successful/verification attempted/unable to verify). XID is the ID (or code) of the particular authentication (a string-type value). CAVV is the authentication verification value (of string type).

Transaction processing

Transaction processing is performed as usual. The only difference is that certain fields are added to a transaction. These are the fields generated as a result of MPI verification (ECI, CAVV, and XID).

Let us illustrate the technical side of the process with an example.


A shopping cart application integrates with the MPI. A customer puts all his purchases to the shopping cart, enters credit card information, and hits “process” button. The credit card information is then sent to the MPI, and the response comes back, indicating whether the card is enrolled or not. If the card is enrolled, an additional request is made to the MPI, which returns the redirect URL and parameters to use to redirect the cardholder to the issuer’s website where his or her identity will be verified (password will be validated). At the next step, the shopping cart executes the redirect (indicating the URL where the response should be directed to) and the cardholder ends up on the website of the issuing bank. The cardholder performs the necessary verifications, such as entering of password. Once the cardholder has entered the information, (s)he is redirected to the callback URL provided by the shopping cart and the outcome of verification process is included as a parameter to that URL. (It should be noted, that the data in issuer’s response (PARES) is encrypted).

Based on verification results, a decision is made, whether the transaction should be performed or not (verification can yield negative results). If the result implies the possibility of further processing, the transaction is sent for processing and the obtained response fields (XID and CAVV) are included in the request.

Gateway viewpoint

If you are a payment gateway and you want to incorporate 3-D Secure service, most likely, you have to support two primary use cases.

  • The first use case would be for people, who are using your payment page. In this case 3-D Secure verification process can be (in a fairly natural way) incorporated into the existing payment page checkout process.
  • The second use case would be for customers that do not use the payment page (send their queries for transaction processing directly through the API). In this case an additional redirection procedure would have to be introduced to the standard processing mechanism, providing the redirect URL. The mechanism would allow you to redirect the cardholder to the issuing bank and complete the process.


If your payment processing system or gateway has to deal with a lot of e-commerce transactions, it might be beneficial for you to incorporate 3-D Secure verification functions. While implementation of 3-D Secure functionality in the gateway is not a complicated procedure, you should be careful in your choice of an MPI partner for this process.

HSM, Tokenization Appliance, or Both?

As new encryption methods and technologies emerge and evolve, many companies and individuals have questions about specific features of different encryption solutions. In this article, we are going to explain the differences between hardware security modules (HSM) and tokenization appliances. There appears to be confusion in this topic, so we decided to explain what each of the two solutions is and clarify the situation.

An HSM is a physical computing device that safeguards and manages digital keys for strong authentication and provides crypto-processing.

In essence, the device stores the keys and implements certain algorithms for encryption and hashing. It can be used for these functions by external applications, such as payment gateway software.
Particularly, an HSM can be used for:

  • encryption and decryption of card numbers
  • decryption of card PINs
  • verification of card security code (at the back of the card)
  • verification of EMV cryptogram
  • other functions

As an HSM is capable of performing data encryption, particularly (using AES algorithm), many people assume that an HSM is equivalent to a tokenization appliance. However, it is not exactly so. Any tokenization appliance does use an HSM of some sort, but it implements some additional logic on top of it.

For instance, an HSM can encrypt a card number, and generate a token based on one way hashing algorithm. It only stores the encryption key and does not store the token and the encrypted value. Consequently, if a card needs to be processed later, and only the token is available, an HSM is unable to provide corresponding card data, because it doesn’t store all the necessary values within itself.

Another difference between an HSM and a tokenization appliance is that although an HSM stores the keys within itself, it does not control, which key is used to encrypt each value (generate an encrypted value) at a specific moment. Consequently, an HSM does not provide a complete mechanism for rotation of keys, which is required by PCI.

As for tokenization appliances, they can, generally, handle the following tasks.

  • A tokenization appliance has an API for interaction with an HSM.
  • It receives the card number, encrypts it using the HSM, and generate the token
  • It keeps track of the keys which are used for encryption and can rotate them with time
  • It stores the encrypted values and tokens
  • It can decrypt any value from the token (as it “knows” which key has been used to generate the value)

As we see, a tokenization appliance implements the so-called vault functionality, and uses an HSM for data encryption and decryption only. The correspondence between the token, encrypted value, and the key (or, to be exact, the key number), is the vault function, implemented in the tokenization appliance itself, and not in the HSM.

It should be understood, that just an HSM is not an immediate solution of tokenization requirement. If you need tokenization functionality, you need a tokenization appliance. If you need to implement such functions as P2PE, PIN processing, or card issuance, you need to use an HSM. If you need both categories of functions, you have several options to choose from.

  • You can purchase both a tokenization appliance and HSM if your budget allows
  • You can also purchase an HSM and license tokenization software that works with it
  • You can purchase an HSM and develop your own vault software on top of the HSM


Before you make an investment in either tokenization or HSM, be sure to understand your needs and based on the totality of your requirements, make an intelligent and informed decision.

EMV, P2PE, or both?

There is a lot of confusion on how EMV and point-to-point encryption (P2PE) work together and whether one can replace the other, and whether both technologies are necessary. While point-to-point encryption becomes more and more popular and EMV-related liability shift in the US is approaching, more and more questions, regarding both these payment processing aspects, arise.

The purpose of this particular article is to explain the benefits of each option taken separately.

In our previous post on point-to-point encryption we described P2PE as an additional security measure “on top of” EMV standard. However, in some cases, people and companies use point-to-point encryption as an alternative to EMV (which, as we explained here, is much more secure than a magnetic stripe).

Of course, if you want to feel more secure and support different card types, you’re better off incorporating both technologies within your solution.

Usage of EMV without point-to-point encryption is not recommended. Some modern businesses choose not to EMV standard and use P2PE only, in spite of the approaching liability shift deadline.

Let us illustrate the essence of the liability shift with a simple example.


A fraudulent transaction took place, during which EMV card was used. The transaction itself, however, was not an EMV transaction, as the merchant did not support EMV standard (did not have an EMV terminal). Consequently the card had to be swiped, and, as a result, the fraud occurred. According to the current rules, an examination would take place before the liable party is defined. However, after October 15, 2015, the liability would get assigned to the merchant, because it did not have EMV terminals.

As a result, businesses, where payment card fraud risk is higher (such as small convenience stores), prefer to use EMV terminals. On the other hand, businesses, where fraud risk is lower (such as large hotel networks, which verify and retain the copies of all the documents of the cardholder at the time of purchase), may be less “stressed out” by the approaching deadline.
They may choose to implement point-to-point encryption as the primary security measure.

For businesses that already have an existing encrypted swiper based point-to-point solution (and consider fraud a minor threat) investing in the new EMV terminals (and EMV certification) might be a challenge. That is why they choose to invest in liability insurances and stay away EMV for now.


The best option is to use both EMV and P2PE technologies. However, if you already have point-to-point encryption functionality, and, presently, you do not consider fraud your top-priority problem, it is not that critical for you to purchase EMV terminals, go through certification, and try to implement respective solution at all your facilities before the liability shift. So why not just make your shift towards EMV standard more gradual and smooth?