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

The Tyee: Bricolage and Drupal Integration

The Tyee is a site I've been involved with since 2006 when I wrote the first, 4.7 version of a Drupal module to integrate Drupal content into a static site that was being generated from bricolage. About a year ago, I met with Dawn Buie and Phillip Smith and we mapped out a number of ways to improve the Drupal integration on the site, including upgrading the Drupal to version 5 from 4.7. Various parts of that grand plan have been slowly incorporated into the site, but as of next week, there'll be a big leap forward that coincides with a new design [implemented in Bricolage by David Wheeler who wrote and maintains Bricolage] as well as a new Drupal release of the Bricolage integration module.PlansApplication integration is tricky, and my first time round had quite a few issues. Here's a list of the improvements in the latest version:File space separation. Before, Drupal was installed in the apache document root, which is where bricolage was publishing it's content. This …

Confused by online payment processing? You're not alone.

In the old days during "polite" conversation, it was considered rude to talk about sex, politics, religion and money. You might think we're done with taboos, we're not (and I'll leave Steven Pinker to make the general argument about that, as he does so well in The Better Angels of Our Nature).

The taboo I'm wrestling with is about money - not how much you make, but about online payment processing, how it works, and what it costs. In this case, I think the taboo exists mainly because of the stakes at hand (i.e. lots of money) and the fact that most of those who are involved don't get much out of explaining how it really works - i.e. the more nuanced communications are overwhelmed by sales-driven messaging, and the nuanced stuff is either proprietary secrets or likely to get slapped down by the sales department.

In other words, if you want to really understand about online payment processing because you want to decide between one system and another, you'…