Card/EFTPOS Intergration

For those who are interested I have just received my DEV/Testing EFTPOS terminal to make an attempt as integrated card processing. :smile:

The company is Payment Express http://www.paymentexpress.com/

Literally came today so not got any info on possibilities yet but know many have been looking for a solution.

My understanding so far is;

  1. SambaPOS need to post XML info to the machine on local port.
  2. Machine does its stuff
  3. Machine returns XML response.
  4. SambaPOS acts based on the response

Anyone interested in possibility of using similar machine and offering assistance in the configuration please jump in.
Unfortunately this is not my primary project at the moment so initial progress may be slow.

1 Like

SO first question… XML which my understanding is no so dissimilar from working with JSON.

Have had a quick search but couldn’t find it.
Do we have equivalent of JSON.stringify(requestdata) and web.PostJson(url,requestjson,username,password) but for XML?

EDIT: Probably thinking about this the wrong way, at the minute can test the machine using telnet in cmd.

OK, so if im reading this correctly;

Now that we have the DPS software, PINpad and receipt printer sorted we need to connect to the PINpad. Since we are documenting the XML interface,
connection will be handled via the XML Listener. Port 65 is the default configured TCP/IP port that the XML Listener opens for connection and communication
with your POS application. For Flash/AS 2.0 the port will need to be greater than or equal to 1024.

I should ‘post’ xml to the xml listener which communicates with the terminal.

I will chime in before I go to bed - XML is just another structure block code which IMO is easier than JSON. This is a sample of XML describing books.xml:

<?xml version="1.0"?> <catalog> <book id="bk101"> <author>Gambardella, Matthew</author> <title>XML Developer's Guide</title> <genre>Computer</genre> <price>44.95</price> <publish_date>2000-10-01</publish_date> <description>An in-depth look at creating applications with XML.</description> </book> <book id="bk102"> <author>Ralls, Kim</author> <title>Midnight Rain</title> <genre>Fantasy</genre> <price>5.95</price> <publish_date>2000-12-16</publish_date> <description>A former architect battles corporate zombies, an evil sorceress, and her own childhood to become queen of the world.</description> </book> </catalog>

The Code should have indenting for better presentation as it gives an idea of how it works. Just note this picture is missing the end block for </catalog>

Reference:
https://msdn.microsoft.com/en-us/library/ms762271(v=vs.85).aspx

There will be heaps around as I think it existed before JSON.

The only tricky bit is you can have definition files or WSDL files which can define the structures for quality control of code and input.
Just a start…and never really coded in it.
[EDIT: Night boys, good luck]

2 Likes

I’d definitely be interested.

Did you get the developer terminal for free from them or you need to sign up for a merchant account first?

I have one concern though which not sure if you are aware of - I note this terminal is just the “PIN pad” type, i.e. it doesn’t print it’s own receipt so can only be used connected to a POS which does certain things such as prints the receipt as well. As this is part of the responsibility of the POS software, I believe for you to use this in a real life scenario, SambaPOS needs to have PA-DSS application certification under PCI rules. A merchant will be unable to pass PCI-DSS certification for their business (a requirement of the bank) if they are not using a certificated application. I believe there are costs involved in having an application certified and they can be sizable. Read more here: https://www.pcisecuritystandards.org/hardware_software/

One way I believe to avoid such PA-DSS requirements is using a payment gateway that gives a card terminal but it is linked to their own software app that is installed on the POS. In such case, SambaPOS would integrate with that app instead of the card terminal directly, and therefore is not required to have the certification.

I may be wrong about this, but please do check it because I worked at a company in the past who made POS software and they had to get their software certified before likes of FirstData / Verifone / PaymentSense, etc, would allow integration.

No charge :smile: just had to sign that I would keep safe and return as received when finnished :smile:

Does this answer that question?

Also the machine has two options for print.
Intergrated or direct printing to the EPOS printer installed on the machine. - Think that eleviates Samba from PCI.

For anyone interested and wanting more info this is the documentation I have been given;
http://www.paymentexpress.com/Downloads/DPSEFTPOS_XMLSocketInterface.aspx/

However just notice this on his email;

The installer and DPS client detailed in this document is incorrect, there is no DPS Client and we will install your device for you.

:neutral_face: helpful documentation LOL

Which leaves telnet as only option at the minute…
So question is can we use telnet within scripts? @emre any suggestions?

But know for sure the machine can print its receipts directly to a printer installed on the PC.

Hmm… no mention anywhere of PCI. I would not want to be so naive to assume it alleviates SambaPOS from certification requirements (not implying you ;), I mean in general!). From experience, I have found banks (and outsourced companies they use to handle PCI-DSS compliance - like Security Metrics, TrustWave, etc. - are not very knowledgeable about this and tend to make life difficult for merchants to pass compliance. They will very likely expect the POS application to appear on their list of approved software.

The image you posted refers to the DPS XML interface, but that is just accepting commands from the POS. Is that interface on the card terminal or software installed on the POS? If it’s on the card terminal, I think its same as I first mentioned. Also, the receipt printing is good to see, and like it refers “the receipt data must not be changed” is good to see (as you don’t want responsibility of that part) but however the fact you are in a position for being responsible for printing that receipt (i.e. either via the receipt printer or POS software) means you have the potential to alter it, and therefore could mean PCI would want to check you did the integration correctly, therefore requiring PA-DSS certification.

Please don’t take my comments as negative as I know they seem so, as I would very much love to have card integration in SambaPOS, but I know this whole PCI stuff can cause a roadblock and complications on this sort of thing and it’s good to clear it up before any serious effort is made. :smile:

1 Like

I get what your saying.
He did mention/imply that there would be some form of approval of the integration.
As the in theory samba just tells the machine the transaction details and received a approved etc response and their machine communicates directly with their gateway and samba has nothing to do with the processing/card details it should be good and guessing their check would be that your are providing the approved receipt.

I know, delt with trustwave before - all script read muppets which know less about computers than my grandmother.

Main aim at the minute is to see if samba can actually communicate with the terminal, the machine is a loaner and nothing to loose other than a bit of time on the hope that getting some form of communication with the machine isnt too major job.

Have emailed the chap anyway just to raise the question of PCI responsibilities.

DPS was an old method he said, missed his comment on that. at the minute am communicating directly with the machine via telnet.

This topic is the only useful one relating to telnet

Not really wanting to start having to throw third party apps into the mix, but a quick search I found this Virtual COM Port Redirector, which allows you to send data to a virtual COM port that then gets redirected to telnet (amongst other possibilities). It’s not free ($90) but a starting point and you might be able to find the same type of software as open source / free elsewhere. But if you use that app, then you can send data to the Raw Printer / Port Printer and have it redirected to telnet.

1 Like

I did think an option like that might be a possible avenue.
Have only ever used telnet once so not to sure on the particulars.

Either way I am seeing a problem in ‘receiving’ the response.

Yeah, if I was writing an application to do this, I would have it send then wait for a response. But I don’t think that is possible in SambaPOS at the moment…

1 Like

@markjw
This is the responce from Payment Express regarding PCI;

PCI

You’re POS is clear of PCI but your customers won’t be – exactly the same as any non-integrated solution they are currently using. The full description provided on the PCI page of our device:

“Payment Express EFTPOS isolates the Payment Express approved PTS compliant hardware from third party software such as point of sale and vending applications. Payment Express EFTPOS provides integration middleware for interfacing with such third party software and is designed to allow the third party vendor to separate application functionality from the PA DSS compliant application.”

In regards to connectivity although the previously mentioned DPS client is no long used the process for communicating remains the same that being an XML interface on 127.0.0.1 port 2008;

Connectivity

You don’t have to use telnet, I just used this as an example of example requests and responses sorry for the confusion there. Within the POS you need to be able to communicate to our XML interface which listens on 127.0.0.1 2008 .

1 Like

Hey JTRTech

The process of sending and receiving is reasonably standard with XML posts and receives, The steps typically and I apologize in advance if this is old hat for you (but others may gain something):

Steps

  1. Create XML packet according to their spec (you always need the End Point spec);
  2. Load XML into a object or program reference point;
  3. Post the XML packet to End Point - “result = SendXMLPost(object, para1, para2)”;
  4. Decompile XML receipt sitting in “result”.

The trick for you is to find the SambaPOS mechanism as you guys discussed to send the packet. I am wondering if URL printer will do the job? Certainly has the ability to send…

Using external scripting, IMO, will be too slow and will operate under the proposed “File Monitor Service” emre was looking at.

You really need a HTTPPOST() function in SambaPOS I feel. I am not sure if anything like that exists but would be a great feature! :wink:

1 Like

It does exist in the API. Look at JTRTech’s PMS integration.

web.Upload(url,content)
uploads content to url with POST method.

and

web.PostData(<url>,<data>,[<user>],[<password>])
web.PostJson(<url>,<json>,[<user>],[<password>])

Both functions are identical but web.PostJson function adds “Content-Type”, “application/json” header to the request.

2 Likes

Thanks for your input @pauln, its not old hat for me don’t worry but you have confirmed my thoughts as I originally posted in the hope of something like web.Postxml() helper.

The main issue I can see is its not as simple as post and response as the machine will return multiple responses as the transaction progresses, or at least I believe that’s the case based on what I have seen in the testing stage using telnet.
It is allog the lines of post transaction xml to machine, machine responds in sequence with its steps/progress, in a way showing you what it is displaying onscreen /doing.
–> Post transaction
<-- Display transaction total and insert/swipe card
<-- (card inserted) Display enter pin etc
<-- Display processing
<-- Approved/Denied etc.
<-- direct print to printer installed on machine (integrated receipt not required/optional)

In an ideal world it would be nice to receive these updates in samba as we could use on screen prompts at the insert card and enter pin steps etc.

I think what we need ‘in lay mans terms’ is a XML Interface in ‘Device type’ similar to scales and caller ID

1 Like