I’ve done a few cloud-based point-of-sale credit card integrations before. The way they all work was fairly similar. You plug the credit card machine into an ethernet port, and the credit card machine authenticates itself with the supplier’s cloud server. Then the point of sale application sends an API request to the cloud server. The cloud server then wakes up the credit card machine, which interacts with the customer, and once the payment is complete, the API request resolves and everyone is happy.
I made a quick and dirty application for running payments. The first step is pairing the terminal with the application. To do that, you press 0-7-1-3-9 on the terminal’s keypad, and the terminal displays an activation code on the screen. (The activation code makes me think the programmer may have been a fan of XKCD.) I was able to get the activation code and use it to connect to the terminal. But when I attempted to run a transaction, the JavaScript library threw an error: “Rpc Error: Network timed out! Check and ensure your browser is connected to the internet and has a stable connection.“
I was on my secondary network in my house, so I figured maybe that had something to do with it, so I went up and plugged the device into my DSL provider’s modem/router. I tried again. Same error. Then I tried again from a computer that was also directly connected to the router. Success! So, it seemed that the device needs to be on the same network as the computer that’s controlling it. (This stands in contrast to the other cloud-based point-of-sale-credit-card-machine integrations I’ve done. There the device is listening directly to the cloud server, so the request to activate the device and run a sale can come from anywhere as long as it’s authenticated with the right API credentials.)
I go back downstairs to my secondary network, and it stops working again. I start looking through the browser logs to see what kind of traffic is happening. I see in the network tab of the debugger that it says there is an OPTIONS HTTP request to https://193-168-1-11.rabbit-lan.goindex.com:4443/protojsonservice/JackRabbitService
So, let’s break that request down a bit. So, goindex.com is a domain created by the company Stripe acquired, Index.com. (Perhaps goindex.com is the domain they bought before they could afford for the more valuable 5-letter-in-the-dictionary-domain-name index.com.) Then there’s the sub-domain rabbit-lan, and then there’s the sub-sub-domain of 193-168-1-11. Oh, that’s the local IP address of the P400 on my network. I check to see what IP address 193-168-1-11.rabbit-lan.goindex.com resolves to… Nothing. I plug into the router provided by ISP, and the request changes to
192-168-2-8.rabbit-lan.goindex.com. That domain name resolves to 192.168.2.8. So, I fiddle around some settings on my second router and change it to the 192.168.3.X subnet, and now everything resolves fine.
So, the browser is actually talking directly to the device – not routed through some API, but rather the browser talks via the local network to the device in question.
So, if you find you have connectivity issues with your P400, where you seem to be able to access the internet, but you can’t get your browser to access the device, there are two things to check:
1) Is your computer on the network as the credit card terminal. If not, connectivity will likely fail.
2) Do you have some unusually named subnet that the network is living on? So, if xxx-xxx-xxx-xxx is the device’s local IP address and if xxx-xxx-xxx-xxx.rabbit-lan.goindex.com does not have a DNS entry, then the P400 won’t be able to talk to the browser.