As you read and familiarize yourself with the payment card industries risk and fraud best practices there are several ideas and theories that certainly can and do help mitigate risk.  Although, one such practice often seems overlooked, card transaction declines.  Card transaction declines can be very insightful and help prevent chargebacks and losses.  This practice, like many others, just takes a little bit of time and understanding to develop.

Decline reason codes are a first line of defense against fraudsters using stolen cards.  “Hold-Call” or “Pick up Card” decline codes are obviously very direct and paint a clear picture for a merchant.  Merchants who understand these messages and can tie them to more than just one specific transaction will have discovered a great tool in helping eliminate disputes.   The ability to tie these decline codes to a customer, IP address, physical location, or the like will be able to not only avoid the initial fraudulent order, but will be able to prevent the fulfillment of orders to the seemingly endless supply of other stolen cards a fraudster may be using.

Unfortunately not all declined card transactions are as clear as the codes described above.  In those instances rates and velocities can be very useful.  Decline rates can vary greatly from merchant to merchant, but certainly should not be overlooked.  Excessive card declines from a specific IP address, physical location, city, state, or even for a specific item you are selling should all be red flagged.  This will allow you to take a closer look at certain transactions and customers, giving you a greater opportunity to more thoroughly review those higher risk instances.

“While companies struggle to achieve and maintain compliance with the PCI DSS, data breaches continue nearly unabated.  From Eastern European organized crime rings to state sponsored cyber crime, companies today are facing an increasingly dangerous and skilled adversary.   Compliance with the PCI DSS is required and important.  Unfortunately, achieving compliance can be a complex task.   Join the International Payment Forum and noted payment security expert and former QSA trainer, Chris Mark for a webinar on the state of data crime and PCI DSS.  Chris will discuss recent data compromise trends and provide an overview of the PCI DSS and offer real life advice on how to minimize the cost and complexity of achieving compliance.”

To register…click here.

Since this blog is intended for all sizes of companies, we would like to add some helpful advice for our smaller merchants.  If you have a website or blog it is very helpful to know the amount of traffic that is viewing your site and from where the traffic originates.  There are a number of services that can be used.  The most popular is probably Google analytics.  Additionally, Onestat (www.onestat.com) is very nice.  I have personally used for years on my sites.  This blog is tracked by Sitemeter (www.sitemeter.com).  If you are currently running a website without analytics you are really  not doing yourself or your company justice.  The solutions referenced in this email can track time, pages visited, and location of the user.  Some of the information is very useful.  For example, you may be able to see if a prospective customer visited your site or if a competitor has been on your site.  That being said websites, and the Internet in general, are in the ‘public domain’.  This means that even if don’t like someone visiting your site you should block them or ensure that you don’t post anything sensitive on your website.   The analytics is very useful to gauge the effectiveness of press releases, speaking events, and other marketing efforts.  For example, after a recent newsletter broadcast, I could tell that over 100 people visited our site within several hours.  This is interesting information that can help tune marketing efforts and messages.

For years, the National Retail Federation (NRF)has been arguing that retailers have been required by their acquiring banks to keep full account numbers on file for use in dispute resolutions. This simplifies the process for the acquirer, allowing them to search and find transactions that may be in question. The challenge with this practice, though, is that it significantly increased the merchants’ risk. Requiring them to maintain records of full account data, meant that retailers had to spend tremendous amounts of money and resources to protect that data and to achieve, validate and maintain PCI DSS compliance. Large merchants struggled with the complexity of their systems and the amounts of data resident within them, while small merchants often wrestled with unfamiliar technologies designed to keep data secure.

On March 31, 2009 Dave Hogan of the NRF had the opportunity to express his frustrations to Congressional Committee convened to hear testimony on the effectiveness of the PCI DSS. In his testimony, he addressed the confusion in the industry around what was required of merchants in order to process a chargeback, or identify a fraudulent (or suspect) transaction. He stated that merchants were, in fact, required by their banks (who said it was required by the card brands) to maintain that data. The card brands fired back that they required no such thing. The banks and the card brands were pointing fingers, with the merchants caught in the middle.

Last week, Visa put a decisive end to the debate. In a joint statement released with the NRF, Visa clarified that merchants are not required to store the account information. Specifically, the statement reads “The unnecessary storage of full card PAN information by merchants has led to incidents of data compromise, theft or unintended disclosure during disposal… To clarify, Visa does not require merchants to store PANs, but does recommend that merchants rely on their acquirer / processor to manage this information on the merchants’ behalf.”

This statement is a great relief to merchants across the country. For several years, Visa in particular, and the industry at large, has been advocating that merchants should reduce to the greatest extent possible the amount of cardholder data that is stored. This clarification, as Hogan states, “is a promising step.”

Visa has once again taken an industry leadership position by releasing tokenization best practices. While not always the case, historically Visa has released best practices prior to making those best practices actual requirements. The PCI DSS was previously the CISP which, until about 2003, was a best practice. The PA DSS was previously the Payment Application Best Practices (PABP).

Visa has publicly stated that they support data replacement.  As stated in the document:

“Visa supports tokenization as a means of replacing Primary Account Numbers (PANs) with non-sensitive surrogate values (known as “tokens”) to eliminate or reduce storage of cardholder data.”

ProPay is proud to say that our ProtectPay solution complies with Visa’ Best Practices already and we will continue to work to ensure that we lead the industry by providing a robust, flexible, secure solutions to help companies protect data while simultaneously reducing the regulatory compliance burden.

We are glad that Visa is being proactive and taking such a leadership role as it will help ensure the security of merchants and will allow companies to better protect cardholder data.