3

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?

2

2 Answers 2

3

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

15
  • It stopped working for me on 4.7.9. Yes, using TLS 1.2. With SOAP being enabled, do you mean in PHP or somewhere else? Where are the IATS log tables. Yes, agent code/password is correct. I monitor the transactions in IATS portal to check it is working when I have problems. In the CiviCRM dashboard under Contributions menu there is IATS Payment Admin which shows the log. No connection to the outside appears.
    – BruceW
    Aug 6, 2016 at 23:47
  • Ok, seems that when webhost did recent upgrade didn't enable SOAP. Thanks for that Karin. Good instincts. Activated the CRONs. Seems that SSL will not accept all certs, so failing.
    – BruceW
    Aug 8, 2016 at 2:00
  • Not sure what you mean by SSL will not accept all certs? You've confirmed you're using TLS 1.2? Aug 8, 2016 at 2:33
  • Yes, all my servers are updated to TLS 1.2. I am getting 9002 error even if I set both Live and Test to TEST88. My agent code ends in 80.
    – BruceW
    Aug 8, 2016 at 5:35
  • SSL, that was an issue with Return-Path. It is not accepting "all" certs.
    – BruceW
    Aug 8, 2016 at 5:45
-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

1
  • 1
    So in other words - you were not using TLS 1.2 after all... That's what I asked you in my answer. Your webhost just confirmed it. Aug 25, 2016 at 14:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.