Hi all, I'm a software engineer currently working on a kiosk machine project. I am required to integrate pinpad, POS printer and touchscreen so that customer are able to order stuff through the kiosk. However I am having problem connecting the pinpad with POS for.Net 1.12, I have tried using Service Object Manager Utility created by Sean Liming, however the application didn't detect my pinpad. I tried the pinpad using hyperterminal and it shows that it is connected through COM1 port. I used the POSExplorer class to list the devices detected also to no avail. Do I have to install a specific driver for the pinpad for it to be detected? I am using Sagem EFT930S pinpad.
Plug the USB interface directly into the USB socket.if the voltage in the USB interface is below the +5V DV, or below the 300mA, please use the external DC+8~10V instead. RS-232 and USB can’ be used at the same time.if at the same time,USB is prior to the RS-232. 4.2 4.2 DRIVER PROGRAM INSTALLATION RS-232 need the matched driver program. Get technical support, drivers and downloads for your VeriFone PINpad 1000SE.
Thank you in advance for your attention and help. Regards, Andika. Hi, See Sean's reply.
![Pinpad Zt588 Driver Pinpad Zt588 Driver](http://www.bpress.cn/list/di/pic/98/295298.jpg)
The only thing I would add is that generally there is no such thing as a 'generic' service object. Some service objects can work with multiple devices, and the sample service object for Barcode Scanners provided by MS can be used as a sort of generic SO but it's not perfect. Likewise, Cash Drawers are simple enough that you may be able to find or use a generic SO for some of them, but I would rather have a manufacturer specific one to ensure pulse lengths and status capture are correctly implemented. Service objects are the 'middle' layer that understand a specific device's (or range of devices) capabilities and therefore they tend to be specific to a device, or at least a make of hardware. The design of UPOS is that service objects aren't really generic, they are the layer where the deviec specific code resides.
Even if you can get a 'generic' service object, it's questionable as to whether you should use it in favour of a more specific one or not. PinPads are not generic. Typically, there is a special SDK for PinPads.
Looking at some of the Sagem datasheets, they list an SDK available. You will need the SDK to develop a Service Object. As York pointed out, you might want to contact the manufacturer for more information.Sean www.sjjmicro.com / www.seanliming.com, Book Author - XP Embedded Advanced, XPe Supplemental Toolkit, WEPOS / POS for.NET Step-by-Step ' PinPads are not generic. Typically, there is a special SDK for PinPads. ' This is not really accurate. Please provide some documentation to support your claim that Pinpads are not generic.
UPOS and OPOS are standards, therefore any devices developed to the standard should work. It is true that you may need a driver from the manufacturer to get the pinpad working, but I have never heard anything about needing an SDK. To the contrary, I have tested several different pinpads against OPOS over POS for.NET and they work fine without needed an SDK.
From past PinPads discussions on this forum, the PinPad devices that developers have asked about required an SDK. The datasheet to the Sagem device called out in this post calls out an SDK. If you have a list of PinPad devices that don't need the extra SDK and have OPOS driver, then please post them. This would be a great help to everyone. I will be more than happy to post on my website.Sean www.sjjmicro.com / www.seanliming.com, Book Author - XP Embedded Advanced, XPe Supplemental Toolkit, WEPOS / POS for.NET Step-by-Step. Indeed, in fact I don't think.any. of the EFTPOS device providers in New Zealand (and possibly Australia) have UPOS drivers for their gear, instead they have their own SDK's.
Does anyone know if the UPOS spec is even PCI-DSS compliant? That standard was recently enforced here in NZ and required many retailers to upgrade their hardware and software. Certainly the two EFTPOS device integrations I've done, and the three others I've looked at doing have all required a 3rd party SDK and not UPOS/OPOS/Pos.Net support. Of course that's not to say that's the case in the US etc. Yort, To my knowledge there are currently no UPOS service objects for Pinpads.
The OP mentioned OPOS so that is what I was referring to. As for PCI-DSS that is a function of the device itself and the underlying software that stores the data as I understand and not of UPOS or OPOS. It is the device itself that is certified, not the communication method. In any event, both OPOS and UPOS allow for passing the encrypted pin block. As for the SDK, that is not required in the US as I can attest from personal experience.
Hi, UPOS is the standard that both OPOS and Pos.Net are based on, when I said 'UPOS service objects' I meant OPOS or Pos.Net or JavaPOS, all of which are UPOS implementations. Therefore, by my reasoning, if there are OPOS drivers then there are UPOS drivers since OPOS is an implementation of UPOS. Sorry to confuse you. As for the PCI-DSS, yes the device and the software have to be certed, I understand that.
But since the UPOS implementation (i.e either Pos.Net, OPOS or JavaPOS) is part of the software, along with the service object, I was curious to know if they had any issues with compliance. For example, storing the card number (at least if it's unencrypted) anywhere is an no-no, so if Pos.Net logged the track data to a disk file when logging was enabled that would then be in violation of the standard. You said they support encrypted transmission of data, which is probably good enough. So long as the encrpytion used is strong enough for the PCI-DSS standard (to be honest, we didn't have to deal with this to get compliance, since the EFTPOS SDK handled it for us and I haven't read the PCI-DSS spec myself so it could all be fine as you suggest). I was just asking out of curiosity. I also understood (from other people that have supposedly read the PCI-DSS spec) that the communication method did sometimes come into the PCI-DSS standard, in terms of data being sent over the network (whether it was wired, wireless or VPN) being properly encrypted as per the PCI-DSS requirements.
Thanks for the info though. It's good to know that if we ever take out product to the US we can expect to provide EFTPOS integration via Pos.Net:). The Verifone sc5000, there was an ARC88, and something else that required an SDK. Someone resently posted about an ID-Tech PinPad that is PCI compliant and has an OPOS driver. It appears that after several years since the release of POS for.NET, there still needs to be a supported device list. Basically, a list of devices that have a Service Objects and OPOS drivers that works with POS for.NET. This might help to eliviate some questions and get developers pointed in the right direction.
I did something like this years ago for CF cards that could boot XPe and it appeared to help. Does this sound like a good idea?
-Sean www.sjjmicro.com / www.seanliming.com, Book Author - XP Embedded Advanced, XPe Supplemental Toolkit, WEPOS / POS for.NET Step-by-Step. I am currently abandoning POS for.Net for now because I really can't find any drivers or software to connect my pinpad to.Net. I am trying primitive way of using System.IO.Ports and connecting the device to serial port. It's kind of troublesome because of the encrypting and decrypting of the message to pinpad, however some simple instructions are working for now such as sales etc. Can you tell me whether I can do it this way? I'm concerned about the pin encrypt and decryption, is it doable using System.IO.Ports?
Unfortunately, your situation is what I have feared and have warned Microsoft POSfor.NET/WePOS team about on several occasions. I am sure Microsoft has a significant investment in this POS tool, but without properly promoting or encouraging it, developers will abandon it for other solutions that are proven and well documented. I would encourage you to give POS for.NET a chance. It has a lot of potential.
There are a few of us on this forum that beat this drum, but eventually I cant really blame those who choose other technologies even including JavaPOS which have wider IHV support, if the commitment from Microsoft isnt there. If you can use the Idtech pin pad (SecurePin 100) it does have an OPOS driver for it on their website (idtechproducts.com). Yeah, I'd rather choose POS for.Net for this project because the library and function is already there, but I am already stucked for almost a week just trying to make device responding and I can't really find any suitable driver.
Changing the pinpad is not really an option because we're purchasing the pin pad for a bank which only provide Sagem pinpad. It's really one of a work trying to figure out the hex and parsing the message out, having library doing that for me will save me a lot of time.