Retail point of sale credit card processing - card present. Minimizing PCI compliance requirements

Question

I am writing a point of sale application for a client who has some very specific needs. The client is a retail store, so when they process credit cards, they have a physical card present and can swipe it. The way it is now, at the end of check out, it presents the cashier with a total, and the cashier keys the total into a credit card terminal (by hand--it is not connected to the computer), swipes the card at the terminal and then when the payment is processed, the cashier presses the "Paid by Credit Card" and it prints a receipt.

The problem is that hand keying in totals is time consuming and prone to errors. I'd much rather have my program transmit the amount to a credit card terminal and then get a message when the transaction has been processed. I don't want to touch any card holder information (card number, etc) because I want to stay outside of PCI. All I want to do is send an amount and get back an "accepted" or "declined". You'd think this would be common, but I seem to have failed to find information. (For example, authorize.net's card present API requires me to collect and transmit the card number. I don't want to collect and transmit the card number. I want to transmit an amount and have someone else collect and transmit the card number and notify me when the process is complete.)

Does anyone have a solution for this? Has anyone worked with Verifone or Ingenico's hardware? I don't care if I'm sending the number of a physical terminal connected via USB or to a virtual software terminal. I just don't want to be the terminal myself, so that I'm not anywhere in the chain of card data.

Heng

Have you found a solution for this? – Ferrari

Answer 1

I'm familiar with the VeriFone line of products, both signature capture (Mx900 series) and mobile iOS devices (Vx600). Your first hurdle is that the units are pricey for the little guy (ie: small business owner) at about $500 & $900 each respectively (retail).

On the bright side these things are your friends when it comes to PCI via what VeriFone dubs Verishield Protect (VSP). Essentially VSP encrypts the card swipe on the magstripe head and your POS solution will have to send out a decryption request which your POS software can either consume for settlement or for a fee VeriFone will send it directly to the bank.

The main sticking point of the PCI requirements I believe you're running into is the fact that the clear card data can't be "stationary" at any point in your code and either of these solutions will be a good launching point.

Good luck!

Spoonbill

Answer 2

You should take a look at payworks. They provide a iOS / Android SDK to integrate a credit card reader. You never touch credit card data.

Disclosure: I am a software engineer at payworks.

Poor

Answer 3

The Pax S300 can do it, though I haven't found a processor that supports it. TSYS is supposed to, but after 4 months of run around, I could never get a device. Helcim has great customer service and report that they are planning an Ingenico solution for pushing the total to the terminal by the end of 2015.

Reformed