advertisement
advertisement

Can VeriFone Actually Outsource PCI Problems?

Written by Frank Hayes
August 7th, 2013

In theory, you can’t outsource PCI issues, but VeriFone wants to try. On Monday (Aug. 5), the POS maker announced VeriFone Point, a payments-as-a-service offering that basically takes everything in the store except the PINpad out of PCI scope—and, as far as we can tell, the PINpad doesn’t belong to the retailer, so that’s somebody else’s problem, too.

This should be a really good idea, and maybe even a good product for some chains if it’s implemented right (we haven’t seen details yet). But let’s imagine it is: The PINpad belongs to the service provider. Card data is encrypted and transferred via the service provider’s network, not the merchant’s. A token is kicked back to the store POS with the card approval, so the merchant can track customers and meet branded-cart transaction detail requirements. No card data ever comes near the merchant’s systems. What could possibly be wrong with this plan?

Well, pricing could be wrong—VeriFone says it has a subscription-based model, and many of the merchants who could most benefit from not having to worry about PCI already don’t worry about PCI. Since the payments-as-a-service idea is only cost effective if its price is compared to the cost of PCI compliance, that crowd probably won’t be interested anyway.

Then there’s PINpad security. That’s already a problem at most chains, even when they own the PINpad—devices that aren’t screwed down, devices that are left unattended long enough for a thief to tamper with them, devices that simply get rough treatment. When a PINpad explicitly belongs to somebody else, that’s practically an invitation for abuse from the point of view of some associates.

And what if something goes wrong with a transaction or the device itself? If a swipe fails or the power has gone out, there has to be a fallback system and a fast response by the payments-as-a-service provider—fast as in hours or minutes, since ans associate can’t just be guided over the phone through swapping in a spare PINpad. That would potentially put the PINpad back into PCI scope for the merchant.

That’s all downside, and it’s all very practical—and probably unavoidable.

The upside? Implemented right (yes, there’s that caveat again), retailers might never have to deal with PINpads again.

Suppose everything that isn’t a payment card just gets kicked back to the POS system by the processor via the same channel as approvals and tokens. Then when loyalty cards or closed-loop gift cards are swiped, they’d go straight to the POS, the way they’re supposed to. So would e-coupons sent by an NFC mobile wallet, or anything else the processor doesn’t recognize as a payment it’s supposed to handle.

Meanwhile, there’d no longer be that sense of dread involved in tinkering with the POS system every time a new technology arrives at the PINpad. All those chip-and-PIN and contactless and NFC and PayPal Now implementations could be handled by the processor, not the retailer. And at least in theory, the retailer wouldn’t have to care.

There are some finicky details that would no longer be under the control of the retailer—choosing from multiple processing networks might not be practical, but that’s the sort of tradeoff you’d expect from handing off the entire process to someone else. (Then again, it might not be so difficult after all. As usual, it probably comes down to who’s willing to pay for what.)

On the other hand, there are some interesting possibilities. Chains that currently handle transactions in-store and then batch them to central IT could still do that, or they could have transaction approvals duplicated to central IT, or just run to central IT which would then communicate with the in-store POS. Franchise operations that handle payment processing centrally could keep an eye on those franchisees, transaction by transaction.

And in a different direction, health of the PINpads could be centrally (and consistently) monitored—and there’s a lot more impetus to do that for the processor responsible for security than for central IT with a lot of different priorities.

Will all this magic turn out to be reality in VeriFone’s first attempt at payments-as-a-service? Almost certainly not, and there may be completely new problems that surface. But the biggest reason retailers believe they have to handle card numbers is that they always have (back to the days of the zip-zap machines) and there hasn’t been a reasonable alternative.

Now there may be an alternative. How reasonable will VeriFone and its partners be? That’s a different question.


advertisement

Leave a Reply

Readers, specifically those who want to comment on a story:
Our Comment SPAM system is getting very aggressive these days and has been blocking legitimate comments. If you post a comment and don't see it appear within 2 hours or so, can you please send a heads-up to customer-service@storefrontbacktalk.com? Ideally, please include the time you posted the comment. That will allow us to try and hunt for it. Thanks! P.S. We're working on fixing the system, but we don't want to lose any valuable comments in the meantime.

Newsletters

StorefrontBacktalk delivers the latest retail technology news & analysis. Join more than 17,000 retail IT leaders who subscribe to our free weekly email. Sign up today!
advertisement

Most Recent Comments

Why Did Gonzales Hackers Like European Cards So Much Better?

I am still unclear about the core point here-- why higher value of European cards. Supply and demand, yes, makes sense. But the fact that the cards were chip and pin (EMV) should make them less valuable because that demonstrably reduces the ability to use them fraudulently. Did the author mean that the chip and pin cards could be used in a country where EMV is not implemented--the US--and this mis-match make it easier to us them since the issuing banks may not have as robust anti-fraud controls as non-EMV banks because they assumed EMV would do the fraud prevention for them Read more...
Two possible reasons that I can think of and have seen in the past - 1) Cards issued by European banks when used online cross border don't usually support AVS checks. So, when a European card is used with a billing address that's in the US, an ecom merchant wouldn't necessarily know that the shipping zip code doesn't match the billing code. 2) Also, in offline chip countries the card determines whether or not a transaction is approved, not the issuer. In my experience, European issuers haven't developed the same checks on authorization requests as US issuers. So, these cards might be more valuable because they are more likely to get approved. Read more...
A smart card slot in terminals doesn't mean there is a reader or that the reader is activated. Then, activated reader or not, the U.S. processors don't have apps certified or ready to load into those terminals to accept and process smart card transactions just yet. Don't get your card(t) before the terminal (horse). Read more...
The marketplace does speak. More fraud capacity translates to higher value for the stolen data. Because nearly 100% of all US transactions are authorized online in real time, we have less fraud regardless of whether the card is Magstripe only or chip and PIn. Hence, $10 prices for US cards vs $25 for the European counterparts. Read more...
@David True. The European cards have both an EMV chip AND a mag stripe. Europeans may generally use the chip for their transactions, but the insecure stripe remains vulnerable to skimming, whether it be from a false front on an ATM or a dishonest waiter with a handheld skimmer. If their stripe is skimmed, the track data can still be cloned and used fraudulently in the United States. If European banks only detect fraud from 9-5 GMT, that might explain why American criminals prefer them over American bank issued cards, who have fraud detection in place 24x7. Read more...

StorefrontBacktalk
Our apologies. Due to legal and security copyright issues, we can't facilitate the printing of Premium Content. If you absolutely need a hard copy, please contact customer service.