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: http://forum.civicrm.org/index.php/topic,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.

Code


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.

Install

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 "https://www.iats.ticketmaster.com" for both of the live URLs
    • put in "http://www.iats.ticketmaster.com" 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

Comments

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…
Hi,
We have a Payment Processor running in C#.net 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 www.paypal.com...
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?

Thanks,
Gracia.
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…
Hi,

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

Varnish saves the day, in unexpectedly awesome ways.

Four and half years ago, I wrote a blog post about Varnish, a 'front-end proxy' for webservers. My best description of it then was as a protective bubble, analogous to how it's namesake is used to protect furniture. I've been using it happily ever since.

But last week, I got to really put Varnish through a test when the picture here, posted by Fair Vote Canada (one of my clients), went viral on Facebook. And Varnish saved the server and the client in ways I didn't even expect.

1. Throughput

Varnish prides itself on efficiently delivering http requests. As the picture went viral, the number of requests was up to about 1000 per minute, which Varnish had no trouble delivering - the load was still below 1, and I saw only a small increase in memory and disk usage. Of course, delivering a single file is exactly what Varnish does best.

2. Emergency!

Unfortunately, Varnish was not able to solve a more fundamental limitation, which was the 100Mb/s network connection. Becaus…

What to do in the age of Trump?

Well, that's the question of the day. If you're part of an organization that does advocacy work, rather than waiting to see what happens first, might as well get yourself ready, even if the details are sketchy still. Here's one opportunity that's ready for you now, message courtesy of Steve Anderson of OpenMedia.

OpenMedia, David Suzuki Foundation, SumOfUs and a range of other organizations are supporting a new shared set of civic engagement tools.

Vancity Community Foundation is providing some support to subsidize some of the cost of the tools to select values-aligned organizations that sign up before February 28th.

Interested? You can learn more or book a demo from here: http://tools.newmode.net/

Here's some live examples of the tools you can take a look at:

1. Click to Call: http://www.davidsuzuki.org/blogs/healthy-oceans-blog/2016/11/to-help-protect-canadas-oceans-weve-made-it-easy-to-call-your-mp/#newmode-embed-4-266

Check out this video of David Suzuki's d…

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…