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.


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.

Credit Card Fraud Protection Tools

The purpose of this article is to familiarize the key merchant services industry players with the main credit card fraud protection tools. Before credit card payment industry emerged, criminals physically robbed the banks. With the advance of e-commerce and online payment market bank robberies were partly “replaced” by fraudulent transactions of different types. Expansion of electronic payment industry was followed by the expansion of credit card fraud. As a result, a necessity for credit card fraud protection tools emerged. These tools are intended to minimize fraud possibility and prevent potential losses of funds, resulting from such fraud.

Some information on importance of credit card fraud protection tools in payment gateway software can be found in respective article.

Here we are presenting an overview of some popular and useful credit card fraud protection techniques, arranged into several groups.

Geographical Location Based Techniques

IP Geolocation

The technique is based on pinpointing the customer by his/her IP address location. If transaction comes from a high-risk (untrustworthy) geographical location, it can be considered a risky or potentially fraudulent one.

Proxy Detection

The technique involves flagging high-risk IP addresses, suspicious proxies, as well as satellite connections serving high-risk geographies.
Some fraudsters are capable of evading IP geolocation controls by using proxies to spoof their IP addresses. Proxy detection helps to identify spoofing. Proxy Detection tools detect both anonymous and open proxies (these are compromised computers that allow traffic to be routed through them). Open proxies are often used for online credit card fraud.

Card Profile (Bank Identification Number)

The technique involves verification of the information on the credit card, such as card association, issuing country, bank and card type (e.g.credit card, debit card, prepaid card).
For instance, if a merchant does not want to accept foreign-issued cards, or if the issuing country comes from a high-risk region, then respective transactions can be declined.
The information, represented in credit card BIN (6 to 9 digits of card number) allows merchants to make informed decisions related to transaction processing. More detailed information on credit card BIN and intelligence as payment gateway software features can be found in respective article {link}.

Techniques Based on Accuracy of Customer-supplied Data

E-mail Identity Verification

The technique involves verifying whether the customer’s e-mail address is linked to the customer’s name and address. It is always useful to check whether the address is valid, and whether it actually exists or not.
If customer’s identity is not confirmed with the e-mail used for a purchase, the purchase can be declined.

E-mail Profile

The technique involves verification of such characteristics as gender, age, and location associated with the email. As in the case of the previous technique, it is worth checking, whether the e-mail is valid or actually exists.
If information obtained based on e-mail does not coincide with the data specified by the customer during the purchase, the transaction can be declined.

Telephone Profile

The technique involves verification of phone type (e.g. Voice over IP (VOIP), prepaid cell phone) and location associated with the phone number. While stationary home phone is associated with a specific place within a given country, VOIP can be used at any location. Consequently, usage of a VOIP phone can be considered a sign of potential fraud. This criterion itself can not be considered a decisive one, but it can be taken into account in combination with some other fraud signs, if they are present.

Reverse Address Lookup

The technique involves verification of the name(s) associated with the shipping and billing address. If an e-mail specified in the order does not correspond to shipping and billing addresses, the transaction can be considered a high-risk one, and the order can be declined.

Professional Social Network Lookup

The technique involves verification of such information as company (or individual customer’s) affiliation, location, and potential mutual connections on professional social networks, such as LinkedIn and others.
If the number of potential connections come from high-risk locations, or is too few, then additional checks may be necessary.

Other Techniques

Risk Scoring

Risk scoring (or fraud scoring) technique involves usage of a third-party service which performs an overall risk assessment of a transaction. Assessment results serve as a guideline for the merchant to decide whether to approve this transaction or not.

Website Traffic Information

The technique involves verification of traffic and linking information, which are necessary to determine legitimacy of company or e-mail domains. The obtained information on a companies and domains can be used to check e-mails coming from the domain, used for the purchase, and, potentially, check the company, in the name of which the order was made.
For example, web-sites with large volumes of non-human traffic are marked respectively and analyzed for potential fraud.


The technique involves verification of billing and shipping address locations via satellite or street view.
If the two addresses are completely different (for instance, locations are situated in different countries), additional checks may be needed for the order.

Domain Registration Lookup

The technique involves verification of the registration information of the website or email domain. For example, if a domain is unregistered, registered abroad, or if a test e-mail is returned by mail delivery system, then the respective domain should be considered a suspicious\questionable one.

Visit the UniPayGateway website if you are interested in the diagram illustrating this topic

Payment Concepts: Payment Card Data Storage

This article is the second one in a mini-series describing recommendations to be considered by merchants interested in attaining PCI compliance. In this installment we are going to look into the reasons behind payment card data storage and possible solutions that make PCI audit more simple.

If you have not read the intro, we recommend that you start with it, as it will improve your understanding of the current post.

Reasons behind payment card data storage

There are several reasons for payment card data storage:

  • for reporting purposes and to look up previous transactions
  • for issuing of refunds
  • for repeat purchases and recurring billing

Let’s take a closer look at each of them.

Payment card data storage for reporting and transaction lookup

The question to consider here in terms of payment card data storage is whether it is really necessary to store credit card numbers for future transaction lookup.

If a business is storing the info for reporting purposes without actually doing anything with the card number, it can just store a part of that number (for some merchants it might be sufficient to store just the last 4 digits, solely for identification purposes).

For lookup purposes by full account number merchants can use one-sided hash (information on hashing algorithms can be found here. A common way is to use SHA-256 hashing function with multiple iterations and salt to ensure that the data is hacker-proof.

The hash value is unique, the number of iterations is difficult to guess, and the salt is difficult to crack. Even if the hashing algorithm was determined, the number of iterations established, and the salt guessed, it would still take a considerable amount of time to decode card numbers using brute force approach.

Generally, storage of the last 4 digits and one-sided hash is considered acceptable, but the final “verdict” will depend on your specific auditor.

Payment card data storage for issuing of refunds and transaction settlement

In some cases, merchants would process credit card transactions and store payment card data in order to be able to issue a refund (return money) on the card if the cardholder returns merchandise. Sometimes, certain processors will require full credit card information to settle transactions at the end of the day.

In both cases (refund and settlement) merchants need to consult with the current payment gateway or payment processor to see if there is an alternative option to return money or to perform settlement.

If a merchant needs to return money to a customer, many present-day processors and gateways support refund operation using reference number. When the original sale transaction is processed, a reference number is returned back to the merchant. Subsequently, it is possible to issue a refund passing only the reference number back to the processor, and effectively returning money for that transaction without supplying the original credit card number.

Those, experiencing the problem around settlement (usually, associated with terminal capture) should consult their current payment gateway and see if there is a host settlement (capture) option available that would eliminate the need for sending credit card information at settlement time.

Payment card data storage for repeat purchases and recurring billing

The most common payment card data storage solution for repeat purchases and recurring billing is tokenization. Instead of getting and storing the credit card number, businesses, wishing to have support for repeat purchases and recurring billing, are getting a token from a PCI-compliant tokenization provider. Thus, they can store a token instead of the card number, and reuse it in subsequent transactions\purchases, while reducing their PCI scope.

The concept of tokenization and respective options available to merchants for effective payment card data storage and PCI scope reduction will be covered in the next post.