How to get IATS working

Question

Seems that IATS will not work using extension 1.5.3 - It logs the transaction in CiviCRM but never makes a connection with IATS. I'm not sure it is even connecting with the network.

Any clue folks?

Answer 1

If with EOL you mean End Of Life - you are mistaken! iATS 1.5.3 is already working for many transaction pathways in 4.7.x - but we will not release an official release until ALL 21 type of transactions, payment processor switches, chq debit img swapping, encrypted swipe is working as it currently is on 4.6.x LTS.

In general before upgrading any site you will really want to check to ensure that ALL extensions that you have enabled have releases for the CiviCRM version you're upgrading to - otherwise you're taking a risk.

A number of sites [from at least 3 CiviCRM partners that I know of and likely more] are already transacting with iATS on 4.7.x - they would have created a staging copy to check that their pathways are working.

So I'm not sure what issues you're running into. Are you using TLS 1.2? Is SOAP enabled? Any clues in the iats log tables? agent code/password correct - and configured properly?

See iATS Extension - README.md file: 9002 Error - if you get this when trying to make a contribution, then you're getting that error back from the iATS server due to an account misconfiguration. One source is due to some special characters in your passwd.

Also: Please have a look at the link http://home.iatspayments.com/Relaunch-SHA256 and check if your environment is compatible.

EDIT: to test if your server environment is indeed TLS 1.2 - go into your CiviCRM -> Payment Processor configuration and edit the URLs from www to www2 - so: e.g.: https://www2.iatspayments.com/NetGate/ProcessLinkv2.asmx?WSDL Run a transaction - if this works [if this does not produce a 9002 error] - then your server environment is -not- TLS 1.2

Answer 2

Ok!! I have found the culprit. Here is the response from my webhost:

This looks to be a limitation on your server when connecting to the remote server and we can test this directly using openssl.

Shown below is a failed connection to the remote server using TLSv1 (what your wget command specifies) to the remote server's HTTPS port (443):

CT-156611-bash-3.2# openssl s_client -tls1 -connect iatspayments.com:443
CONNECTED(00000003)
31985:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake failure:s3_pkt.c:1092:SSL alert number 40
31985:error:1409E0E5:SSL routines:SSL3_WRITE_BYTES:ssl handshake failure:s3_pkt.c:536:

The same connection fail results from my local workstation. However, when specifying a higher version of TLS such as TLSv1.2, I am able to connect from my workstation as shown below

$ openssl s_client -quiet -tls1_2 -connect iatspayments.com:443
depth=3 C = SE, O = AddTrust AB, OU = AddTrust External TTP Network, CN = AddTrust External CA Root
verify return:1
depth=2 C = US, ST = New Jersey, L = Jersey City, O = The USERTRUST Network, CN = USERTrust RSA Certification Authority
verify return:1
depth=1 C = US, ST = VA, L = Herndon, O = Network Solutions L.L.C., CN = Network Solutions OV Server CA 2
verify return:1
depth=0 C = US, postalCode = 76131, ST = TX, L = Fort Worth, street = Suite 1800, street = 100 Throckmorton Street, O = First American Payment Systems, OU = Information Technology Group, OU = Secure Link SSL Pro, CN = www.iatspayments.com
verify return:1

Your server is running CentOS 5 which does not support TLS versions higher than TLSv1 and many servers are beginning to reject those connections, such as payment gateways. If you require this support, then it will be necessary to re-image the server to CentOS 7