I believe its the ‘xml socket’ if that’s what its called which takes the 127.0.0.1 : 2008 to the machine via COM8.
@emre do you have any ideas?
I can send xml to http://127.0.0.1:2008 using web.PostData() which is received by the machine and begins the process but this is irrelevant if cannot ‘listen’ for the responses as they are got given as a response to the web.PostData().
Is it a big job to implement some form of http:// port listener in forn of a device like the caller ID/scales in the same way you have added the twitter ‘interface’?
Im confident in saying that this xml<->http<->COM is how they have ‘separated’ the device so that you do not have direct contact with the PQD.
@emre did you ever have any after thoughts on this?
I know an intergrated card terminal solution would be popular for many users.
I haven’t done much more with this since we last spoke as been busy on the PMS however with that nearing an end should be able to get back on this.
It was left as the issue was receiving the replies from the machine as not returned as a response to the post and multiple responses are returned as processed.
1 Like
Hey @JTRTech
I have a Terminal on route soon with a big provider here in Oz. Apparently they are going international so I will keep this thread up to date.
Hi I would be interested however I’m still setting up my overall layout and having some issues.
Don’t worry I am in the same position! The Terminal is about a week away but the good news JTR is that I will have developers from the provider as my resource 
2 Likes
I am very interested. Keep us posted.
My provider has oz origins 
So are you saying that nothing was ever returned to var response? Correct spelling “response”…
Is there a way to test that script out of SambaPOS - @QMcKay? I assume PHP may be able to test a return as this is a “show stopper” right there.
Need to quickly determine is SambaPOS is at fault not making the response Array available back to the Script.
It will be because the responses are not direct responses to the post.
Ie the card machine get given the amount, then a stream of replies (replies is probably a better term as its not a response to the post but a sting of replies with the progress;
Which is why I beleive some form of monitoring device is required.
The com port is not directly accessable as this connects in to whatever comes in the installer which provides the xml port/interface.
Using the com port directly would not be suitable as this would then leave the processing up to the software which is not the way forward.
It will be this way so that they can keep the processing secure within their system and the machine can do its stuff and connect back to the provider via internet.
If we were connecting directly to com port I belive this would ‘get in the way’ of this.
The prinsaple of this method is to leave the PCI responsability with the provider, if you were happy with your own PCI responsability you could just use a plain USB MSR but that opens you up to a workld of hastle with PCI.
Ummm - do you need to read replies or just a Success or Fail code (Approved/Denied)? Were replies concatenated into a longer string or did they cause a block? Or replies were sent where?
They come back individually in sequence.
They come back in on the 2008 port (could only get as far as seeing them come in using putty connected to 127.0.0.1:2008
Ideally would like ability to read them all.
But reading on would most likely allow reading to all.
You could in theory just send the amount and cash of manually once receipt is printed however that kinda defeats the aim of having intergrated solution.
The two main points as I see are;
- amount corectly sent to machine
- aproved payment trigger correct card payment processed on till.
Other bits will be titovation however can see that having ability to catch aproved response will cover all responses.
Very good, I see where you are at.
I suppose setting up a Web Task Thingy on the URL 127.0.0.1.2008 would not work? Have not used any of that stuff as yet… Stabbing in the Dark so to speak LOL.
hmmm, not tried but sounds interesting. Not used myself yet either.
I don’t want to read the thread again to figure out (remember) what is going on. 
But IIRC, you are able to communicate in some form (Putty). If that is true, I cannot see why or what is not working, nor why we can’t get it to talk to SambaPOS. I think I remember mentioning we might need a different Device Type.
What is a Web Task Thingy? If you can see “stuff” through a browser, you might be on to something. Using HTML Viewer Widget and the JS Invoke or Inject, maybe something can be done?
Web Task Thingy = HTML Viewer Widget (sorry, been long weekend).
In short Q, the Eftpos Unit is sending back messages after the initial SambaPOS “Post” but these messages are at intervals of operation. JTR was trying to read the subsequent messages from the unit after the initial post.
SEE at 5 posts above - was using PUTTY at 127.0.0.1.2008
I agree that this is the most likely solution.
I might be wrong in saying but if we had some form of port listener like this would this not open up all sorts of posibilities? wouldnt it almost me like a basic Samba REST API?
I purchased a test unit for specifically for this reason from a company called PC EFTPOS located in Australia. In the documentation there is actually API config settings inside. Personally could not attempt as I had no clue how to implement. But I’ll upload and see maybe it would be helpful. I’ll keep you posted.
@Shivan the main thing you want to be sure on is how much of the PCI compliance falls on you.
I liked the system I posted about as the machine handels everything you just tell it how much and it responds with progress messages so in theory you would only have the usual basic network and phisical security responsabilities as you have no access to the card details etc.
If you post the API Documentation would happilly take a look and see if can offer any sigestions.
But remember if at any point you are able to see/handle card details be very careful to ensure PCi compliance.
PS. if you start getting to this level of intergration the PCI forms are REDICULIOUSLY COMPLICATED… they are bad enough for just basic systems.
I think the documentation stated that the integration only acts like a third party communicator which just sends the message back to POS machine stating whether it’s accepted or declined. The rest is handled via the eftpos machine
EDIT: I’ve got the documentation at the office. I’ll try and upload it here as soon as I go back to office in next few days. I hope it helps.
1 Like
The #1 issue here is that most of these API’s require a way to read information sent to SambaPOS so this means SambaPOS would need to know when information arrives…Currently we handle this with device events…