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

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…

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'…

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' …