Skip to main content

IATS and CiviCRM

Update, Nov 2009: I've just discovered and fixed a bug I introduced in the 2.2 branch for the IATS plugin. The bug was introduced when i updated the API files from IATS and failed to notice that the legacy method for C$ one-time donations was no longer supported.
If you're using a version greater than or equal to 2.2.7, and are using IATS for C$, non-recurring donations, then you're affected.
To fix it edit the file : CRM/Core/Payment/IATS.php, and remove the line that looks like this:

$canDollar = ($params['currencyID'] == 'CAD');  //define currency type
The full fix removes a conditional branch based on that value a little further on, but by removing this line, it'll never actually use that branch. Drop me a line if you have any questions.

Update, May 2009: This post is still getting quite a bit of traffic, which is great. Here are a few important things to note:
  1. The IATS plugin code is in CiviCRM, you don't need to add any code.
  2. You do still need to add it to the database [i think this will change soon], following the instructions below under "Install"
  3. It should work for Joomla as well, as per:,8032.msg35035.html#msg35035 but the urls in the install section are different.

I'm happy to report that I've taken up an abandoned project from a year ago and just finished it. Thanks to Heritage Toronto who hired Anarres Worker Co-op and Paul Newby and myself to give them a new site

My project consists of writing a 'payment processor plug-in' that allows CiviCRM websites run by non-profits to accept donation/payment/memberships using IATS.

The reason this is interesting is because:

  1. CiviCRM is a great 'CRM' (client relationship management) piece of software designed for non-profits.
  2. IATS is the best alternative for non-profits in Canada who need a transaction processor (i.e. anyone who wants to accept money on-line).
  3. There wasn't any way to use them together.

So .. the rest of this post is aimed at any of you out there who want to try it. I'm going to provide a link to my code + instructions. Note that this is ONLY for CiviCRM versions since 1.7, since the payment plug-in structure changed at that point, and I've only tested it on 1.8 and 1.9.


Here's a zipped tarball, with: CRM/Core/Payment/IATS.php CRM/Contribute/Payment/IATS.php packages/Services/IATS/iatslink.php packages/Services/IATS/creditcard.php packages/Services/IATS/iats_reoccur.php just put it in your civicrm installation root and do a tar -xvzf iats.tgz
This is now updated code as of Feb 26 to fix the previous issue with extra spaces. It also has support for US$ and recurring donations.


In order to test the code, you need to:
  1. Add a new payment processor type from this path (for Drupal): /civicrm/admin/paymentProcessorType?reset=1 or for Joomla: /administrator/index2.php?option=com_civicrm&task=civicrm/admin/paymentProcessorType&action=add&reset=1 As far as I know, this isn't documented.
    • Use "IATS" for Title and Name
    • Billing Mode is 1
    • "Payment_IATS" is the PHP class name
    • use "Agent Code" for the Signature Label
    • put in "" for both of the live URLs
    • put in "" for both of the test URLs
    • it does support recurring donations (but see below)
  2. Add a new payment processor to your site: For Drupal: /civicrm/admin/paymentProcessor?reset=1 [Check your documentation for Joomla, it'll be different]. This is better documented but I'll make it easier for you:
    • Put IATS for your Name
    • For your live payments, you can put in your Agent Code and Password, or use the test one of "TEST88" (user and pass)
    • For your tests, use the test one ... you keep the urls you put in as defaults earlier.
  3. And now add the paypage, I'll let you figure that one out.

And that's all. Please don't try this on a production server, I'm not providing any guarantees. I have tested it on CiviCRM 1.8 and 1.9, it should work on 2.

Update Feb 26 I've added in some code for US$ and recurring donations. The only problem with recurring donations is that IATS doesn't accept all the options that CiviCRM assumes it will, so you have to create a custom template to restrict this. Please RTFM to see how this is done - the file you want is: CRM/Contribute/Form/Contribution/Main.tpl


Joe Murray said…
Many thanks for this, Alan. What needs to be done before this is ready for production. Has your client gone into production with it yet?
Alan Dixon said…
The client for whom this was originally written is planning to launch their site in the next few weeks. I've got a few other clients who are potentially using it soon, but no one in a production environment yet.

So - it's ready for prime-time, but should be watched carefully for a while.
Zoran said…
Hi Alan, is this code still in production use for any of your clients?

Have you (or someone else you know) done something similar for any of the open source shopping cart packages, like osCommerce, ZenCart, etc.

Thanks in advance...
Alan Dixon said…
Yes, it's in use for the original client as well as 2 additional clients i've used it with since.

Re: something similar - I've stayed away from all the shopping cart packages, but any well built package should be able to make an IATS plugin fairly easily, it's a very straightfoward interface.
gracia said…
We have a Payment Processor running in which performs Credit card transactions for few of our clients.
Now we have a new client who uses civicrm. So we want to transfer the user(donor) from the civicrm webpage to our payment processor asp page.

We couldn't figure out where exactly we should give our url. We tried to add a payment processor entry in the payment_processor_type and the files in CRM/Core/Payment and other files.

But we found that when ever we try to run a donation (in sandbox), it is redirected to
Could you please help us to move forward. Its been weeks since we are working on this.
Do you suggest us to follow the similar steps you have used?

franklin said…
Hi, I am creating a plugin for civiCRM. I have added a new payment processor type and payment processor as mentioned. My plugin file is in CRM/Core/Payment.But still for some reasons, on submitting the donation it is redirecting me to paypal which was set before. What mistake am I doing here?
Thank you so much. Any help is appreciated.
Alan Dixon said…
hey gracia & franklin:

These are support questions for CiviCRM, try the support forum instead.

gracia: sounds like you will need to write your own civicrm payment processor plugin for your payment processor.

franklin: you can enable multiple payment processors for your site, sounds like that's what you've done. Either remove the paypal one, or edit the pay page to change processors.
Anonymous said…

My payment processor plugin works great. But after the transaction I am manually updating the contribution status from pending to completed. Is there a way to automate this like how paypal does?
Alan Dixon said…
That's a surprising comment - my experience is the opposite, i.e. that Paypal (standard) requires you to update the status from pending to complete, but IATS doesn't. In any case - since this is a support question, it should go to the civicrm forum, not here.
Bob Gulian said…
The link to the tarball is broken.
Alan Dixon said…
Bob: true, this is a very old post now. All the required code is in the CiviCRM codebase.

Popular posts from this blog

Me and varnish win against a DDOS attack.

This past month one of my servers experienced her first DDOS - a distributed denial of service attack. A denial of service attack (or DOS) just means an attempt to shut down an internet-based service by overwhelming it with requests. A simple DOS attack is usually relatively easy to deal with using the standard linux firewall called iptables.  The way iptables works is by filtering the traffic based on the incoming request source (i.e., the IP of the attacking machine). The attacking machine's IP can be added into your custom ip tables 'blacklist' to block all traffic from it, and it's quite scalable so the only thing that can be overwhelmed is your actual internet connection, which is hard to do.

The reason a distributed DOS is harder is because the attack is distributed from multiple machines. I first noticed an increase in my traffic about a day after it had started - it wasn't slowing down my machine, but it did show up as a spike in traffic. I quickly saw that…

Upgrading to Drupal 8 with Varnish, Time to Upgrade your Mental Model as well

I've been using Varnish with my Drupal sites for quite a long while (as a replacement to the Drupal anonymous page cache). I've just started using Drupal 8 and naturally want to use Varnish for those sites as well. If you've been using Varnish with Drupal in the past, you've already wrapped your head around the complexities of front-end anonymous page caching, presumably, and you know that the varnish module was responsible for translating/passing the Drupal page cache-clear requests to Varnish - explicitly from the performance page, but also as a side effect of editing nodes, etc.

But if you've been paying attention to Drupal 8, you'll know that it's much smarter about cache clearing. Rather than relying on explicit calls to clear specific or all cached pages, it uses 'cache tags' which require another layer of abstraction in your brain to understand.

Specifically, the previous mechanism in Drupal 7 and earlier was by design 'conservative' …

CiviCRM's invoice_id field and why you should love the hash

I've been banging my head against a distracted cabal of developers who seem to think that a particular CiviCRM core design, which I'm invested in via my contributed code, is bad, and that it's okay to break it.

This post is my attempt to explain why it was a good idea in the first place.

The design in question is the use of a hash function to populate a field called 'invoice_id' in CiviCRM's contribution table. The complaint was that this string is illegible to humans, and not necessary. So a few years ago some code was added to core, that ignores the current value of invoice_id and will overwrite it, when a human-readable invoice is generated.

The complaint about human-readability of course is valid, and the label on the field is misleading, but the solution is terrible for several reasons I've already written about.

In this post, I'd like to explain why the use of the hash value in the invoice_id field is actually a brilliant idea and should be embrac…