Visa mandates that merchants eliminate the use of vulnerable payment applications
Posted on Wednesday, October 24, 2007 by Bryan Johnson
Visa made a pretty significant announcement today that is aimed at eliminating vulnerable payment applications from the Visa payment system.
The objective is to prevent certain prohibited card holder data from being stored and also reduce the number of breaches. If you're new to this topic, here is some context to what Visa is trying to address.
Over the past few years, certain payment applications (primarily Point of sale systems) used by retailers and restaurants have been a gold mine for criminals stealing credit card. These systems have been targeted because they're were known to be storing prohibited credit card information - the exact data that criminals need to make fraudulent purchases and manufacture duplicate cards. Merchants are usually not aware that their systems are storing such data, but they're still held responsible if breached. Credit card information that cannot be stored includes magnetic stripe data, CVV (three digit codes), PIN's, or encrypted PIN blocks.
To address this security vulnerability, which Visa has cited as the leading cause of breaches among small merchants, they announced that beginning January 1, 2008, the first of five mandates will be implemented to start the process of eliminating non-secure payment applications from processing with Visa. In other words, Visa is announcing to merchants they will be unable to process Visa credit or debit cards if their POS system does not meet required security standards and is still storing prohibited data. You can also check the 2nd pdf posted below to see if you current POS version is compliant.
Read the entire press release here (see second pdf below for Visa's updated list of vulnerable POS applications).
Here is list of POS systems with information about their compliance status and any newly released software update information:
This effort by Visa is targeted towards addressing data security for 'swiped' merchants such as restaurants and retailers, which account for the larger portion of the ~3 trillion credit/debit card processing industry. The 'card not present' portion of the industry that includes merchants such as ecommerce, business to business, and mail/telephone order will will either choose to do the necessary upgrades internally to meet PCI requirements or our outsource the storage of credit card data. Other related posts: PCI DSS Compliance basics for credit card security PCI DSS Compliance and the cost of a credit card breach Braintree solutions: The Smart Approach to PCI DSS Compliance
Alternative payment types PayPal, Google Checkout, and Bill Me Later
Posted on Friday, October 19, 2007 by Bryan Johnson
Mercator Advisory Group, an independent research firm in the payments industry, recently completed a study on alternative payments. This is a partial abstract of the report that I thought was very helpful in putting the online and alternative payment space in perspective with the payments industry as a whole:
While retail point of sale continues to be the largest area for consumer payments, online consumer spending has yet to reach its potential from the payment perspective. In 2000 less than 1 percent of sales were via the internet. Today, that spending is likely to be $116 billion in the United States, a full 5% of retail spending. But this annual growth is predicted to slow from 20 percent to 16 percent by year end and further to 13 percent by 2008. As these rates slow, online merchants must meet their customers "where they are" with the right payment mechanisms to maintain the highest possible growth and the widest possible sales funnel. Alternative payment systems are fast becoming an important way for merchants to sustain and accelerate that online sales flow.
This report and most others that analyze the affect of alternative payments show that by implementing additional payment types such as PayPal, Google Checkout, and Bill Me Later, in addition to traditional merchant acccounts, merchants can increase sales by lowering shopping cart abandonment rates. The study is much more extensive in the approach and analysis than what I've called out and these guys have a great reputation for quality work.
PCI Compliance fines for small business breaches
Posted on Thursday, October 18, 2007 by Bryan Johnson
Major breaches like TJX have been widely publicized but breaches at smaller businesses have received very little attention. This is the case because information about these smaller occurrences have been very hard to come by due to two reasons.
First, not all states have disclosure laws requiring merchants to disclose breaches and secondly, Card Associations are not required to disclose individual cases. For this reason, I thought Robin Sidel's recent WSJ article In Data Leaks, Culprits Often Are Mom, Pop , where an actual breach is analyzed, was very helpful in putting the costs and risks of smaller breaches into perspective. Robin, if you're willing to share some of your journalistic research tricks about finding this sort of information, I'm all ears! Here are some of the highlights:
- Since 2005, more than 80% of the credit card breaches have occurred at small businesses.
- Since October of 2006, Visa has levied $3.3 million in fines for non compliance.
- MasterCard did not disclose their fines but I bet Robin could find them!
- Lodi Beer, a microbrewery and restaurant in California had unknowingly stored 11,728 credit card records in their point of sale system. Track data from the credit card's magnetic strip cannot be stored. When that data was breached, Visa and MasterCard fined Abanco, the restaurant's merchant account provider, $27,000. Abanco then in turn passed that fine onto the restaurant. In addition to the fines, this merchant has spent over $50,000 in remediation costs, legal fees, upgrades, etc. That is a huge amount of money for a small business.
There are a few interesting things to note about PCI Compliance and small businesses. First, in trying to get merchants compliant, Visa, MasterCard and the other card brands have put the responsibility squarely on the merchant acquirer (aka the processor or merchant account provider). They've successfully done this with a policy of making them responsible for paying fines when breaches occur.
The second interesting thing to note is that while these merchant acquirers are responsible for fines, they will almost always pass whatever they're fined onto the merchant. Finally, if merchants are ultimately responsible for the fines, it would be helpful if they could get a heads up as soon as possible so they could act accordingly.
To this end, I know acquirers have been trying to reach out to their merchants. One strategy has been including warning messages on monthly processing statements, which are never read anyways because merchants gave up long ago trying to read those undecipherable things. I've seen others announce, again via monthly statements, the availability of educational conference calls to explain the risks and process of becoming complaint.
I'm not critiquing the outreach, rather just highlighting the difficulties small businesses face in gaining a proper understanding what they have at risk. The owner of Lodi Beer said it best, "All someone had to do is tell us you can't do that. We would have changed it." Anyway you look at it, helping 7 million businesses become compliant, 85% of which are small businesses, is a tall order.
Other related posts:
PCI Compliance and the cost of a credit card breach
PCI Compliance basics for credit card security
Braintree solutions: Simplified PCI Compliance through remote storage of credit card data
Using tokenization to secure credit card data and meet PCI Compliance requirements
Posted on Friday, October 12, 2007 by Bryan Johnson
PCI Compliance requires that merchants properly protect credit card data. The difficulty with that requirement is that storing it onsite often requires expensive hardware and software upgrades. Tokenization provides an alternative to expensive on site storage and allows merchants to store all sensitive customer data remotely in a PCI Compliant environment, without spending money on any upgrades. IT Security expert Joel Dubin explains it well:
Tokenization is a technology that enables a token to replace a credit card number in an electronic transaction. This token or reference number is meant to prevent the theft of the credit card number during electronic transmission and storage of a transaction. Since the reference number can't be used for transactions or fraudulent charges, there is little harm done if it's stolen.
Tokenization [can make] systems compliant without costly changes by using a 16-digit randomly generated number resembling a card number. The only numbers from the original card are it's last four digits, which become the first four of the token. Using only these four numbers, the token is still PCI compliant.
For credit card processing, merchants get a unique token associated with the information that was submitted to an off-site vault. This unique customer identifier can then be used to remotely initiate transactions and change or delete files. Using this technology, merchants can completely eliminate the need to store credit card information on site. Using tokens is not limited to storing credit card information. It can be used to store all sensitive customer information including banking account information, drivers license numbers, social security number, image documents, and just about anything else.
Other related posts:
PCI DSS Compliance basics for credit card security
PCI DSS Compliance and the cost of a credit card breach
Braintree solutions: The Smart Approach to PCI DSS Compliance
Businesses paying big money to become PCI Compliant
Posted on Tuesday, October 09, 2007 by Bryan Johnson
UPDATE: I've updated my previous post on this topic so it now has all of the information below and more.
As a follow up to a post I wrote earlier this week about the cost of PCI Compliance, I read an article in the Wall Street Journal that had some good data about what businesses are spending to become compliant. The authors profiled Guitar Center, a company that has 210 stores nationwide. The company was cited as having spent nearly $500,000 purchasing monitoring software, security tolkens, and wireless security software. I'm sure that there are other technologies they purchased but were not mentioned. They also reported estimates from Gartner that the average Level 1 merchant, who by definition processes more than 6 million card transactions annually, spent on average $568,000 on technologies needed to become PCI compliant.
This year alone the spend among the largest companies to become compliant will be in the range of $400 to $500 million. Level 2 merchants, those that process between 1 million and six million transactions annually, were estimated to have spent $267,000 on technology to become compliant. Keep in mind that these figures only include technology costs and not time and effort of researching and implementing the solutions. It also excludes the opportunity costs of having the same people working on other company money making initiatives.
Merchants are prohibited from storing CVV, CVV2, CVC2 & CID per PCI standards
Posted on Monday, October 08, 2007 by Bryan Johnson
A Card Verification Value code, CVV, (CVV2 for Visa, CVC2 for MasterCard and CID for AMEX) is the three or four digit number located either on the front or back of a credit or debit card. Merchant's can request the CVV code from card holders as another way to screen fraudulent transactions. The idea is that someone using a stolen credit card is less likely to have this code so they will be unable to complete the transaction. With most payment systems, you can adjust settings to automatically reject transactions where the CVV code does not match the card number.
The effectiveness of this code is limited to the ability to keep it out of the hands of hackers and thief's, which is why it is prohibited by PCI Standards from being stored. For merchants who charge customers on a recurring basis, the CVV code can be used with the initial transaction but cannot be stored for future transactions. The use of the CVV code does not affect the rate you are charged. It only helps with reducing fraudulent transactions by verifying the identity of your customers. The CVV code is not needed to handle chargeback requests. So if you're currently storing CVV numbers, it may be a good idea to reassess your procedures and delete them from your system as soon as possible. Here is a simple graph demonstrating what can and cannot be stored.
Other related posts:
PCI DSS Compliance and the cost of a credit card breach
PCI DSS Compliance basics for credit card security
Braintree solutions: The Smart Approach to PCI DSS Compliance
Track data cannot be stored per PCI regulations
Posted on Thursday, October 04, 2007 by Bryan Johnson
Merchant accounts are prohibited from storing "track data" that is recorded from swiped transactions. Track data is the information encoded within the magnetic strip on the back of a credit card which is read by the electronic reader within the terminal or point-of-sale (POS) system.
When a credit or debit card is swiped, the track data may include customer name, credit card number, expiration date, CVV number (three and four digit code), and in the case of a debit card, the PIN number. Of that information, the customer's name, credit card number, and expiration date may be securely stored according to PCI regulations if the merchant chooses.
Under no circumstances can the CVV code or PIN number be stored. They must be deleted by immediately following the authorization. One problem has been that certain POS systems have been collecting prohibited information without the merchant knowing. Hackers find out what POS systems are storing this information and then target the retailers who use that particular system.
The second problem has been that merchants have misunderstood what information they actually needed in order to process transactions. For example, some merchants have been working under the incorrect assumption that the CVV code was necessary to store after the original transaction. Most POS vendors who have systems that capture and store that information have been scrambling to make sure that they and their customers are making the appropriate adjustments to become PCI Compliant. Here is a simple graph outlining what data can and cannot be stored according to PCI Regulations.
Other related posts:
PCI Compliance and the cost of a credit card breach
PCI Compliance basics for credit card security
Dec. 31, 2007 is the next PCI Compliance deadline
Posted on Thursday, October 04, 2007 by Bryan Johnson
Now that the 327 Level 1 merchants appear to be getting closer to PCI Compliance, Visa is now setting their sites on Level 2 merchants that are defined as processing 1 to 6 million Visa transactions annually. There are currently 729 merchants in this category. As of August 31st, 38% were validated and 44% had submitted initial validation but were in remediation. Other related posts: PCI DSS Compliance basics for credit card security PCI DSS Compliance and the cost of a credit card breach Braintree solutions: The Smart Approach to PCI DSS Compliance
Sept. 30, 2007 deadline passes for PCI Compliance
Posted on Thursday, October 04, 2007 by Bryan Johnson
Sunday, September 30th was the deadline for the 327 Level 1 merchants to demonstrate PCI Compliance. Businesses that process more than 6 million annual Visa transactions are considered Level 1 merchants. Visa reports that 44% of those merchants were compliant as of August 31st. The remaining 177 Level 1 merchants had submitted plans but were working on remediation prior to gaining official compliance. Visa had instituted two types of penalties for merchants who did not meet the deadline. First was higher interchange fees and second was monthly fines up to $25,000 per month until compliance was achieved.
Reasons why higher credit card fees are charged
Posted on Wednesday, October 03, 2007 by Bryan Johnson
There are quite a few ways that merchant service providers can structure the pricing of credit card fees.
Some companies will offer a 'Qualified' rate of something like 2.69% and $.30 and then a 'Non Qualified Rate' of 3.47% and $.30. There are similar variations with three and four different categories instead of two. Sometimes companies will offer a category only for 'Debit' cards and other times they will bundle the credit and debit card rate into one. Neither one is necessarily better than the other. It just depends on what the other categories are and the price of each.
Merchant service providers can typically choose any of five or six different pricing structures when offering credit card processing services. Regardless if you have two, three, or four different rate categories, there are reasons why certain cards will be charged the respective rates.
Most of the time, if you process a consumer credit or debit card and you successfully capture their correct billing address (known as Address Verification Service, or AVS) the transaction will fall into the 'Qualified' bucket and get charged the Qualified rate. If you don't correctly capture the billing address, then the transaction will be 'downgraded' and will fall into a category with a higher rate.
Corporate, business and international cards typically fall into the higher rate categories regardless of whether AVS is captured. Some rewards cards also fall into these higher categories. Other reasons why transactions may be assessed a higher rate include not settling transactions within 24 to 48 hours, authorizing credit cards and then capturing them after a predetermined amount of time, and authorizing a credit card and then capturing it for a different amount. While there are some standard guidelines in the industry, processing companies have discretion about what types of cards fall into what categories and for what reasons.
So in this regard, it's always difficult to do a direct comparison from one provider to the next. It's helpful to always understand all of the different categories that your provider will be charging and the general guidelines they've assigned to each.
