gohanman
commented
9 years ago Architecture and IPTrans / Remote Hardware
This post covers how "traditional" integration communicates, how the PDCX/EMVX integration communicates, and how one of these models might be adapted to IPTrans.
Traditional / Current
- On the page where the cashier initiates payment, there's an AJAX call to begin processing.
- The PHP-side receiving end of the AJAX call builds request XML, submits the request using cURL, waits for a response, parses the response, and returns a JSON object to the original AJAX call
- The javascript on the payment page examines the JSON response object and redirects to display a success or error result.
PDCX/EMVX
- On the page where the cashier initiates payment, PHP builds the request as the page loads and embeds it directly into page.
- An AJAX call on the page lifts the request body out of the page and POSTs it directly to the driver via HTTP.
- The driver passes the request through the relevant ActiveX and returns the XML response to the AJAX call
- The page javascript POSTs the whole response to PHP to parse, save, and redirect to a success or error page.
While the newer approach involves more steps, I think eliminating cURL makes some parts of the process simpler. Timeouts/limits related to cURL itself, PHP execution time, and Apache execution time all go away. The main "waiting" communication is the AJAX call to the driver; long-polling and delayed responses is much more normal and well supported behavior on the javascript side. Another key difference is the request isn't just waiting for network communication. It's waiting for the customer to interact with the card reader as well as communicate with the processor. The human part is going to make average turnaround time on these requests slower to avoiding potential timeouts is important.
Remote / IPTrans / Non-ActiveX
There's no particular reason the driver and POS need to be on the same machine. A non-Windows lane could POST requests to a remote Windows box that manages the hardware card reader. This may be difficult from a physical infrastructure standpoint (wiring, extra computers, etc) but isn't really a technical challenge.
The current IPTrans implementation works like this: the driver accepts XML requests via HTTP and is responsible for resolving platform issues. With this setup, the driver listens on the same port and accepts identical requests regardless of platform.
- The windows driver feeds the XML body directly into an embedded ActiveX control, gets the response, and sends it back to the client (POS).
- The linux driver forwards the XML body along to the IPTrans by way of the Java listener app, gets the response, and relays it back to the client (POS).
Both drivers perform some manipulations on the POS generated XML. Some of these manipulations are common to both platforms and some are driver specific but the general idea is to isolate the POS side from extra complexity.
This may turn into a perpetual issue for a while. But I think there's enough progress to be newsworthy.
Background
The suggested solution for EMV support uses an ActiveX control called EMVX. This control handles all card data and processor communication keeping POS out of scope. As with most things EMV, timelines are hazy. This is not an option for live transactions yet. A similar ActiveX control, PDCX, exists for traditional credit/debit/EBT transactions. It operates in a similar manner keeping POS out of scope. My current goal is to get this stuff working in Windows since it's ActiveX.
Driver modules
There are two new driver modules available. SPH_Datacap_PDCX uses the PDCX ActiveX control; SPH_Datacap_EMVX uses both ActiveX controls. It's unclear at this point whether EMVX can handle all non-EMV cards or if some will have to fall back to PDCX. Creating .NET wrappers for ActiveX controls does add some extra complexity to the build process. Updated documentation: https://github.com/CORE-POS/IS4C/blob/master/pos/is4c-nf/scale-drivers/drivers/NewMagellan/README
Current functionality
Notable differences between the two ActiveX controls
PDCX works. With test cards and a test-keyed terminal, I get actual authorizations back from the processor. It could theoretically be rolled into production use in short order. PDCX does not allow the customer to choose a card type. PDCX does not allow the customer to enter cash back. PDCX does not require the customer confirm the amount (this is not configurable as far as I can tell). PDCX does have an option to get a signature although I don't have any hardware to test that function with. PDCX supports several hardware options although the VX805 is the only one I've used.
EMVX works but it currently requires a locally installed NETePay server. It now appears this requirement is not likely to change any time soon. EMVX does allow the customer to choose a card type if they swipe the card. If they insert the card instead, the chip & terminal decide whether a PIN or signature is required. I'd guess contactless behaves the latter way but haven't got that input method to work with the test cards. EMVX has an option to prompt the customer for cash back. EMVX does require the customer confirm the amount (this is not configurable as far as I can tell). EMVX does not have any signature capture functionality. Hardware support appears limited to the VX805 at present.
Tested Transactions
Working as of August 21, 2015
Not working as of August 21, 2015
Overall Status
This is certified for [beta] production use by the processor although no one is doing that yet. Gift cards in particular may have some WFC-specific things baked in. I'm only logging transaction detail in the PaycardTransactions table and not the set of legacy efsnet* tables. I'm very tempted to make a clean break here, drop the efsnet nonsense entirely and re-write any backend reporting as needed. Some kind of menu or UI is needed to deal with all the card-type specific commands.
Both PDCX and EMVX are now certified. EMVX will require a locally installed NetEPay server and that piece isn't quite ready yet but I'm told will be in the next week or so.