The token approach is hardly new and it simply replaces a credit card number with a token that acts as the number throughout the payment approval cycle.
It's fair to say that such a method—in theory—would reduce the risks of card transactions by shrinking the window of vulnerability. But it's hardly fullproof protection and as long as retailers accept credit card payments, they are almost certainly under the PCI jurisdiction.
That didn't stop Shift4 on Wednesday from issuing a statement that "merchants concerned about PCI DSS compliance have an option that enables them to avoid its burdensome requirements."
Shift4's argument hangs on this line from the current PCI rules: "PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply."
But the product from Shift4—whose employees didn't return a phonecall and E-mail to discuss their release—doesn't kick in until after the credit card has been presented and introduced to the POS.
Gartner's senior security analyst, Avivah Litan, said the vendor's claim is pushing it.
"I think the Shift4 press release is potentially misleading. As long as a merchant is accepting a credit/debit card at the POS, the merchant must comply with PCI. There is a period of time, albeit short, when the POS device must transmit the card number to the Shift4 service so that it can create the token number," Litan said. "The merchant is therefore responsible for making sure that that POS transmission is encrypted."
Litan adds that for many retailers with older POS systems, this is more than a technicality. "Many old legacy POS terminals are incapable of encryption, making this ‘first' and ‘last' leg of the payment journey transaction the most vulnerable. I say ‘last' because the POS system has to receive an authorization message back from the card networks. Security is only as strong as the weakest link. So, bottom line, in many cases, merchants won't want to consider outsourcing data processing and electronic data storage until they upgrade their POS equipment in order to support encryption. Visa's 2010 PABP compliance date will help make that happen, but not until 2009."
Litan, as usual, makes some excellent points. But the bigger problem here is the overall PCI confusion among retailers. Retailers overwhelmingly want to be PCI compliant (Fear? Thy name is no interchange fee discounts) but those are being flummoxed by security vendors confusing and misleading them.
This turns into a very vicious cycle. Retailers want to trust security vendors, so they can rely on them to interpret PCI and other security rules. But when reputable vendors like Shift4 get caught playing fast-and-loose with PCI interpretations, it makes it 50 times as difficult for vendors to be trusted with such interpretations.
Put another way, security vendors are in a wonderful position to not only sell software and services, but to act as trusted advisors to retailers, trying to navigate PCI. I'm not sure of the best way to kill that golden goose for all security vendors, but I think Shift4 has come up with a pretty bloody good one.