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;
SambaPOS need to post XML info to the machine on local port.
Machine does its stuff
Machine returns XML response.
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.
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>
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]
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.
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.
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.
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.
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.
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âŠ
@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 .
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
Create XML packet according to their spec (you always need the End Point spec);
Load XML into a object or program reference point;
Post the XML packet to End Point - âresult = SendXMLPost(object, para1, para2)â;
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!
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
just had to sign that I would keep safe and return as received when finnished 
helpful documentation LOL
