It's a time of year when machines and people get stressed, particularly in countries where tax laws and custom favour end-of-year donations. And if you've ever managed a CiviCRM installation, the last thing you probably want is to interrupt your end-of-year festivities with an issue of someone being unable to make a donation.
But of course, it's inevitable - there are no fool-proof systems. There's always someone trying to make a last minute donation with an old Internet Explorer 6 for example. And chances are, you got a call with something like 'your website is down' - no name, no time, no url, etc.
If you're using iATS Payments for your CiviCRM payment processing, then there's a useful diagnostic tool that I'd like to share here.
In case you're not already convinced - diagnosing the real issue is the most important first step. If you're able to trace the interaction of the donor with the server via web logs, then that's often extremely useful (e.g. it'll usually tell you which browser they were using, and if there is a code error, that will show up as well), but sorting through those logs and identifying the relevant records is often difficult or impossible, especially on a busy server and with inadequate information.
But here's what you can do:
1. Visit the iATS Payments Admin console. There's a link to it at or near the bottom of the CiviCRM contributions menu. It'll show you the last 50 transactions or attempted transactions via iATS Payments. You'll be able to quickly spot systemic problems vs. one-off problems and narrow down the scope of what you're looking for, and hopefully even be able to say with confidence that the issue is a one-off and that a lot of contributions are going through. If you have the last 4 digits of a card, or an auth result, you can even do a search for a specific transaction. If you can see a pattern of failures, you can also use the detailed time information to link those failures to the server logs for more information.
2. If this isn't enough and you have direct sql server access, the console is generated from a couple of tables, called 'civicrm_iats_request_log' and 'civicrm_iats_response_log', that are worth inspecting. Every transaction attempted through iATS Payments from CiviCRM should get exactly one row in each of those. So for example, if your server is having network connection issues to the iATS Payments server, then that'll show up because there are missing response rows.
What about 4.7?
It's embarrassing to admit, but we started working on a 4.7 compatible release for the iATS Payments extension almost a year ago. The short answer is - if you've already upgraded to 4.7 and need a 4.7 compatible version of the extension, then please make use of the latest release that you can get from github, here: https://github.com/iATSPayments/com.iatspayments.civicrm/releases/tag/1.5.4-rc-1
The longer answer is: it turns out that the CiviCRM Core 4.7 release was very ambitious about cleaning up some old contribution/payment related code, and though that is a good thing in principle, it's been under-resourced in testing and development (not through lack of trying, but mostly an underestimate of just how big a job it is/was). My best way of saying this is that CiviCRM Core has an extremely sophisticated collection of payment-related pieces (auto-renew memberships, recurring contributions, line items, financial accounting), and it's been a lot more work than we realised to get a new and improved code base that still does all the things that 4.6 did.
So although in the iATS Payments extension, the 4.7-compatibility issues are resolved, there are still lingering core issues that make us hesitate to put out a full 4.7 iATS Payments release. Again - if the iATS extension has been holding you up on the upgrade, by all means go ahead and use our latest rc release above, but if you haven't yet upgraded, then we recommend you wait at least until the new year and the next CiviCRM Core 4.7 release.
Wishing everyone happy holidays.
- Alan
