Merchant Fines?

Every now and then I come across someone wondering how fines work in the merchant service arena. Here is an example:

I keep seeing the mention of these fines. Who has the power to levy these fines on places that are non compliant? What makes them think they will actually be able to collect?

This is a good question. This is a very good question. In a security summit my company hosted last year, we put together a round table discussion with Visa, MasterCard, AMEX and the attendees, a similar question was posed. The answer was a little vague and it goes like:

VISA/MasterCard – The initial response was that Visa's and MasterCard's legal agreements are between them and the member banks, not the merchant so Visa and MasterCard does not have the ability to fine merchants, they can only fine the member banks. But, after some follow-up questions and prodding, they stated that their agreements with the member banks does not prohibit the member bank from passing the fine down the chain until it gets to the merchant. Most all agreements in this chain have some sort of "hold harmless" clause and it's this wording that end up placing the fines in the merchants lap. So while Visa and MasterCard do not fine the merchant directly, indirectly they are the one imposing them.

AMEX – American Express' agreements are much more straightforward, most AMEX agreements are between AMEX and the merchant. In this case, AMEX would be imposing any fines directly and hold harmless clauses are not in the mix.
Part two of the question above, what makes them think they will actually be able to collect? Well, merchant agreements are legal and binding contracts so not only can your merchant bank freeze your accounts to cover any fines, they can make your life legally miserable. In addition, many merchant agreements require personal guarantees, which can add to the miserable factor.

Bottom line: read your merchant agreements carefully and do your best to comply with all the requirements. Just like with the law (maybe more so), ignorance is no excuse.

Payment Tidbits

Well, I've been ignoring my blog long enough. I've been dragging my feet because part 3 of A Better Mousetrap series is a little larger than I anticipated, mainly because I want some pretty diagrams and I'm barely proficient at graphic programs. Anyway, I've decided it's my blog and I'm going to go slightly out of order – hopefully this won't kill anybody. I will be doing part 3, just not today.

Does ABC POS System have hidden fees?

Recently I was involved in a thread where the question was asked, "Does ABC POS System have hidden fees?" (While the question posed is real, the names have been changed to protect the innocent). The dialog quickly went from "ABC dealers not disclosing that they use a gateway for payment processing (and the associated fees)" to "payment gateways are unnecessary." My opinion may be biased on this subject but bias or not, there are definite advantages for a POS vendor to use a gateway as opposed to a direct interface to a payment bank/processor.

Let me start my argument by stating that all payment gateways are not created equal. All the advantages I list here are gained by using a reputable, reliable, secure and full-featured gateway provider (hereafter referred to as "good gateway"). Obviously, I believe that Shift's $$$ ON THE NET offering meets this criteria. There might be others but that is another topic that can be discussed on someone else's blog.

In no particular order, here are some of the advantages for a POS solution to use a good gateway provider as opposed to a direct interface:

• Security - a good gateway can increase to level of security in a POS application ten fold. One security "best practice" is to only store what is absolutely necessary. Not storing payment details, like actual card numbers, greatly lowers the merchant's exposure to compromising sensitive data. In the event the POS application data files are ever stolen, even if the files are encrypted (which is required), current regulations require the merchant to notify law enforcement AND the customers (via their merchant bank) because the encrypted data has the potential of being decrypted. If the POS application does not store this information, notification is not required – saving both legal costs and reputation (although, Shift4 would still recommend notification of law enforcement).


• Auditing - a good gateway will allow for pre-settlement or pre-capture auditing. Pre-settlement auditing allows the merchant to make corrections to transactions in a batch before they are sent off to the merchant's bank account. There are several reasons for this including: 1) system or communication failures that resulted in missing or double posted transactions, 2) a layer of protection against trusted employee fraud, 3) a layer of protection against simple data entry or posting errors by clerks. Many people assume that accidentally posting a $100 sale and later posting $100 credit is a wash – WRONG. There are fixed transaction fees associated with both sale and credit transactions as well as a discount rate applied to sale transactions that you do not get back when the credit is issued. This $100 example will cost the average merchant about $2 (not including labor of charge-back fees if it went that far). If post settlement corrections are common, these fees can add up fast.


• Archives - a good gateway will provide a minimum of 90 days of archives. These archives can be used for charge-back defense, fraud control and even sales analysis or sales forecasting.


• Batch Resubmittal - while not common, occasionally batches of transactions get lost, have data content issues or merchants experience bank/processor setup issues that prevent submittals. Without a good gateway in the middle the only resolution is to rekey the entire batch. With today's security regulations where full card information should not be printed on drafts and vouchers, rekeying may be impossible resulting in a loss of funds.


• Bank & Processor Neutrality - with a good gateway, merchants can shop around for their best rates and services whereas direct interfaces lock you into a particular merchant service provider OR add substantial fees if the merchant uses a non-preferred provider. A good gateway will make a merchant service provider switch transparent to the POS application and should not burden IT staff or operations.


• Support - a good gateway can offer a much greater level of support than a POS vendor (who most likely does not have a great expertise in payment processing) and a Bank/Processor (who most likely does not have ANY expertise in POS applications). Good gateways will provider 24x7 support which can compensate for a POS provider that does not offer 24x7 or a Bank/Processor that does not offer 24x7 support. A good gateway provider has expertise in dealing with both POS vendors and Banks/Processors. Most POS vendors do not know the differences between EIRF and CPS Retail nor should they have to; this is something a good gateway knows and/or can diagnose. Processors provide very limited help in diagnosing qualification vs. non-qualification rate issues. Believe it or not, I've personally worked with several banks that could not help with these types issues.


• Merchant Advocate - this could be lumped into Support but a good gateway will have the merchant's best interest in mind, not the POS vendor and not the Bank/Processor. This could be in diagnosing an occasional POS interface issue to being charged excessive non-qualification fees by the merchant bank.

All things being equal, a POS application using a good payment gateway has much more value to a merchant than the same POS application using a irect interface to a Bank/Processor. Smarter POS vendors will focus on their forte – POS - and incorporate their gateway provider's expertise and features into the overall POS solution.

A Better Mousetrap - Tokenization - Part 2

This is Part 2 of a three part series on tokenization and how it can be used to help secure payment processing. Part 1 described what tokenization is and how it is stronger than encryption for storing card information. This part details which sections of the various card association security programs tokenization addresses and how it simplifies compliance. Part 3 wraps it all up with real world examples on how tokenization is used.
Here I will detail three security programs (actually one or two depending on how you look at it, read further): Card Holder Information Security Program (CISP), Payment Applications Best Practices (PABP) and Payment Card Industry Data Security Standard (PCI/DSS). While other card associations may have their own security programs, most of the major associations recognize these three security programs as the standard.
I'll note that I am detailing the USA version of these security programs and where tokenization applies. There is also an International equivalent, Account Information Security (AIS). From what I have read, the programs are similar, but I have not directly compared the differences between the two but the same advantages should apply. Please note that the advantages described here are from the viewpoint of the POS application vendor or provider, though merchants reading this post will see the benefits of using tokenization techniques.
Card Holder Information Security Program (CISP)
CISP is an all-encompassing, ever-changing, security program. PABP and PCI/DSS are parts of CISP. I originally mentioned CISP as a separate program because of the confusion in the industry. Many people see "CISP" come in from one direction and "PABP" or "PCI/CSS" from another direction so in their minds, these are simply "Additional security mandates I must comply with." In reality, they are all requirements of the same program focusing on different aspects but with a common theme: cardholder information security.
Payment Applications Best Practices (PABP)
This part of CISP focuses on application and merchant security best practices. While these are called "best practices," in reality, they are requirements that the applications used by the merchant and the policy set by the merchant must meet or exceed.
For brevity, I will only detail the top-level requirements and I will highlight the requirements that tokenization either fully addresses or helps address. Each of these top-level requirements is a group of rules pertaining to the topic and I encourage you to read the complete PABP requirements. A fully certified Shift4 API addresses many of these requirements but, for the purposes of this article, I will only highlight the items addressed by tokenization
PABP Requirements

1. Do not retain full magnetic stripe or CVV2 data.
2. Protect stored data.
   Here is where tokenization excels. As I hope I have shown in Part 1, tokenization is stronger than encryption.
3. Provide secure password features.
4. Log application activity.
5. Develop secure applications.
6. Protect wireless transmissions.
7. Test applications to address vulnerabilities.
8. Facilitate secure network implementation.
9. Cardholder data must never be stored on a server connected to the Internet.
   With tokenization, you are not storing card information so you are free to store tokens anywhere, either encrypted or plain text.
10. Facilitate secure remote software upgrades.
11. Facilitate secure remote access to application.
12. Encrypt sensitive traffic over public networks.
13. Encrypt all non-console administrative access.

Payment Card Industry Data Security Standard (PCI/DSS)
This part of CISP focuses on data center and merchant security. These rules are divided into 12 sections and are sometimes called the digital dozen. All merchants should strive to meet the requirements of these rules but only certain merchants (like processors and gateway providers, larger merchants and merchants that have been hacked) must undergo a third party audit for compliance, usually annually. As a merchant, if you are a widely known national or international merchant, I recommend that you have annual audits to offset some potential risks if your security is breached. With tokenization these risks are reduced even more, possibly eliminating the risk altogether.
For brevity, I will detail the top-level of the digital dozen and where and how tokenization addresses them. Each of these top-level requirements is a group of rules pertaining to the topic and I encourage you to read the complete PCI/DSS requirements. As I did when detailing the PABP requirements, I will highlight the requirements that tokenization either fully addresses or helps address. And just like with PABP, a fully certified Shift4 API addresses many additional requirements, but I will only highlight the items addressed by tokenization
PCI/DSS Requirements

1. Install and maintain a firewall configuration to protect data.
2. Do not use vendor-supplied defaults for system passwords and other security parameters.
3. Protect stored data.
   Same requirement as in PABP so the same advantage - Here is where tokenization excels.
4. Encrypt transmissions of cardholder data and sensitive information across public networks.
5. Use and regularly update anti-virus software.
6. Develop and maintain secure systems and applications.
7. Restrict access to data by business need-to-know.
   Many of the "need-to-know" requirements are met if only the tokens are stored as they do not contain sensitive cardholder information nor can they be used to access this information.
8. Assign a unique ID to each person with computer access.
9. Restrict physical access to cardholder data.
   If only tokens are stored, then restricting access to cardholder data is moot - there isn't any cardholder information.
10. Track and monitor all access to network resources and cardholder data.
    As with #9, the cardholder data side of this requirement is taken care of when using tokenization.
11. Regularly test security systems and processes.
12. Maintain a policy that addresses information security.

Conclusion
While the highlighted items don't seem like much, the non-addressed requirements are mainly common sense or most likely already addressed. The peace-of-mind in knowing that you are not storing cardholder information should be enough to justify the need for implimenting tokenization. Otherwise, throw in the cost of developing and implimenting need-to-know access levels, data usage monitoring and reporting to the POS application and helping merchants define user access policies as required by PABP and PCI/DSS, then the need for tokenization should be evident.
An additional marketing advantage of tokenization is a friendly explanation of how your application secures cardholder data. "The application does not store cardholder information and instead uses tokenization" is much easier to explain or put on a brochure than "The application uses 128-bit Triple DES to encrypt all cardholder data and the encryption keys are securely stored using a hard coded encryption key in the registry" (huh, how is that secure?). Or you simply don't mention key storage and hope no one asks!
I have shown you where tokenization fits in the CISP requirements and how it can simplify the compliance for POS vendors and merchants. Please check back for Part 3 of this series where I will give real-world examples of tokenization in action, with pictures! If you have any comments or questions on this topic, feel free to post them. Until next time…

A Better Mousetrap - Tokenization - Part 1

Back in October 2005, Shift4 announced "tokenization" capabilities in its $$$ ON THE NET product and at the same time release the tokenization technology to the public domain (Shift4 Releases New Technology to Insure the Security of Its Merchants' and Partner's Payment Processing). Two months later, Dr. Heather Mark, Ph. D., CISSP, published a white paper on the difficulties and weaknesses of encrypting data and the benefit of using a "tokenization" technology (Storing Credit Card Data: A Look at the Business Needs, Regulations and Solutions Surrounding the Issue). In this posting, Tokenization - Part 1, I'll try to define exactly what tokenization is and the benefits it has over data encryption (the primary benefits were covered in Heather's white paper but here I'll try to provide a shorter version). Part 2 will cover how tokenization can ease the burden on POS vendors and merchants to comply with many of the payment security regulations like CISP, PABP, PCI/DSS, etc. Part 3 will give real world examples on how tokenization was implemented in POS and other applications and again reemphasize how tokenization is more secure than storing encrypted data. Other parts may follow based on the how these first three go...

Tokenization - Huh?
Webster's defines token as "Something serving as an indication, proof, or expression of something else". We are using "tokenization" as the process of substituting a unique identifier (a token) for a card number. This token, for all intents and purposes, is a random unique value and has no way to be deciphered to gain knowledge of the associated card information. Instead, the token is used to initiate payment requests or updates of an already existing payment transaction (voiding a sale, flagging an auth only transaction as a sale, etc.).

I use strong industrial strength encryption – Where's the weakness?
There are several very strong encryption technologies available: triple-DES, AES, Blowfish, RSA, etc. Ignoring any inherent known or unknown weaknesses of one encryption method over another, all these technologies have the same weakness: key storage. The theory behind securing data using encryption is simple: scramble the data to make it unusable for unauthorized use. Encrypting the data (making it unusable) and decrypting the data (returning the data to it's original & usable state) requires keys - a key to lock the data, a key to unlock the data. With most of the encryption techniques, the same key is used to lock and unlock the data. The problem is: How do you secure these keys in the POS application? Once these keys are compromised, the "secured" data is no longer secure.

This problem of securing the keys is very difficult in a compiled POS application and is all but impossible in a shared web-hosting environment that many web sites use. A common technique that POS vendor's use to secure the keys is to encrypt (a catch-22) these keys using a hard-coded password that "only the application knows". In a compiled application, obfuscation (hiding) techniques can be used to give a reasonable level of confidence that the keys are secure. On the other hand, most web sites use scripting languages and hiding the hard-coded encryption keys in these scripts is very difficult.

How is tokenization stronger?
The best way to secure data is to not store the data. This is the theory behind tokenization. The token can be used for initiating new transactions or modifying existing transactions, but beyond this context, it is useless data and there is absolutely no chance it can be used to gain knowledge of the real card information.

Let's assume a worst case scenario: Your Xyz Application data files are not secured in anyway, no encryption techniques have been used, and these files have been given to the world. Obviously, if full card information were stored in these files, you would be in a world of hurt with your customers, your bank, the card associations and quite possibly government and/or law enforcement officials.

Keeping with the worst case scenario: Even if Xyz Application encrypted the card information in these data files that were distributed worldwide, the card associations as well as several states have enacted laws that would require you to notify your customers of the breach because the data can potentially be decrypted. Sure, the data might be securely encrypted, but how confident are you that given enough attention by a dedicated hacker, the decryption keys won't be compromised? In other words, even if encryption techniques are used, merchant reputation wise, you are still in a world of hurt.

Continuing with the worst case scenario: Your Xyz Application stores the token instead of the sensitive card information and these data files are again distributed, it does not matter if they were encrypted or not, no card information was compromised. Your customers do not need to be notified of a breach based on the compromise of card information. Obviously, you may still have to notify your customers or officials based on other sensitive or personal information stored in these files, but not as far as the payment regulations are concerned.

Conclusion
Shift4 released the tokenization concept to the public domain in the hopes that other gateways and possibly even the card associations will embrace the technology, making for a more secure industry as a whole. This posting, part 1, is very generic and non-Shift4 specific. With parts 2 & 3, I'll try to be a generic as possible but they will most likely include sections that detail Shift4's implementation of tokenization.

Here I've tried to briefly describe what tokenization is along with how & why it is stronger than encryption when it comes to the storage of credit card or any payment information. If you have not already done so, I urge you to read the white paper by Dr. Heather Mark - she has a lot more experience writing on the topic of security so she might explain concepts better than I.

Please feel free to comment. Check back later for parts 2 and 3 and maybe more…

At last. I finally made the step to start my own blog. I have posted my unsolicited opinions on many forums and have now decided to create my own spot to spew forth these payment tidbits. Enjoy!