Portalum / Portalum.Zvt

A .NET Zvt Library for Payment Terminals (C#)
MIT License
88 stars 36 forks source link

Problems with Verifone VX820 #8

Closed amaneshi closed 2 years ago

amaneshi commented 2 years ago

Hello! Thank you for sharing such great library! This is not actual issue - just a report on problems with Virifone VX820.

In code I saw that you use SimpleTCP client with keep alive settings enabled, and in TestUI project this should work - like we press "connect" button and then connection exist before we don't close it manually (and we can test other functions, like payment, diagnosis etc).

When I try to use such approach to connect to terminal in TestUI despite "keep alive" - connection get closed after 1-2 seconds of inactivity. So I cloned your repo and rewrite flow to open connection, execute command and close connection.

Another problem that I encountered with my terminal - when I called function "diagnosis" one of received packets with status receipt (which contain a lot of printable text) got fragmented. Its total size was 1648 byte, but received it with 2 events - first with 1024 byte, and second with rest. As result both packages failed BMP integrity check (length) so this messages was lost. Not sure if this should be fixed in your code, as this more like some problems of TCP library (as it is throw 2 events "data received"). But also this can be limitation of package size in terminal itself - not sure in this (then maybe add some buffer to assemble fragmented packages...).

tinohager commented 2 years ago

Hello I have been following your fork. The goal of this project is to improve the fragmentation of the ZVT protocol, there was no real open source implementation until this project, at least none that I found. So we took care of it ourselves. It would be nice to reach a point where you can tell the payment service provider you are using this project and get a straightforward acceptance. Their complete spin-off does nothing to help that goal, unfortunately.

I think for security reasons it is not useful to disconnect again and again because only one connection to the device can remain open. If you close the connection, another program could connect in the meantime and lock you out.

With which payment service provider is the device used?

Can you record the communication with a network sniffer? For example with Smsniff? And make them available to me?

amaneshi commented 2 years ago

Nice weekend! Thank you for response!

Its hard for me to help you with provider - I develop outsource project and was provided this hardware as is (with configuration inside already). If you advice how to find it out I can share. Initially it was provided to me with demo project that used monstrous "pepper" library (maybe this is a provider also) and was implemented with it. But don't like it, very heavy and "strange" (especially in Unity) and cost money.

Then I got next project (UWP) and use this same hardware (as protocol ZVT) to prototype feature till client not decided on provider and send me new hardware, and after searched for opensource, selected your library as base. Then they look like decided (sent FirstData SoftConnect 4.2 lib of mid 2020 year, now company rebranded and I cant find where they took it, and terminal Verifone V400M - but don't have it now). I tried SoftConnect demo program with their lib - and its working too (same as pepper) - but not liked it as it use C DLL lib and INI file for config and we need to set parameters dynamically in project.

Not sure on pepper lib (not tried) - but SoftConnect use same flow as I implemented - connect, send command, receive response, disconnect (and this clear in their logs).

I will make record of fragmented part and share with you later... and compare with SoftConnect C native library

tinohager commented 2 years ago

We have also already worked with Pepper (Treibauf). In the meantime, Pepper also offers a Docker container. Whereby we had various difficulties with the implementation of a client. Since the further development took too long, we decided to do the implementation for ZVT ourselves. Pepper basically offers much more than just the ZVT protocol, which is what we actually need the most.

But I can completely agree with you, I am not a friend of C implementations either.