Description: When troubleshooting the inability to process transactions, we may need to verify whether the line of communication from the Interface terminal and/or server to the UTG is open. One method of doing so is a Browser Test, which is used to validate that the UTG is able to receive communication over a specified port to the UTG's configured IP address. It should be noted that a Browser Test does require bringing up the UTG Stand Alone. To perform the browser test, please perform the steps outlined in the article below.
Verify the IP Address and Port Number that the Interface is using for communication as well as the Task Description -- this is the name of your configured API Interface, often the interface name.
Then, stop the UTG Service if it is running and start the UTG Stand Alone before opening up a Web Browser on the machine (i.e. Internet Explorer, Chrome, or Firefox).
For all Non-REST interfaces keep reading.
For REST API click here.
In the Address Bar, type in HTTP://[ipaddress]:[portnumber] or HTTPS://[ipaddress]:[portnumber] if you are using an SSL connection (example: http://10.0.18.23:17476 or https://10.0.18.23:17476). The IP Address and Port Number are the values collected in Step 1. Note that we are not looking for any activity in the browser itself; a "Can't Display Webpage" or similar message is completely normal.
Leaving this window open, look in the UTG Stand Alone for an entry for [TaskDescription].1 (RPRO in above example) which will have a status of Ready or Available (what status displays is irrelevant) where [TaskDescription] is the value collected in Step 1. This will be located somewhere below the Global Status section, under the [TaskDescription] Waiting entry which will display at all times.
If the line exists, then communication to the UTG's IP Address over the Port Number listed if possible over the network. Troubleshooting should then be directed to the configuration in the UTG, Interface, and possibly Windows Firewall.
NOTE: If you see threads opening there (extra lines appearing) when you run a browser test, then it is communicating properly. Displaying false does not necessarily mean there is an issue.
If the line does not exist, (and we see just TaskDescription Waiting) then the attempt to communicate is never reaching the UTG. This indicates a networking restriction, likely on the Port in question, and will need to be addressed by your IT.
For REST Interfaces:
If the merchant is using REST API Interface the test is a little different.
Follow the same steps above but use https://[ip address]:[port]/api/rest/v1/ instead. This initiates a UTG callback and tests the same communication. You won’t necessarily see any activity in the api interface thread in UTG but instead you’ll get some sort of response in the browser from the UTG complaining about an invalid format request. One example being:
If you receive something like that, mark the test as successful. If you get nothing back in the browser, the browser test has failed.