Anyone who’s been in a Glenbrook Payments Boot Camp session with me has heard me emphatically stress that merchants “just want to sell stuff – they don’t want to be in the payments business”.

Of course many larger and more sophisticated merchants have figured out how to use payments strategically to increase sales – think private label credit, friction-reducing checkout, cross-border tender types, etc., – and/or to lower operating costs, but most of this is lost on the smaller Tier 3 and Tier 4 merchants. Those merchant tiers encompass the “mom and pop” stores – single store boutiques, dry cleaners, cafes and such, up to merchants with a few locations – generally generating up to a few million card transactions per year.

So where am I going with all of this? I was recently catching up with a former colleague of mine who is now head of sales at a major acquirer, discussing security solutions targeted at these Tier 3 and 4 / SMB merchants. I was lamenting what I consider to be a sad state of affairs in these segments, that relatively simple card security solutions have been in the market for years, but are not getting routinely deployed.

More specifically, I’m referring to what is known as “P2PE” – Point-to-Point Encryption solutions that essentially encrypt card data as it enters a point-of-sale device via a mag-stripe swipe or dip of the EMV chip and passes it securely to their card processor where it can be decrypted and sent to the card networks for processing. The overall goal, of course, is to get “radioactive” card data out of the merchant’s environment, protecting what is sometimes known as “data in flight”.

It’s worth pointing out that the PCI Data Security Council, the organization that sets industry-wide standards for card-related security, mandates that “data at rest” be encrypted in some fashion, but does not mandate point-to-point encryption. Instead, it does provide guidance on various other ways to protect data as it’s being transmitted from the point of sale to the merchant’s processor.  That said, the organization has provided “P2PE Solution Requirements and Testing Procedures” as well as associated FAQs[1].

In my opinion, P2PE is the closest thing to a silver bullet that we have to protecting mag-stripe and EMV transactions at Tier 3 and Tier 4 merchants right now, and it will be for a number of years until we have a critical mass of tokenized Apple Pay/Android Pay/Samsung Pay/Fill-in-the-Blank Pay transactions at physical POS (note that even the EMV specs don’t specify encrypting card data out the back end of the terminal).

Yes, this isn’t a trivial problem and with security every detail matters. If keeping merchant equipment out of PCI scope is the goal, then where encryption takes place and the path that data takes—back through the POS system or direct to the processor in the semi-integrated manner—makes a difference. Protection has to be in place at the application layer and over the communications link. But this is all settled science. There’s no mystery here.

So my problem is not that we don’t have the technology to protect these merchants with an affordable solution; my problem is that as an industry, we aren’t doing it. Instead, we are assaulting these poor SMBs with incomprehensible concepts such as “PCI compliance”, “mandated industry security standards” and the need to be “PCI certified”.  Why?  Shouldn’t the industry just build P2PE-type solutions into every point-of-sale device”?

And by the way, I should mention that it is now standard practice for most acquirers to charge their merchants monthly or annual “PCI Compliance Fees” that do NOT include installing P2PE on their terminals.  Oh yeah, and if the merchant is deemed to not be PCI-compliant, the merchant is usually hit with, you guessed it, a “PCI Non-Compliance Fee”.  And most acquirers charging PCI Compliance and Non-Compliance fees also sell security insurance to many SMBs to protect against potential fines and penalties stemming from data breaches that P2PE and tokenization could have mitigated in the first place.

Just to be clear, I’m not saying that P2PE and tokenization are sufficient to totally obviate SMBs having to think about card security. Merchants still need to be cognizant of how they handle physical cards, what they print on receipts, reports that may contain full account data, ensuring their terminals haven’t been tampered with, etc.  What I am saying is that the greatest risks can be largely mitigated relatively painlessly and cost-effectively.

To be fair, some acquirers do routinely install P2PE into their devices without explicit charges for it. They just build the cost into their pricing and/or include it into an add-on service such as data breach insurance. Although I really have to wonder about those acquirers that are happy to sell the SMBs data breach insurance without even requiring P2PE. I can only assume that they make more money paying off a claim here and there versus the cost of implementing P2PE.

But why are most acquirers not routinely implementing P2PE solutions as a matter of course? First, there is a cost to it – they need to modify, test, and certify their terminal apps as well as implement secure encryption key management practices (like they already do anyway with PIN pads). In addition, there are often technology licensing costs. And, in fact, many acquirers feel that the small merchants won’t pay them an explicit fee to cover these costs. But of course, it is now an industry standard to charge either PCI compliance or non-compliance fees that the merchants do pay. I have no idea how common this is, but I actually had an acquirer for a non-profit I volunteer for tell me that Visa and MasterCard required them to charge us those fees.

I don’t realistically believe that shining a spotlight on this issue will make much of a difference in the marketplace, but I do want to acknowledge those acquirers that are “doing the right thing”. I hesitate to mention those that I know of lest I forget some. But please feel free to acknowledge those that are in the comments section below. And as always, I’d truly appreciate your thoughts and perspectives.

[1] pcisecuritystandards.org/document_library?category=p2pe&document=p2pe_solution_requirements