New POS Security from Old System Topology

by George Peabody on March 3, 2015

in Card Acceptance, Card Fraud, Card Payments, Card Technology, George Peabody, Payments Fraud, Point of Sale (POS), Security

Post image for New POS Security from Old System Topology

Anyone around technology for a couple of decades recognizes how old ideas tend to return. To those folks, using a browser to do data entry into an enterprise database looks a lot like a mini or mainframe system’s terminal application.

Back for another incarnation in payments is an old fashioned topology familiar to anyone who used or deployed stand-beside dial-up terminals. In that mode, the POS terminal is not connected to the merchant’s system in any way. It sits next to the cash register and the sole integration point between the two is the staple the clerk uses to connect the cash register receipt to the print receipt from the POS terminal. The data flow went directly from the terminal to the acquirer’s modem bank and front end system, never touching the merchant’s system.

Integration and its Risks

While that simple configuration is still out there in considerable numbers, the typical retailer has connected their point of sale system, the PC running the store, to the POS terminal that takes card payments. In other words, the PC, predominantly based on Windows, is inserted between the payment terminal and the acquirer.

What could go wrong with that? We already know – that connection is the major source of card data breaches today. Using the POS terminal simply as a payment acceptance peripheral means that the merchant’s POS system drives the payment interaction and sees the payment data as it flows through the merchant’s system to its acquirer or processor.

SecureProgramming

Direct Connection Returns

Back in the non-integrated, stand-beside days, the POS terminal drove the payment acceptance process. It was the master of the transaction at the merchant’s location. We are now seeing instances of that direct merchant-to-acquirer topology returning to the market, a shift made possible by IP connectivity, powerful and price competitive POS terminals, and safer integration between the POS terminal and the software running on the POS system.

Verifone’s Secure Commerce Architecture (SCA) is an example. Since we obviously can’t go back to stapler-driven integration, Verifone has begun promulgating a system layout and process flow that makes the POS terminal itself responsible for all payment-related data reading, formatting, and communications.

In its SCA, the terminal receives the payment amount from the POS system and then over IP, as a peer device, it sends the message within a standard SSL wrapper to the merchant acquirer’s front end system for authorization. The data is transmitted within an SSL encrypted communications link and, one hopes, the merchant and its acquirer have encrypted the payload itself

On the return trip, the terminal sends the AUTH message to the POS system’s software along with an acquiring token. Using this topology and the data protection stalwarts of encryption and tokenization, the merchant never sees card data. From a PCI point of view, this is a Good Thing.

ISV Relief

It could also be a very good thing for the independent software vendors who write the line of business software the merchant uses to automate the point of interaction. They’re the ones who have had to deal with PCI security concerns and the complexities of payment transaction management while most would prefer to just concentrate on how to better serve the business of, for example, their hair salon customers.

Using an API based on name value pairs to communicate non-payment data (with the obvious exception of sale amount data) simplifies the ISV developer’s work and could simplify device certification as well, now a daunting challenge given EMV’s complexities.

This shift is brought to you partly by Moore’s Law. In the past, the integrated configuration required the computing horsepower of the POS system. POS terminal hardware models now possess 32-bit processors running at 400MHz with 512MB of memory, enough to run the Linux operating system and payment applications. In a decade, the processor speed has nearly doubled and memory many times over that.

With encryption and tokenization, in its multiple forms, we’re seeing good moves for payment security. Returning all the payment logic to the POS terminal is another step forward, benefiting the ISV, its merchant customers, and the payment ecosystem itself.

Leave a Reply

Previous post:

Next post:

Clicky Web Analytics