IDTech Sign&Pay Vendor and Setup

[hozt]

We will be switching to Mercury for payment processing once we go live with Core. Can anyone recommend a good vendor for purchasing these terminals? Thanks!

[gohanman]

http://http://www.jrposdepot.com is the only choice AFAIK. The device itself can be purchased elsewhere but you have to go through JR's for key injection. It needs a PIN encryption key and an MSR encryption key. Mercury is requiring CORE to use end-to-end encryption. That has a fair number of benefits, of course, but initial setup is a bit more of a headache.

On Thu, May 29, 2014 at 5:11 PM, hozt notifications@github.com wrote:

We will be switching to Mercury for payment processing once we go live with Core. Can anyone recommend a good vendor for purchasing these terminals? Thanks!

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/359.

[jdpurdyvi]

TASQ (http://www.tasq.com) is another company that can provide encryption services. They stock some Mercury approved terminals. Just not sure if they have the IDTech terminals.

[joelbrock]

Important: JR's Depot needs to inject the GPI, E3Test as well as the E2E (end to end) key loads for the IDTechs to work properly. And, repeating Andy: they need the PIN and MSP keys.

Re-stating since they (JR's) seem to never get it right the first time, then you have to ship them back and wait.

On Thu, May 29, 2014 at 6:28 PM, purdy notifications@github.com wrote:

TASQ (http://www.tasq.com) is another company that can provide encryption services. They stock some Mercury approved terminals. Just not sure if they have the IDTech terminals.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/359#issuecomment-44605751.

[pierced]

What is "GPI" and "E3Test"?  
  I am having my IDTech terminals upgraded because they were all
  running SecureHead version 1/23.  I told Mercury to have the
  "Mercury E2E MSR Key" and well as the Debit (PIN).  Do I need
    to tell them to Inject "GPI" and "E3Test" also?
  If ordering new IDTech terminals make sure the new terminals will
  be running SecureHead 1.31 (see a note from Andy below):

--------------------------------------------------------------------------------------------------------------> If "SecureHead" version is 1/23 rather than 1.31, you're most likely running

into an ID Tech bug that occurs after ~50k card swipes where it stops producing valid output. I had to send some of my devices into ID Tech for repairs when this happened (and then send them to a company called JR POS

> Depot to have encryption keys reinjected).

---

Don Pierce Information Systems Manager Harvest Co-op Markets

617-661-1580 ext.123

From: joel brock <notifications@github.com>Sent: Thursday, May 29, 2014 :45PMTo: CORE-POS/IS4C <IS4C@noreply.github.com>Subject: Re: [IS4C] IDTech Sign&Pay Vendor... (#359)
Important: JR's Depot needs to inject the GPI, E3Test
  as well as the E2E

  (end to end) key loads for the IDTechs to work properly.

  And, repeating Andy: they need the PIN and MSP keys.

  Re-stating since they (JR's) seem to never get it right the first
  time,

  then you have to ship them back and wait.

  On Thu, May 29, 2014 at 6:28 PM, purdy
  <notifications@github.com> wrote:

  > TASQ (http://www.tasq.com) is another company that can
  provide encryption

  > services. They stock some Mercury approved terminals. Just
  not sure if they

  > have the IDTech terminals.

  >

  > —

  > Reply to this email directly or view it on GitHub

  >

https://github.com/CORE-POS/IS4C/issues/359#issuecomment-44605751.

— Reply to this email directly or view it on GitHub.

[gohanman]

I've never heard of or specified anything about GPI or E3Test. I don't know what either means and there's no place for those on the ordering form I've used.

On Fri, May 30, 2014 at 5:20 AM, pierced notifications@github.com wrote:

What is "GPI" and "E3Test"? I am having my IDTech terminals upgraded because they were all running SecureHead version 1/23. I told Mercury to have the "Mercury E2E MSR Key" and well as the Debit (PIN). Do I need to tell them to Inject "GPI" and "E3Test" also? If ordering new IDTech terminals make sure the new terminals will be running SecureHead 1.31 (see a note from Andy below): --------------------------------------------------------------------------------------------------------------> If "SecureHead" version is 1/23 rather than 1.31, you're most likely running

into an ID Tech bug that occurs after ~50k card swipes where it stops producing valid output. I had to send some of my devices into ID Tech for repairs when this happened (and then send them to a company called JR POS Depot to have encryption keys reinjected).

---

---

Don Pierce Information Systems Manager Harvest Co-op Markets

617-661-1580 ext.123

From: joel brock notifications@github.comSent: Thursday, May 29, 2014 :45PMTo: CORE-POS/IS4C IS4C@noreply.github.comSubject: Re: [IS4C] IDTech Sign&Pay Vendor... (#359)

Important: JR's Depot needs to inject the GPI, E3Test as well as the E2E

(end to end) key loads for the IDTechs to work properly.

And, repeating Andy: they need the PIN and MSP keys.

Re-stating since they (JR's) seem to never get it right the first time,

then you have to ship them back and wait.

On Thu, May 29, 2014 at 6:28 PM, purdy notifications@github.com wrote:

TASQ (http://www.tasq.com) is another company that can provide encryption

services. They stock some Mercury approved terminals. Just not sure if they

have the IDTech terminals.

—

Reply to this email directly or view it on GitHub

https://github.com/CORE-POS/IS4C/issues/359#issuecomment-44605751.

— Reply to this email directly or view it on GitHub.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/359#issuecomment-44636280.

[pierced]

hmmm maybe Joel can shed some
  light on this

---

Don Pierce Information Systems Manager Harvest Co-op Markets

617-661-1580 ext.123

From: Andy Theuninck <notifications@github.com>Sent: Friday, May 30, 2014 :44AMTo: CORE-POS/IS4C <IS4C@noreply.github.com><Cc: Don PierceSubject: Re: [IS4C] IDTech Sign&Pay Vendor... (#359)
I've never heard of or specified anything about GPI or
  E3Test. I don't know

  what either means and there's no place for those on the ordering
  form I've

  used.

  On Fri, May 30, 2014 at 5:20 AM, pierced
  <notifications@github.com> wrote:

  >

  > What is "GPI" and "E3Test"?

  > I am having my IDTech terminals upgraded because they were
  all

  > running SecureHead version 1/23. I told Mercury to have the

  > "Mercury E2E MSR Key" and well as the Debit (PIN). Do I need

  > to tell them to Inject "GPI" and "E3Test" also?

  > If ordering new IDTech terminals make sure the new terminals
  will

  > be running SecureHead 1.31 (see a note from Andy below):

  >

-------------------------------------------------------------------------------------------------------------->

If "SecureHead" version is 1/23 rather than 1.31, you're

  > most likely running

  > > into an ID Tech bug that occurs after

  > ~50k card swipes where it stops

  > > producing valid output. I had to send

  > some of my devices into ID Tech for

  > > repairs when this happened (and then

  > send them to a company called JR POS

  > > Depot to have encryption keys reinjected).

  >

  >

---

  >

  >

  >

  >

  > --------------------------------

  > Don Pierce

  > Information Systems Manager

  > Harvest Co-op Markets

  > 617-661-1580 ext.123

  > --------------------------------

  >

  >

  > From: joel brock <notifications@github.com>Sent:
  Thursday, May 29, 2014

  > :45PMTo: CORE-POS/IS4C
  <IS4C@noreply.github.com>Subject: Re: [IS4C]

  > IDTech Sign&Pay Vendor... (#359)

  >

  > Important: JR's Depot needs to inject the GPI, E3Test

  > as well as the E2E

  >

  > (end to end) key loads for the IDTechs to work properly.

  >

  > And, repeating Andy: they need the PIN and MSP keys.

  >

  > Re-stating since they (JR's) seem to never get it right the
  first

  > time,

  >

  > then you have to ship them back and wait.

  >

  > On Thu, May 29, 2014 at 6:28 PM, purdy

  > <notifications@github.com> wrote:

  >

  > > TASQ (http://www.tasq.com) is another company that can

  > provide encryption

  >

  > > services. They stock some Mercury approved terminals.
  Just

  > not sure if they

  >

  > > have the IDTech terminals.

  >

  > >

  >

  > > —

  >

  > > Reply to this email directly or view it on GitHub

  >

  > >

  >

https://github.com/CORE-POS/IS4C/issues/359#issuecomment-44605751.

  > >

  > —

  > Reply to this email directly or view

  > it on GitHub.

  >

  > —

  > Reply to this email directly or view it on GitHub

  >

https://github.com/CORE-POS/IS4C/issues/359#issuecomment-44636280.

— Reply to this email directly or view it on GitHub.

[joelbrock]

GPI and E3Test are standard. You dont need to tell them to add those. THis was according to the technician i spoke to at JRs Depot

[hozt]

Thanks for the help. We ordered a terminal from JR's Depot.

I then enabled credit cards in the IS4C configuration and set the processor to MercuryE2E. In the file MercuryE2E.php there are two values that need to be populated:

define('MERCURY_TERMINAL_ID',""); define('MERCURY_PASSWORD',"");

Is the terminal ID the serial number of the Sign and Pay device? Is the password our "Web services password" we received from Mercury?

When I try those value the terminal just displays "waiting for cashier". The output of the pos.exe driver is showing activity after each step of the process.

[gohanman]

Those are values from Mercury. Password is the web services password, and terminal ID is the corresponding merchant account number (I forget their exact terminology). That's poorly named in CORE; it predates having an actual hardware terminal.

The terminal has no internet connectivity, so it's just handing the encrypted data over to the PC and is, in fact, waiting for the cashier to do something with it. "CC" in POS should bring up a list of card-related commands, otherwise "CCFROMCACHE" bypasses the menu and offers to charge the card.

Mercury's setup is a bit finicky about live vs testing cards. If the ID Tech has the "testing" encryption keys, you need to provide the testing web services credentials. Signing in as the test cashier (9999) will use these credentials. If the ID Tech has "live" encryption keys, you need to provide the actual account credentials. Signing in as any other cashier will use the values specified as MERCURY_TERMINAL_ID and MERCURY_PASSWORD in MercuryE2E.php. This makes testing annoying and/or expensive if you have to keep charging a real card. A mismatch between keys and credentials results in a decryption error message.

For a partial - but free! - test, you can sign in as the test cashier using a live ID Tech. If you go through the process and get a decryption error, it means: 1) The lane PC received the relevant info from the ID Tech 2) Mercury received the request and understood it 3) The lane received Mercury's response and understood it

If all you have is the live terminal, I'd verify that approach yields the expected error first before trying to charge a card for real. No need to rack up excess charges during testing.

[hozt]

I did confirm that our terminal is configured only with production keys.

I pulled down the all the latest code and rebuilt the pos.exe driver again. I then updated my values in the MercuryE2E.php, but still nothing is happening once I initiate the charge through the Core. I also tried this with the 9999 test cashier and had the same result. Watching the output from pos.exe it does show that the driver is reading the card information.

Rebooting the terminal from the CC menu does work, but reset causes the CC terminal to go blank. Another thing I am seeing is that the credit card logo is showing "test" on the screen.

[gohanman]

This is what the process should look like. Maybe that'll help identify where things are going wrong.

First screen. Using the TermStateNotifier under the scale box can help verify POS is getting information from the device.

That box should change as info is entered into the terminal. The green box around the visa-y icon is a good sign too but might require a page refresh.

After entering all needed information at the terminal:

Entering the credit card menu:

Next is a confirmation of the amount:

Sending to the processor & waiting for response:

Got response; waiting for signature:

Added tender, done w/ transaction:

What step's going wrong for you?

[hozt]

I must be missing a critical step because each time I select CC or CCFROMCACHE nothing happens after the popup screen with the 4 options. I do not see any of the screens that you show above nor do I see the green around the icon. Sometimes after pressing CC the popup screen flashes and then closes right away. I have tried this in multiple browsers with the same result.

Andy, I appreciate your help in getting this working. After it works I will document the process so others will have an easier time with setting this up. Would you or someone else that has successfully configured the Sign&Pay be willing check out our test lane? My direct contact is it@medfordfood.coop. Thanks!

[gohanman]

We may have missed a step, or at least encountered a typical problem in an unexpected place. If you're not getting the green icon, even after refresh, the pos.exe and the browser probably aren't communicating correctly. Most people run into this when the scanner-scale doesn't work, but perhaps you don't have one attached to your test lane yet?

There are two different communication channels. When the browser sends a message to the driver, it sends that message directly via UDP. When the driver sends a message to the browser, it write that message to a file that the browser is polling. The driver => browser communication is what tends to not work out of the box.

When pos.exe is running, it ought to be creating files in is4c-nf/scale-drivers/drivers/NewMagellan/ss-output/. The browser ought to be polling that directory for files. The user running pos.exe and the user running PHP both need write access to that folder (or just 777 for testing's sake). You should be able to just create a file in that directory containing a UPC and verify that item gets rung into the transaction. If the item isn't rung in, there's a polling issue. Make sure the "Scanner/scale driver" is set to "NewMagellan" on the config Extras page.

If my guess is wrong, we could certainly set up some kind of screen share / conference call thingamajig to debug.

[joelbrock]

Also, the ports.conf file in is4c-nf/scale-drivers/drivers/NewMagellan

On Thu, Jul 17, 2014 at 10:00 AM, Andy Theuninck notifications@github.com wrote:

We may have missed a step, or at least encountered a typical problem in an unexpected place. If you're not getting the green icon, even after refresh, the pos.exe and the browser probably aren't communicating correctly. Most people run into this when the scanner-scale doesn't work, but perhaps you don't have one attached to your test lane yet?

There are two different communication channels. When the browser sends a message to the driver, it sends that message directly via UDP. When the driver sends a message to the browser, it write that message to a file that the browser is polling. The driver => browser communication is what tends to not work out of the box.

When pos.exe is running, it ought to be creating files in is4c-nf/scale-drivers/drivers/NewMagellan/ss-output/. The browser ought to be polling that directory for files. The user running pos.exe and the user running PHP both need write access to that folder (or just 777 for testing's sake). You should be able to just create a file in that directory containing a UPC and verify that item gets rung into the transaction. If the item isn't rung in, there's a polling issue. Make sure the "Scanner/scale driver" is set to "NewMagellan" on the config Extras page.

If my guess is wrong, we could certainly set up some kind of screen share / conference call thingamajig to debug.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/359#issuecomment-49334430.

[hozt]

I have the scanner-scale connected and it is working. There are files being created in the ss-output directory. When I load the pos.exe I do see that my IdTech changes to "Please Swipe Card". My ports file does have these two options selected: /dev/ttyS0 SPH_Magellan_Scale /dev/hidraw0 SPH_SignAndPay_USB

I did confirm that I am using the latest code from the master repository.

I do have the paycard module "MercuryE2E" enabled and the "Integrated Credit Cards" set to yes. Tender mapping is set for "CC" to "CreditCardTender". Scale driver is set to "NewMagellan".

Now when I select "CC" I am getting "input unknown". "CCFROMCACHE" yields nothing.

If I cancel a transaction the screen on the IDTEch goes blank until I restart the pos.exe process again.

There are no php errors during this process.

[gohanman]

Well, the blank screen is probably a timing issue. Assuming "use Windows" isn't an acceptable solution, running pos.exe with the -v switch often addresses it (I don't know how to make asynchronous USB I/O work properly in linux).

The it@medford email kicked a rejection notice back to me. I'm andy AT wholefoods DOT coop if you want to schedule a phone call to try and sort through this better.

[hozt]

I had to enable both the QuickMenus and Paycard plugins. Under the "Extras" settings I then enabled the TermStateNotifier as suggested. Now everything is working much closer to what you described.

Once the customer swipes the card I do get a response in the notify area as the screens above show. When I then press CC it flashes the menu then immediately brings up the Tender confirmation. After pressing "Enter" I get the processing message and then this error: "Error: Merchant Setting Does Not Accept RecordNo."

Credit card terminal is then stuck on "Waiting for cashier". Press CC again and at confirmation click clear causes the IDTech screen to go blank.

[gohanman]

That's actually huge progress. That's an error from Mercury rather than CORE. So they're receiving your request and sending back an error message. You should be able to work around it in the short term by setting MERCURY_USE_TOKENS in MercuryE2E.php to false. Long term, you probably want tokenization enabled on your merchant account. What it does is send a unique code back with each authorization, and you can use that code to make adjustments to that authorization (e.g., void it or issue a refund) without having any card information. It only works with credit though not debit or EBT.

The quickly flashing menu is because the menu page is getting a javascript keyup event on enter. It's probably from typing CC[enter] on the previous page but the browser doesn't separate them cleanly. I'm attempting to catch those spurious events and avoid them but it isn't perfect yet.

Clear from the confirmation screen is identical to reset from the CC menu [when said menu sticks around long enough to offer options]. It's the same timing problem.

[hozt]

Setting the tokens to False does get farther. We now get an error about "Merchant Setting Does Not Accept Encrypted Data".

Are these settings something we can change in the Mercury interface? I do not see any way to change settings at https://portal.mercurypay.com.

[gohanman]

Not that I know of; I think you have to contact Mercury support. That one, unfortunately, is not optional. Mercury only certified CORE for encrypted card data so it needs to be enabled. I know you can have multiple merchant account numbers with different settings/features associated with a single login to the portal.

On Mon, Aug 4, 2014 at 7:55 PM, Jeff Haug notifications@github.com wrote:

Setting the tokens to False does get farther. We now get an error about "Merchant Setting Does Not Accept Encrypted Data".

Are these settings something we can change in the Mercury interface? I do not see any way to change settings at https://portal.mercurypay.com.

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/359#issuecomment-51137602.

[hozt]

Mercury needs to know this to setup the account: Core POS v 1.x - E2E/MToken and is associated with the developer account The Tech Support Cooperative BID 487324.

I can successfully process a debit card, but after the transactions completes the screen on the IDTech goes blank.

Another issue is when I try to process a credit card I can not sign on the terminal. The IDTech screen flashes when I select "request signature", but nothing I do can get past this.

[gohanman]

The terminal is buggier in general in linux (or, rather, I don't know enough about the OS' USB subsystem to make it work correctly). Running the driver with -v helps sometimes. Otherwise, fiddling with the DEFAULT_WAIT_TIMEOUT in SPH_SignAndPay_USB.cs may help.

[hozt]

I tried changing the DEFAULT_WAIT_TIMEOUT both increasing and decreasing it and did not see any change to the signature screen. The touch screen works on the other screen, just not the signature screen.

Do you know if anyone has it working under linux?

[gohanman]

Rutland VT is, and Harvest was for a while (they switched to windows because of printer issues though, not terminal issues).

This seems to help some on my available linux test environment: af8e6fe0a37dc43525ecdcdd4c6f529b95f5edc0

On Tue, Aug 5, 2014 at 12:50 PM, Jeff Haug notifications@github.com wrote:

I tried changing the DEFAULT_WAIT_TIMEOUT both increasing and decreasing it and did not see any change to the signature screen.

Do you know if anyone has it working under linux?

— Reply to this email directly or view it on GitHub https://github.com/CORE-POS/IS4C/issues/359#issuecomment-51233841.

[hozt]

Fantastic, that worked! We will do more testing and see if I can find any other issues.

[gohanman]

Fix for the timing issue is in 0.9.17