IBY_0001 Communication error. The payment system, the processor, or iPayment electronic commerce servlet is not available/accessible.

IBY_0001 Communication error. The payment system, the processor, or iPayment electronic commerce servlet is not available/accessible. Please make sure you have the correct system set up and resubmit the request at a later time.

Problem:
In our Oracle applications instance R11i (11.5.8), we applied some patches as part of some maintenance activity. Subsequently we ran autoconfig and then, the users complained that their iPayment credit card authorizations were failing with the aforesaid error.

Troubleshooting and Fix:
I am aware that the error message is generic in nature and can happen due to a variety of reasons including misconfiguration of payment gateway related class files in jserv.properties / zone.properties / System setup using iPayment Administrator responsibility and so on. However, in our case, we did not have a reason to suspect those factors as the change that happened was we having applied some patches and DBA related maintenance activities.

The first thing to do in this kind of a situation is to enable FND Debug Logs. Specify a location for the log file and provide the module which needs to be traced, in our case IBY.
Second thing is enable AF logs by having debug related entries in jserv.properties:
wrapper.bin.parameters=-DAFLOG_ENABLED=TRUE
wrapper.bin.parameters=-DAFLOG_MODULE=iby%
wrapper.bin.parameters=-DAFLOG_LEVEL=STATEMENT
wrapper.bin.parameters=-DAFLOG_FILENAME=/tmp/fndLog10Mar.log

However, I believe it is a good option to enable debug logging in jserv by editing jserv.properties and editing log related parameters :
log=truelog.file=[full path to jserv.log]
log.timestamp = true
log.channel.debug=true
Dont forget to enable debug logging in httpd.conf. This should also be able to trap the error.

The above debug settings resulted in the following error stack (Partial Error Stack):
java.net.ConnectException: Connection refused
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:350)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:137)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:124)
at java.net.Socket.(Socket.java:268)
at java.net.Socket.(Socket.java:95)
at oracle.apps.iby.payment.PmtAdapter._oraMippSocket(PmtAdapter.java:982)
at oracle.apps.iby.payment.VendorAdapter.oraMipp(VendorAdapter.java:146)
at oracle.apps.iby.payment.VendorAdapter.oraDispatch(VendorAdapter.java:396)
at oracle.apps.iby.payment.VendorAdapter.oraDispatch(VendorAdapter.java:328)

This resulted in analyzing why the connection refused error was showing up.
It turns out that the parameter "Listen" in httpd.conf got updated due to new templates brought in by the patch.

Before patch it was :
Listen 8001
After patch it was:
Listen [Hostname.domain.com]:8001

This was the cause of this issue.

When you have the Listen 8001 directive, the apache listens on 127.0.0.1. However, when Listen [Hostname.domain.com]:8001 is configured, then it listens on the hostname. So if the iPayment uses a load balancer URL, it will not be able to connect because in the /etc/hosts file on the physical host, the entry will look like:
127.0.0.1 http://www.qcprod.acme.com/
So, when the loop back connection from the host tries to connect on 127.0.0.1, because apache is no longer listening on 127.0.0.1 and hence it sees connection refused error, which results in the original error message thrown by iPayment. The fix is to change the Listen parameter back to original value.
- Aravind Kamath Posral