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.

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.

Offline Processing: Store-and-forward

The purpose of this article is to describe the store-and-forward mechanism implemented in payment gateway software in the cases when transaction processing becomes impossible due to temporary loss of connectivity with the processing “back end” (for instance, a bank) or due to some other errors.

As we explained in one of the previous articles, issues with transaction processing might be caused by one of the two conceptually different reasons: timeouts and errors. While the previous article focused on timeout handling, this one focuses on offline transaction processing, which is made possible by implementation of store-and-forward technique.

The essence of store-and-forward approach

Originally, when modems were introduced and connection was not always stable, the so-called offline transaction processing concept was developed. Usually, offline transaction processing is implemented at the level of a payment terminal (as it is a standalone device, independent from the host application). Sometimes, this solution is referred to as store-and-forward. On the basic conceptual level, the terminal stores transactions and, once connection is reestablished, it sends them to the host application for processing. The transaction is not actually submitted for processing immediately, but rather a “fake approval” is generated for the sale to be able to complete. The actual transaction information is then stored and processed once the connectivity is available. The underlying assumption, supported by the general experience, is that the card is going to be processed, and money will be available for the given transaction at a later time.

The advantage of store-and-forward mechanism is that transactions which did not go through at the time of initial attempt can still be processed later, and, in most cases, get approved.

The disadvantage of store-and-forward mechanism is that, sometimes, once the system is operational and the previously stored transaction is reattempted, it gets declined.

The systems which support offline transaction processing have to store credit card numbers for some time. Consequently, operators of such systems need to take care of PCI-compliance and respective cardholder data storage-related issues {link}. As a result, systems which do use offline processing need to implement encryption of track data or other approaches in order to minimize PCI consequences.

Offline transaction processing is most suitable for e-commerce businesses, where a customer does not get purchased product immediately after the purchase, leaving some time for transaction re-processing. The approach is also applicable for service providers (such as newspaper subscription, dating web-site subscription) because, in theory, a service can be terminated (canceled) the next day after a customer ordered it. On the other hand, retail businesses may find it difficult to use offline processing, because once a customer gets the purchased product, it is problematic to track this customer if some transaction processing issues arise after the purchase is made. That is why retail businesses usually utilize the approach only on small amounts (usually, under $50).

There are two common scenarios for offline processing implementation. In retail businesses it is usually implemented at the level of payment terminals, while, in general, the approach can be utilized at payment gateway level as well. Some processors also offer offline processing at the level of their own payment systems. Regardless of the level of its implementation, the general store-and-forward mechanism used for offline transaction processing remains conceptually the same.

Conclusions

Offline transaction processing is a relevant solution for e-commerce businesses, experiencing communication problems with the host payment processing application.

3D Secure Program

The purpose of this post is to familiarize online merchants and other merchant services industry players with 3D Secure program.

In e-commerce transactions, where the card is not physically involved, card fraud is more likely than in retail transactions. Therefore, special fraud protection measures are required, and 3D Secure is one of such.

In essence, 3D Secure is a special XML-based protocol, intended to provide additional security level for online credit and debit card transactions. 3D Secure program is implemented by Visa (as Verified by Visa), MasterCard (as Secure Code) and Amex (as Secure Key) for additional protection of cardholder data. In order to use 3D Secure service for a given card, the card-issuing bank must be enrolled in 3D Secure program.

If the card issuing bank participates (is enrolled in) the 3D Secure program, the cardholder can enroll the card and associate a special password with it. When an online purchase is made with the card, and the web-site supports 3D Secure, then additional authentication process happens, involving additional authentication factor.

The process is as follows. A customer makes an online purchase. When the time comes to pay for the purchase, the customer is redirected to the additional authentication page, where he or she enters his or her password associated with the card. As a result of the authentication a special value is generated, which is then passed to the gateway for the processing of the transaction. This value serves as the additional authentication factor (similarly to two-factor authentication described in our article on google authenticator).

If the password is invalid, the payment is not processed.

The unique value generated for 3D Secure-based authentication, associated with the card, is called Universal Cardholder Authentication Field. Visa and MasterCard implementations of the 3D Secure protocol use different methods to generate it: Visa uses Cardholder Authentication Verification Value, while MasterCard uses Accountholder Authentication Value.

A merchant who wants to enroll in 3D Secure program has to integrate with the MPI-provider and be able to transfer respective values to the payment gateway. When a merchant receives a payment request, a special Merchant Plug In (MPI) component checks if the card is enrolled in 3D Secure program. If the card is enrolled in 3D Secure, the component executes the redirect and the value is sent to the payment gateway for authentication.

The advantage of 3D Secure program for a cardholder is that if a card is stolen it is more difficult to use it for unauthorized online purchases. The advantage of the program for a merchant is that rejection of transactions which did not get through 3D Secure authentication process, potentially, reduces the number of chargebacks issued after unauthorized transactions.

Conclusion

Merchants, handling mostly online transactions and operating with international cards, are advised to enroll in 3D Secure program in order to protect themselves from potential online credit and debit card fraud.

PCI Compliance Levels

The purpose of this article is to familiarize different merchant services industry players with the four levels of PCI compliance, and briefly describe some solutions available for level 4 merchants (the most common category), allowing them to go through PCI certification procedure as smoothly as possible.

As we mentioned in one of the previous articles, any business dealing with cardholder data in some way, has to meet PCI compliance requirements and go through some sort of PCI audit procedure. Depending on volumes of transactions processed (including online transactions) a business is classified as belonging to one of the four PCI compliance levels. Beside processed transaction volumes, a company’s PCI compliance level also depends on predominant card entry mode the company utilizes. There are several card entry modes (determining card industry types), but in terms of PCI compliance levels card entry modes (or card industries) can be divided into two basic categories: e-commerce and other transactions.

Let us briefly review the levels of PCI compliance (as they are defined by Visa), moving from 4 to 1.

How PCI compliance levels are defined

A level 4 merchant is a business processing less than 20 thousand Visa e-commerce transactions a year, or any merchant processing less than a million Visa transactions a year, regardless of card entry mode.
A level 3 merchant is a business processing between 20 thousand and one million Visa e-commerce transactions a year.
A level 2 merchant is a business processing between 1 and 6 million Visa e-commerce transactions a year.
A level 1 merchant is a business processing more than 6 million Visa e-commerce transactions a year, or a business, considered a level 1 merchant by Visa association itself (based on cardholder data security and risk related considerations).
The complexity of PCI compliance certification and PCI audit for a given business are determined according to the level this business belongs to.

PCI compliance-related solutions

In order to meet PCI compliance requirements, merchants, belonging to PCI compliance levels 1,2 and 3 can utilize various solutions (such as tokenization, profiling and others), enabling them to store credit card data and manage cardholder data flow in the most effective way.

Many online businesses, web-sites, and small size merchants, fall into level 4 category, and often look for the most suitable solutions for PCI certification. In this post we focus on this (most common) type of merchants – level 4 merchants, which, according to some sources, handle about one third of the total volume of credit card transactions processed.

In order to meet PCI requirements, level 4 merchants have to fill out the so-called SAQ (self-assessment questionnaire). The type of a SAQ (ranging from A to D) that a given merchant has to fill out, depends on this merchant’s validation type. Basically, the validation type depends on how the merchant handles cardholder data (and whether the merchant stores it or not). More information on merchant validation types can be found here.

Level 4 merchants often utilize the services of other companies (level 1 service providers acting as PSPs in this case) to process credit cards. Particularly, they often rely on payment pages and tokenization services of the PSPs. In most cases the PSP itself would have a special mechanism for level 4 merchants, simplifying the process of filling out the SAQ significantly.

For example, most companies, performing PCI audit (such as Trustwave, Security metrics, CoalFire) have special software packages (or web-based offerings) designed to help level 1 providers that use them for PCI audits to simplify the completion of the self-assessment questionnaires for their level 4 customers.

Basically, an SAQ is a simple *.pdf document. PCI audit companies create special web-portals for level 4 merchants. An authorized level 4 merchant can enter such a portal, submit its SAQ, and identify its payment service provider. After that the fields related to the PSP are auto-filled. These can be the fields denoting particular features (which level 4 merchants might not even be aware of), provided by the PSP itself and not by level 4 merchants from the PSP’s portfolio.

The described arrangement (solution) greatly simplifies the process of PCI compliance certification for both PSPs and their level 4 clients, as well as for PCI auditors themselves.

Conclusion

Before starting to worry about PCI compliance, a level 4 merchant should reach out to its PSP and enquire about the respective automated solution, that the PSP might already have in pace.