Hacker News Reader

Comment by luisbebop | Hacker News Reader

This device is insecure. It is going to take a long time to get the PCI/EMV certifications. Besides that how do you handle the certification of new applications running side by side with your payment application? Everytime you deploy a new application you should re certificate the entire stack, by the PCI standards. Nice concept, but you have a long road ahead before competing with VeriFone, Ingenico, PAX, Miura shuttle and others.

View on HN

Hi - I work for Poynt on the PoyntOS and Payment interfaces - so maybe I can provide some clarity without going into too much of our IP. As mentioned on our site (https://getpoynt.com/specs), we have two separate subsystems - one for Android and the other for secure payment processing.

All the payments (EMV/NFC/MSR), secure key (including acquirer keys) management, P2PE encryption, EMV/PCI, etc. are handled by the secure processor. There are no other applications that can run on this secure processor other than the signed and certified applications.

On the Android side, Poynt's Secure service is the only service that's capable of communicating with the Payment Processor to initiate card reading (EMV/NFC/MSR/others) and pass through the encrypted data it receives to the merchant's acquirer. All the 3rd party applications run independent of the Poynt's Secure Service and when they need to collect a payment, they do so through our Poynt Payment Fragments to facilitate the Payment flows. (See here for information on how it works: https://getpoynt.com/developers/terminal#2.3 Poynt Payment Fragments).

So as you can see, we are able to keep the security domains separate and thereby able to handle PCI certification in a much more graceful way. Obviously they are some complexities but choosing a certifiable payment processor board was one of many ways we are able to deliver a secure solution.

Cheers!

How are you securing the PIN entry? It looks like that happens on the same screen as the random 3rd-party apps get to run on, leaving open the potential for an app to intercept the PIN. As i understand the PCI stuff, anything that the PIN hits is fully in-scope.

The same question here. Anyone can develop and 3rd-party app to capture the PIN on the same screen from the payment app.

A rogue app asking for PIN on the merchant facing screen ? not sure there's anything much we can do about that other than making sure we catch that during the review process. Whenever there is a need for the consumer PIN entry, it's driven by the second payment processor - not from the android side.

Should be able to prevent PIN information from getting accepted by any means other than your locked-down PIN entry screen. So, any app that wants to grab people's PIN entry would either require them to enter their PIN twice, or block the transaction from going through, which should be very visible.

We designed a solution to keep the switching logic between standard touch and PIN entry within PCI scope such that PIN entry is not even visible at the lowest levels of Android (and thus 3rd-party apps). Also, 3rd parties do not get to run on or take control of that screen.

Are any team members from automotive? This sounds similar to automotive head unit designs. Consumer-facing processor + OS and secure processor (or core) with separate OS.

I'm nervous about the Android part of this product. I've seen some poor implementations of devices that want to use Android because it's 'easy' to get a lot of features up and running but then struggle with the quality of the middleware layers or Android-specific UI patterns that they try to strip out.

Otherwise, I think the dual screen and industrial design looks good! I hope the LCD looks as good as the renderings.

Reply on news.ycombinator.com