file io api to enable chip and pin hardware

[shanly]

We have a a chip and pin device we integrate with by:

• writing a file to c:\known-location\out.txt
• then polling for results files c:\known-location\in.txt, c:\known-location\receipt.txt, c:\known-location\customer-receipt.txt
• we currently do this through FF plugins but this is quite hacky and something we would like to move away from

We are looking at adding an API extension to qz.io that looks something like:

openFile(filePath)
writeData(filePath, txt)
closeFile(filePath)
setFileCallbacks(calls)

We are working on a spike to see if it is possible. Will add reference here once done.

Would this be something that might be merged in?

The reason we are looking at qz.io is that we are likely going to move to it for replacing our current ticket printing integration and it seemed like a good integration to piggy back this on.

[tresf]

writing a file to c:\known-location\out.txt

We support this now via https://qz.io/wiki/2.0-Raw-Printing#filesystem.

then polling for results files c:\known-location\in.txt, c:\known-location\receipt.txt, c:\known-location\customer-receipt.txt

This would be custom and is a very dangerous request as it could lead to the leaking of private data (reading someone's documents, word, excel, etc).

What you're describing is more File IO from the description. Can you explain what "chip and pin" hardware is exactly and what the recommended method is for interacting with this hardware?

[shanly]

By chip and pin device I mean a credit card device where you swipe your card and enter pin to charge your card an amount.

The recommended integration is through a file interface where you write a file to a known location. This file is then picked up by the chip and pin software and a transaction initiated on the card swipe device. The result of this is then written back to a file.

The simplified loop is like above write file, poll for result file, read file and process.

From a security perspective the location can be narrowed to only specific directory and even specific filenames? These could be added as part of configuration?

This is similar to the Firefox plugin we currently have doing this - it reads and writes only to a configured single location.

[shanly]

Might help if I give full flow:

Context:

• A PC running our POS software in a browser
• Same PC running software that works with attached chip and pin card reader
• A boxoffice staff member
• A customer with a chip and pin credit card

Steps:

• Staff member adds tickets to order with input from customer
• Once order finalized the customer decides to pay the amount, 99euros, by card
• Our POS software writes a file to c:\known-location\out.txt with this request for 99euros
• The chip and pin software picks up this transaction and initiates a connection to the chip and pin hardware for a charge of 99 euros
• The customer accepts charge, enters their pin and is successfully charged
• This result is then communicated back to chip and pin software which writes results to files c:\known-location\in.txt, c:\known-location\receipt.txt, c:\known-location\customer-receipt.txt
• Our POS picks up these files and captures the payment information and completes the order and prints the tickets

All of this is currently done using a FF plugin.

[tresf]

@shanly are these files encrypted? In the US, there are strict regulations against storing CC information on the PC, so any payment hardware we'd expect to utilize a proprietary, encrypted-over-the-wire API.

I've worked with some manufacturers using direct USB or using keyboard emulation however this is the first I've heard of a two-way flat file interface. Can you share some information about the hardware, how prominent it is and if it's U.S. PCI-DSS (Payment Card Industry Data Security Standard) compliant?

[shanly]

The files aren't encrypted because there is no credit card information in the files. Its just essentially an amount passed to the software on the PC which communicates securely with the chip and pin device and gives an answer back. At no stage do we actually see or pass card information - its a request for an amount and in essence success failure response.

The company behind this is one of the biggest players in the UK and Global payments market, (~5,000 staff), and is fully PCI-DSS compliant. The product we integrate with is common place in the Theatres we sell our product into.

I'm purposefully not adding the company name here as I'm not sure but think there are some disclosure agreements in place.

[tresf]

I'm purposefully not adding the company name here as I'm not sure but think there are some disclosure agreements in place.

Perhaps obtaining the hardware is fastest then. Is the hardware cloud-enabled and cloud-to-IoT encrypted and in turn only uses the filesystem for currency data (or a USB-to-middleware-to-cloud) tethering?

Also does the hardware have a free or very cheap developer API that would be adequate for our test lab?

The reason this information is important is because there are several players in this space and without any other hardware to compare to, we're blind to the industry standards in this space. My PCI experience dates before the smart chips were introduced, but leveraged a USB cable which did 100% of the communication. It sounds like things have changed since then, we just need to know how.

If you are actually from the hardware manufacturer itself, we should talk privately.

Edit: And if the path to c:\known-location\customer-receipt.txt is a safe area, we can do much more to add this to our API then if it's arbitrary.

For example, we would have no objections to reading and writing to %APPDATA%\qz\customer-receipt.txt but we would decline any writing to the root of C:\, or any startup area (or to our own preferences, logs, etc).

[tresf]

Microsoft recommends using %ProgramData% for locations which must be shared by all users. %APPDATA%\qz is always available too, but that would rely on all services running in user-space and being able to expand wildcards.

For design purposes, we'll use %ProgramData%/qz for Windows however we will need to find a shared path for Linux and macOS as well.

[mrloop]

Just updating with reference to spike, see #178

[tresf]

This has been fully implemented in #306. Ready for testing/review/merge into the 2.1 branch.

[tresf]

Closed via #306.