Interesting merchant terminal -- but it seems to be little more than a pretty rendering and physical mock-up right now.
I like how the first guy puts his card in, takes it out AND THEN punches in his PIN, which is exactly how PIN & Chip doesn't work. I would have hoped they'd at least be familiar with the process.
It looks to me like a mobile computer strapped to a terminal. I'm not sure why this is better than having a terminal + iPad or something similar but I'm not the target demographic.
I see many other issues with it:
- Hardware development is hard and long. This looks to be little more than a physical mock-up. For example datasheet lists "Ethernet" is connectivity options but there is no ethernet port visible on the body.
- BLE & GSM antennas are exactly where you wouldn't put either of those. Here is tip: You can't put an antenna behind an LCD. They have metal backings.
- Shouldn't QR & Barcode Scanner be pointing UP? You have very limited field of view when it is pointing down.
- Getting EMV and FIPS certified are going to take a long long time. Granted they could buy that firmware off the shelf to accelerate the process.
Okay, I'll bite. I'm an employee so you'll have to take what I say with a grain of salt.
The video was produced with a cosmetic device and with actors. You're right that the card has to be in the device during PIN entry. The scene you're referring to, however, is depicting tip entry.
The device does not have an ethernet port but we will be shipping with a separate charging dock that will provide wired connectivity.
I can assure you that all of our antennas are not behind LCDs. While compact, the device does have a number of non-LCD surfaces.
The customer facing camera is pointing horizontal. We'll continue to refine the angle (if needed) as we continue testing with our early adopters.
We did in-person demos with over a dozen news agencies. If you have any doubts about the existence of the device, please feel free to reach out to them for confirmation.
I am not doubting that you are building the product.
You/The company should probably put more effort in correcting the datasheet and the information you put out there. We can only judge by what is being presented. Your datasheet says Ethernet. It doesn't say Ethernet would be on a separate dock. It probably should.
If you are placing the antennas behind plastic surfaces, that is great. You should correct the diagrams.
Further to your point about tip entry, tip should be entered before the transaction is authorized right? So one would assume you'd enter tip then put in the card, and optionally enter a PIN or sign the screen.
I can appreciate that it may be just a video demo, but when you post it to a place like YN people are going to point out errors. Funny enough, that error was pointed out by a friend who was watching over my shoulder. She is not a technical person in any way and it jumped out at her.
No problem. I've been mostly a lurker on HN for a while but this is the first time being put under the microscope. I apologize if I came off as defensive. This is a product that's very close to my heart given the amount of time and effort we've put into the product offering. For the record, none of us here posted the article we are here because of the amount of attention and discussion it has garnered.
Point taken about the errors. There are many things we can improve on all across the board. We made a conscious decision to not let perfect be the enemy of good. The video is done so we won't go back and change that but I will work with the team to fix all of our marketing material to be as accurate as possible. Thank you for pointing out or errors.
With regards to tip entry. Industry standard recommends gratuity be added before PIN but it is not mandatory and is a merchant preference. I can't find all the card network examples easily but I happen to have the AMEX EMV Acceptance Guide open and this is what section 4.2.7 states - "In certain Merchant categories such as restaurants, it is standard practice to enable customers to add a gratuity to the amount of the transaction. There are many different ways in which a gratuity can be added. American Express does not define any specific methods for adding gratuities..." it further goes on to say "American Express
recommends that Terminal software enables the Cardmember to
add the gratuity amount to the transaction before entering his or her PIN. This enables the transaction to
be processed as a normal, “card present” transaction."
In any case, we've all appreciated the various comments on here and it has clearly been the most critical audience of the bunch.
Omissions and errors happen. Your company has responded better than most. I'm glad someone from your company was on the forum to correct the record.
With respect to the tip flow, with Chip & PIN you would need the final amount before authorizing the transaction so the tip would be added before just as your guide suggests. Chip & PIN terminals in Canada and Europe do just that. They present you with the tip screen (% or amount) before you enter your PIN & finish the transaction. For MSR, just like in restaurants today, they can change the amount after the initial authorization but they also often authorize for about 50% more (to allow for tip) and then do the capture once the server takes the bill from the table and "closes" it with the correct tip.
I can say from personal preference that I would do a double take if a device allowed me to put my card in and finished the transaction and then permitted a change to the charge amount. What is stopping the cashier from adding her own tip once I walk away.
As mentioned, the point at which the dialog for tip is presented (before or after CVM check) is a configuration option for the merchant. Keep in mind we are deploying a US solution first. We are also anticipating that in the US we will have signature as the primary CVM before PIN. From that perspective, our flow will should be a little less odd.
That said, in the true Chip & PIN solution, once you ask for tip after PIN entry you as the merchant are opening yourself up to higher rates (Card Not Present) as well assuming liability for chargebacks. I don't know why a merchant would want to do that but as a platform we have chosen that use-case as an option.
The expected way to handle Chip + PIN transactions is that the final price is set before you enter your PIN. It is never changed after you put the PIN in - because at that point, it becomes a card-not-present transaction.
If you are using magnetic strip you're correct. For PIN & chip the PIN is sent to the card and verified by the card and the resulting "signature" is sent to the bank. The card has to be in for PIN entry.
An employee, above, said that it is for entering tip. Which would make more sense, but then the card would have to be inserted after the total amount I imagine but I can see how they would have a slightly different flow. Personally, I would want any terminal that I use to show me the final amount that I am going to pay before I put in my card. Lest I pay, walk away and the cashier adds her own tip.
This is the first EMV payments terminal I've seen that allows PIN entry using a touch screen. Is that really allowed by EMV, as a tamper-evident PIN pad?
Doesn't it make it easier to spy?
Because you know where the numbers of the pin are located, you don't even need to look at the keys, but can easily cover it with your hands to prevent "shoulder surfers".
If I have to look where the keys are located, I can't really cover the pad and it'll be a lot slower and not more secure.
I've always felt like it's harder to spy on an LCD screen due to the limited viewing angles as opposed to physical buttons. And the physical layout of the PIN pad should be similar so it should be a smooth transition. The device will also be PCI PTS approved so it will be on par in terms of physical and logical security.
The requirements are that the consumer must have some way of concealing pin entry. That, and some stuff about how hitting different numbers can't make a different sound, or have easily picked-up electrical signatures, etc. I believe the EMV specs are publicly available, too.
Tamper-evident is likely baked into the device, instead. Make a circuit that trips when you open the thing up, wire that up to wipe the keys and brick the device until it goes back to factory.
Exactly what i was wondering. RBI (Reserve Bank of india) does not allow entering PIN's on touch screen. Infact they (RBI) go to such a length that a card processing terminal should be ONLY just the terminal and the hardware should be approved by the RBI which might take months.
If someone from Poynt is on, what are the features that make this better than competing products? I've used Shopify for doing some PoS setups, but I'm having a hard time looking at where Poynt fits in. Other than being cheaper, it lacks some of the things that make Shopify great, namely cash handling and connecting to a back office system.
Hi, I work for Poynt on the PoyntOS and applications. First thing first, Poynt Smart Terminal is a Secure Payment Terminal at the core that provides credit card payment processing functionality to any merchant that needs to accept payments in their stores. This is analogous to the traditional payment terminals that you might probably notice every day at a lot of merchant stores (cafes, salons, grocery stores, etc.). Poynt Smart Terminal enhances the credit card payment processing functionality by supporting more payment methods (MSR/NFC/EMV/QR Code/etc.) so the merchant doesn't need to worry about carrying multiple devices in the store and be able to serve more customers. In addition to that, Poynt Smart Terminal runs on Secure PoyntOS (powered by Android) to provide an application platform and framework for developers to build apps and solutions for the merchants and distribute through Poynt. Developers can take advantage of the PoyntOS to build unified solutions for the merchants that run on the same device where they are used to process payments (unlike various solutions today in the market that require additional hardware like ipads, dongles, etc.). Shopify is an online platform that allows developers to build solutions for their merchants hosted online or on devices. Now with Poynt Smart Terminal, developers can build PoS apps using Shopify platform that run on Poynt Smart Terminal too. So I would probably say they are complementary, not competing.
Should definitely highlight (at least to the HN crowd) that this is an Android device and you're exposing some APIs that can be built on. This is really cool.
I do not work for Poynt, but it seems more like they've forked Android and created a hardware/payment platform for different POS solutions - note that they've already partnered with Vend and Intuit, and offer an SDK out of the gate.
From my prospective a competing product does not exist that fits into the targeted market. Price point, simple integration, agnostic platform... we use a blend of Vend (Brick) & Shopify (Online) and the transition to integrate something like this is simple, straightforward and cheap.
Traditional carriers like Verifone or NCR, your costs are high (typically for enterprise) and implementation is anything but straightforward.
What other payment product that is not a dongle solves these varied payment problems for hosted solutions like vend, lightspeed, shopkeep, etc and is plug and play?
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.
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.
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.
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.
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.
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.
Interesting to see Osama Bedier listed as one of the people. He is the guy who ran PayPal's merchant terminal integration efforts, left for Google Wallet, and then left Wallet.
I think there was a lawsuit filed against him and Google by PayPal the day of Wallet's launch, claiming Google stole their secrets. No idea how that turned out; though I imagine it was a PR move on PayPal's part.
> Does the Smart Terminal accept payments by Apple Pay?
> Yes, the terminal accepts Apple Pay since the iPhone securely communicates with the terminal through NFC. We here at Poynt made our first Apple Pay payment with our Smart Terminal on the morning the software was released to the world. It was a very exciting moment for us!
One of my concerns is that it appears the door to change the receipt roll is on the bottom of the device. Does this mean I have to shut the device off and flip it over if it runs out of receipt paper to print a receipt for a customer?
it's actually in the front of the device as you see on the website (https://getpoynt.com/) and the button to open the printer door is on the side. The door opens forward and you can load the paper from the front (no need to turn it upside down). We will try to post videos of the paper loading as soon as we can.
It seems like a good time for this product. Payments feel like the wild west right now. A reader that can potentially handle all protocols is a safe investment in the future.
To begin with, while our terminal is Android based we have taken numerous steps to lock this device down. Side loading apks is not possible nor is arbitrary access via adb. On top of that, we take great lengths to protect consumer data. In addition to full PCI compliance data is fully encrypted on the device. And if that's not enough, there are several anti-tamper mechanisms that will trigger and lock down the device even further upon physical instrusion.
In terms of physical theft we are actively looking into an option to physically secure the device (think kensington). Our plan is to have a good solution for this before our merchants go live.
Well, here is my big question: WHY ARE YOU STORING CARD DATA AT ALL? (sorry for the caps). You are a pass-through entity, merchant terminals do not store card data. They keep the authorization number from upstream provider to allow void/refunds but there is no need for them to store the number.
With respect to anti-tamper mechanism, are you FIPS-140-2 certified or plan to be?
We aren't storing actual card data encrypted or otherwise. As you said, we are a passthrough as far as the payment portion is concerned. We do store a hashed representation of the card for things like refunds (referenced credits).
Our security subsystem is being built to be FIPS 140-2 Level 3. Complete with tampers seals, switches and a security mesh that will destroy sensitive keys when triggered.
Assuming that someone managed to not only walk off with the device from a retailer but were also able to gain access to the device itself. What kind of data could be harvested from the device?
First things first; the card data is encrypted on read and the device will soon be PCI certified. So none of the card data will be accessible to anyone on the device.
The transaction data (amounts, items, transaction statuses, etc) is managed by the PoyntOS (owned by Poynt). That data has the necessary authentication and authorization around it to prevent just anyone with the device from having access to it. Only a merchant user logged into the app and with the appropriate level of privilege will be able to access the data.
Finally, 3rd party applications will go through a strict vetting process and will be signed. Therefore, it will not be possible for some fake app to work on the device. Also, PCI requires us to constantly monitor the installed application for any kind of tamper.
We are in the process of both PA-DSS for our cloud services and PCI approval for the device. This is the primary reason we are not shipping to merchants until next year. We have line of site to certification and we would not (and can not) ship to merchants until this is complete.
Afaik you should have PA-DSS to your app running on top of the Android OS that btw is not PCI. Just PA-DSS to your cloud services considering the architecture you are proposing is not enough. PCI-PTS to your hardware is another problem you are going to face in your certification because you are using a touchscreen 'pinpad'.
It wouldn't be fun if all this was done before. This is uncharted territory and we are not taking it lightly. We have involved the right talent (some payment industry experts) and have designed this carefully. We are confident that we will pass all certifications necessary to satisfy everyone (including our own high standards).
Most places I've traveled to outside of the US have devices similar to this that staff carry around a restaurant to complete the payment process table side. They've all been PIN+Chip devices as well.
Aside from that one would hope that they aren't storing PII or financial data on the device itself.
You can do the same thing with, well, any credit card machine... Go into any SMB and there's a good chance the credit card reader is independent of the POS system.
I was wondering this too. Somebody could swipe the system straight from the counter and cripple sales for a while. Surprised to not see a Kensington lock on there.
If you decide to build something on our platform, please fill out the form at http://goo.gl/forms/dgwMwDysAv to start a conversation with us. Good luck!
The credit card processors do far more than just issue magic pieces of plastic. The plastic itself is probably the least significant aspect of their business model.
The business model relies on a monopoly, an information monopoly. If the mass's interaction at POS is with a software or a hardware that potentially allows id-ing the patron, preferential pricing becomes possible, security is anon issue -- it seriously damages the value of the middleman.
So that the secure element(yeah right) that's on your plastic or your phone only communicates with OSes and HW that limits the ID-ing of the cx and provides the strict minimum of info to your POS is the critical part, in my view.
If privacy were really the concern, people would pay with cash. They always have, and always will. It is accepted everywhere, is the definition of liquidity, and is virtually untraceable. At best, in-person swiping of physical credit cards is a compromise that people make that gives away some of that privacy (your card provides your name, and can be used to verify your address) in exchange for something more valuable:
1) near immediate payment resolution
2) fraud protection
3) insurance against bad products and vendors - you can
almost always get your money back if something goes wrong
4) credit accounts
5) points/miles/cash-back, at the expense of the vendor
How many different merchants to do you deal with on a regular basis?
What is the risk of fraud or of bad product and or bad vendors when both ends know each other? Why introduce a 3rd party in those transactions that gives back a fraction of its fee to the payer? (5) Instead why not reward repeat business with preferential pricing? (not directly possible but attempted via loyalty programs that cost a lot to deploy)
The credit is provided by the issuing bank (4). It can exist independently of the credit card network.
And with any electronic means, 1 is pretty much a given.
Credit 3rd parties still have a reason d'être if a solution that shortcuts VISA and MC when both ends know each other catches on. A Credit 3rd party is needed as an insurance policy when two unknown parties do a transaction; that insurance is bound to cost more than today given less volume; but it could be efficient if pricing would be market driven instead of diluted in 100-1 day to day transactions.
Thanks to the down voters, BTW. Again HN is showing openness to look at things from a totally non conventional angle. I think I'll log off for good. So long, and thanks for all the fish!
I like how the first guy puts his card in, takes it out AND THEN punches in his PIN, which is exactly how PIN & Chip doesn't work. I would have hoped they'd at least be familiar with the process.
It looks to me like a mobile computer strapped to a terminal. I'm not sure why this is better than having a terminal + iPad or something similar but I'm not the target demographic.
I see many other issues with it:
- Hardware development is hard and long. This looks to be little more than a physical mock-up. For example datasheet lists "Ethernet" is connectivity options but there is no ethernet port visible on the body.
- BLE & GSM antennas are exactly where you wouldn't put either of those. Here is tip: You can't put an antenna behind an LCD. They have metal backings.
- Shouldn't QR & Barcode Scanner be pointing UP? You have very limited field of view when it is pointing down.
- Getting EMV and FIPS certified are going to take a long long time. Granted they could buy that firmware off the shelf to accelerate the process.