Highlighted
Valued Contributor.
Valued Contributor.
260 views

C%24SOCKET to control Verifone Credit Card Reader on USB port %3F

Has anyone been able to control a Verifone Crdit/Debit Card Reader.

The device can communicate either on the network or USB.  I assumed that C$Socket could to the trick.  Can anyone offer advise or help on how to hook this thing up and does C$SOCKET talk to a COM port ?    Randy --- HELP --- I'm drowning in technology that is poorly documented.

 

 

LarryGeeked

Labels (2)
0 Likes
7 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: C$SOCKET to control Verifone Credit Card Reader on USB port?

I took a look for Verifone documentation, and all I found was user documentation, nothing technical. I suspect that you would need to actually contact the company for such doc.

However, I suspect that there is an ActiveX control or a .NET control that does the communication for you. And that you need to utilize that software, not try to talk to the device yourself. Does the device come with software to install?

0 Likes
Highlighted
Valued Contributor.
Valued Contributor.

Re: C$SOCKET to control Verifone Credit Card Reader on USB port?

Randy …. thanks for getting back to my submission.  Hope you had a good holiday in NZ.   Yes, their documentation needs an overhaul.

I have three options that I need to code for  (using AcuGT 9.1.2).

1. To talk directly to a Verifone V400c debit/credit card reader.  It is hooked up to my network and I am trying to get C$SOCKET to talk to it.  When I make the C$SOCKET call to "AGS-CREATE-CLIENT, the return code is always ZERO.  I have the IP address of the device, but am unsure as to what socket # to assign.  I use the one defined by the reader specs, but still does not work.  I'm wondering if C$SOCKET actually works.  So I am stuck and need help.  

2. I also have an interface that will talk directly to Moneris to do credit card validation, payments and credits. using their supplied .NET API library.  I have coded everything needed, but it does not work either.  I have executed the NetDefGen utility and that seems to work OK giving my the required definitions.  However the Acu documentation suggests it is supposed to generate an Event DLL.  But no such library gets created.  When I execute my test routine the CREATE...….statement returns a HANDLE = 1.   I have spent hours reading through the documentation and the sample programs.  So I am stuck and need help.

3. I also have coded that ability to do batched multi-payment requests. I generate and XML file that gets Ftp'd to Moneris for processing.   I am happy to say that it works just fine.

It's frustrating trying to get the first two scenarios working.  I have a relatively simple test file for option 2 that I can supply along with the API library.

Thanks

 

LarryGeeked

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: C$SOCKET to control Verifone Credit Card Reader on USB port?

Sorry, but I won't be able to help with this specific hardware.

We have people using C$SOCKET successfully, and we have people using .NET successfully. So chances are good that this is something specific to this hardware. And without having the hardware and all the necessary software, there is little I can do.

This sounds like a case for hiring Micro Focus professional services.

0 Likes
Highlighted
Valued Contributor.
Valued Contributor.

Re: C$SOCKET to control Verifone Credit Card Reader on USB port?

I appreciate that it is hard to test without the hardware.

However the 2nd scenario is a problem with .Net. where NETDEFGEN is not generating the event DLL library.

LarryGeeked

0 Likes
Highlighted
Valued Contributor.
Valued Contributor.

Re: C$SOCKET to control Verifone Credit Card Reader on USB port?

I have Extend 10.3.1 and C$SOCKET is now talking with the Card Reader using AGS-CREATE-CLIENT.
It also sends and receives a request to receive a payment by swiping a card using AGS-WRITE followed by an AGS-FLUSH.
Then I issue an AGS-READ which works so I receive the acknowledgment from the card reader. However at this point regardless what I do, the buffer keeps the original data that was Read, and just appends subsequent reads to the original read. I tried AGS-EMPTY after reading the data but that does not clear the buffer. I even reset the Card reader so their is no chance it's resending old data.
Also with the release none of the example files mentioned in the documentation are included with the release.

Also, in Debug, the "@!" command to change the execution point does not work, basically almost making debug useless.
So questions:
1) after issuing an AGS-READ and successfully getting the data should calling with AGS-EMPTY work to clear the buffer, (because it is not in my release), or is there another undocumented call to do so.
2) I used AGS-FLUSH after the AGS-WRITE to successfully write the data to the terminal. Do I have to do an AGS-FLUSH after doing an AGS-READ too. (I actually tried this but all it does is appends more data into the buffer).

Some help would be appreciated, or a sample program that shows Writing and multiple Reading would help
Thanks

LarryGeeked

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

Re: C$SOCKET to control Verifone Credit Card Reader on USB port?

First, I use the @! command regularly when debugging, and have never had trouble with it. I just tested it again, and it worked as I expected it to. I'm not sure why it is not working for you.

As an aside, the phrase "doesn't work" is so nondescript. There are so many ways something can not work. In this case, does the execution point jump to a random point? Does it not move at all? Does it crash the runtime? Something else? Note that you need to ensure that the new line you want to move to actually has a verb.

To go back to C$SOCKET - note that when issuing AGS-READ, using a length parameter that is negative tells the runtime to leave the data on the socket. I assume you are not doing this, but I really hate making assumptions.

When you talk about the buffer keeping the original data, I assume you are referring to the COBOL variable that you are passing to C$SOCKET to hold the data being read. (See above about assumptions.) Are you sure that the data is actually being read? Do you move spaces to that variable before issuing the new AGS-READ? Are you checking the return value of C$SOCKET to see how much data was actually read? One possibility here is that the read that is returning the same data is really not returning anything, but is keeping the old data.

The AGS-FLUSH command is intended to throw away bytes that came from the socket. After you have read the data, that data won't be thrown away. The purpose is to do something like the following:

Check how much data is available. Determine that 20 bytes are ready. Read 10 bytes. You know you can ignore the rest, so you can issue AGS-FLUSH with a length of 10 to get rid of the other 10 bytes, so that the next READ (once you know there is relevant data to be read) will not get the 10 bytes you want to ignore.

Since I don't have the hardware, perhaps the best thing to do would be to show me code, with the values of the variables before and after each call to C$SOCKET, along with the return-code after each call. The more detail you give, the better chance I have of being able to help.

0 Likes
Highlighted
Valued Contributor.
Valued Contributor.

Re: C$SOCKET to control Verifone Credit Card Reader on USB port?

Thanks for your reply.  It turns out that because the 1st request that worked did not finish, I had to issued a Cancel and that fixed it.   It's now working.

 

LarryGeeked

0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.