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.
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.
Conclusion
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.
Recommended to you
