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

Recent Payment Views

Payments Post #17: Cutting Costs

Payments Post #17: Cutting Costs

In this Payments Post, we discuss the DOJ bringing a lawsuit against Visa that alleges the company operates an illegal monopoly in the debit card space. Does the argument have merit in our non-legal minds? And if so, what could the DOJ’s move mean for an evolving payments landscape?

read more
Payments Post #17: Cutting Costs

Payments Post #16: The Apple Drops

It’s time for another edition of Payments Post and (surprise!) we’re thinking about the Visa Flexible Credential again. Now that Apple has plans to open up the NFC chip and Secure Element to third party developers, we’re scratching our heads. Who benefits from this newfound NFC access? What opportunities can fintechs unlock? How will conventional financial institutions react? And to tie it all back, does the VFC still matter?

read more
Payments Post #17: Cutting Costs

Payments Post #15: BNPL Battles

In this month’s Payments Post, we revisit the prime use case for Visa Flexible Credential (VFC): BNPL. How are buy now pay later providers positioning themselves in the current environment, how are consumers using their tools, and how are regulators and issuers responding?

read more

Glenbrook Payments Boot CampTM workshop

Register for the next Glenbrook Payments Boot Camp®

An intensive and comprehensive overview of the payments industry.

Train your Team

Customized, private Payments Boot CampsTM workshops tailored to meet your team’s unique needs.

OnDemand Modules

Recorded, one-hour videos covering a broad array of payments concepts.

GlenbrookTM Company Press

Comprehensive books that detail the systems and innovations shaping the payments industry.

Launch, improve & grow your payments business