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 ( 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: Cardholder Data Flow

This is the final installment in a mini-series of posts dedicated to PCI compliance. The purpose of this particular article is to familiarize merchants that have to accept payment card data and store it, so that their software is involved in cardholder data flow, with some solutions, allowing them to improve their flexibility in terms of PCI compliance.

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

The general solution, allowing merchants’ front-end software (web-site\CRM) not to be involved in cardholder data flow is to avoid touching credit card information. There are three ways to accomplish this: using a filter, using a hosted payment page (PayPage) or using a server request interceptor.

Cardholder data filter

When a merchant has a big and complex application with many different data flows, and it is desirable to take the application out of scope, it is possible to reconfigure the system in such a way that all of the incoming and outgoing messages are going through a sanitizing filter (so that the main application is connected to the outside environment only through this filter). The filter could use some sort of algorithm cleaning the credit card information from the incoming messages (replacing it with tokens) and inserting credit card information into the outgoing messages.

This scenario is intended for more complicated systems that need to receive messages from clients and exchange messages containing credit card data with other systems.

This filter solution is a server-oriented one, capable of reducing the PCI scope of a business (because the filter application is still touching the credit card data) but not of completely eliminating its PCI responsibility.

Hosted payment page

Hosted payment page is a common solution for smaller applications that simply need to process payments (and require credit card information only for that).

If the needs of the merchant are confined to accepting payments in a secure way and keeping its own front-end application out of scope, it can rely on a hosted payment page to collect credit card data.

In essence, a PayPage is a web-page that contains fields to gather credit card information. The merchant supplies the payment amount (how much to charge) and description (what to charge for) to the PayPage, and the PayPage collects credit card information and then processes the transaction (pushing the result back to the merchant via callback).

For example, a merchant has a shopping cart as part its own web-site. At the time that payment needs to be collected, a redirect to the PayPage occurs (specifying the payment amount and the information on what the payment is charged for). The PayPage (residing on a PCI-compliant server of the merchant’s payment processor) takes care of the rest. The user enters credit card information and the merchant gets a payment confirmation, or transaction response, which might include token for the merchant to store if it needs to reuse the card in the future.

Server request interceptor

An interceptor is somewhat similar to the filter, only it operates on the client’s side and is used as a solution for web-applications. The interceptor is a script (usually, Java script) residing on a PCI-compliant server, that attaches itself to a static form (responsible for taking in credit card information), and is able to intercept the request when the customer puts in all of the information and hits the “Submit” button. The form gets rendered, the user enters credit card information and submits the form. The script then intercepts this request and sanitizes it by dynamically extracting the credit card information, converting it into tokens and re-inserting them in the request, that is subsequently sent to the server.

Since the page itself is static, the interceptor script itself comes from a PCI-compliant server and the request hitting the server no longer has the credit card information in it, the entire application is, technically, out of PCI scope.

Conclusion to the PCI compliance mini-series

Although the final decision is always made by the assessor\auditor (especially, when a merchant is processing large volumes of transactions), there is a whole range of solutions allowing merchants to reduce their PCI scope or get out of it. So, even if a merchant doesn’t have resources to go through the full PCI audit, there are still ways allowing the merchant’s business to accept credit cards.

Our development has experience of using all three types of techniques, so if you need an advice on implementation of any of the described solutions, do not hesitate to contact us via our “ask question” page.