Evan Schuman's StorefrontBacktalk

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.