0
votes

I have an Android Kiosk POS that I sell to my clients to accept payments. To accept payments, a USB magnetic swipe card reader is attached to the Android Kiosk (it has a USB port) and on swipe, as soon as the keyboard input comes in, the listening activity parses it and extracts the required card info. We then get a token for the card from Stripe and charge them via Stripe as well. This has been working quite well since we released it.

However, a new need has arisen. That is the need for accepting EMV & Google/Samsung/Apple Pay + whatever NFC payments comes in the future. I just purchased another USB card reader from China that accepts chip + NFC + swipe. I know how to handle the swipe part as it is the same as what I have been doing with the single functional card readers that we use in the field currently.

However, I don't know how to accept the chip and especially the NFC payments. I have Google Pay setup on my phone and whenever I put it near this new card reader, it beeps and types (it is considered a keyboard even though it's not) an 8 digit number. So, I know it detects it and all and generates some number, but I have no idea what this number means. I thought it was supposed to give me the card number and all the way the magnetic swipe gives me the tracks. The same for the EMV part... however, with the EMV part of the card reader, it doesn't even seem to get any input.

I am hoping someone has experience with this type of device with Android and can guide me.

Sdk documentation I got with device

Picture of the new device

2
Yes. That doesn't address my question though.qazimusab

2 Answers

1
votes

The number you're receiving on your reader is not the card number number (PAN) - it's a token (sometimes called DPAN) which represents your card, but isn't the same as the card number.

From Google Pay Merchant Help - How payments work (emphasis mine):

Google Pay does not send merchants their customers' actual card numbers when they pay in shops; instead, Google Pay facilitates a process called tokenisation, in which a token stands in for a customer's actual credit and debit card numbers.

[...]

To make a purchase, a customer taps their mobile device on a point-of-sale terminal or chooses to pay in your mobile app. Google Pay responds with the customer's tokenised card and a cryptogram which acts as a one-time-use password. The card network validates the cryptogram and matches the token with the customer's actual card number.

Effectively, this is a security feature to prevent malicious card readers from simply reading and storing the card number from a phone that supports Google Pay, Apple Pay or a similar payment method.

0
votes

I have implemented an open source EMV payment framework (https://github.com/vicente-da-silva/dcemv). This implements both EMV contactless and contact kernels. There are various NFC drivers. It runs on Android. You could use this for EMV transactions where the card PAN is tokenized or not, but for tokenized cards via HCE, the bank/acquirer you are dealing with would have to integrate with Samsung/Apple/Google Pay in order to pass them the token and have it translated back to the original PAN.