CiviCRM Community Forums (archive)

I was notified recently that that recurring payments were not being handled by the IATS contributed processor. It turns out there were two problems:

1. It wasn't handling the 'indefinite # of intervals' option that had been introduced in the past year or so. I noticed that there was another processor that might not be handling it either - in IATS case, there was a test of # of intervals > 1, so that it could handle a single recurring interval the same was as a single payment. Conclusion: the new code now converts "indefinitely" to 10 years. I think it would have been a good idea for those of us maintaining payment processors to have a way to wave big red flags when this change was introduced ...

2. I hadn't understood how CiviCRM handles the additional recurring payments after the first one - CiviCRM requires some kind of callback from the payment processor each time a payment goes through, to enable CiviCRM to add the payment. I don't think IATS does this, so even if the additional recurring payments are now going through, they won't get recorded in CiviCRM (i.e. it'll have to be manually imported).

There were a couple of other bugs or potential bugs in the code that have been fixed as well. You can use the attached diff to patch both 3.0 and 3.1 (likely 3.2 as well, though I haven't tested it).

Please reply here &/or notify me directly of any issues.

Big thanks to Matthew Clarke for pretty much all of the hard work here.

Can you provide a fuller error report?

1. Drupal/Joomla?

2. "nothing is returned" - are you talking about what's on your screen, or in the admin, or on the IATS interface? etc.

1. The first thing I notice is that I believe the IATS processor db entries are in 3.3, so an upgrade might scramble that entry. See the message at the top of this child forum in case that's clearer. In any case, do look at the information about the processor to make sure it's still there and okay.

2. A blank screen with no logging - sounds like it's maybe hung up trying to contact IATS in the back end? Try putting in some break points in the IATS processor code (look for a file called IATS.php).

@Micheas - When I reached out to IATS (having a similar problem) they informed me that I was using an old version (2005) of the IATS.php file and offered up the most revised version. 

Might be worth a shot.

hmmm. Since we updated to 3.3.1 we've been getting a 500 error on all our 'live' donation pages - and I'm trying to figure out why. 

I'd updated the payment processor info from IATS.ticketmaster.com to Iatspayments.com, so that'd not it. 

We're running Joomla! 1.5.21.

Patch for IATS

Index: CRM/Core/Payment/IATS.php
===================================================================
--- CRM/Core/Payment/IATS.php   (revision 31681)
+++ CRM/Core/Payment/IATS.php   (working copy)
@@ -63,7 +63,13 @@
             return self::error('Invalid configuration:'.$currencyID.', you must use one of '.self::CURRENCIES.' with IATS');
         }
     }
-
+    static function &singleton( $mode, &$paymentProcessor ) {
+        $processorName = $paymentProcessor['name'];
+        if (self::$_singleton[$processorName] === null ) {
+            self::$_singleton[$processorName] = new CRM_Core_Payment_IATS( $mode, $paymentProcessor );
+        }
+        return self::$_singleton[$processorName];
+    }
     function doDirectPayment( &$params ) {
         // $result = '';
         //       foreach($params as $key => $value) {


Patch for Barclays

Index: civicrm/CRM/Core/Payment/Barclay.php
===================================================================
--- civicrm/CRM/Core/Payment/Barclay.php   (revision 157)
+++ civicrm/CRM/Core/Payment/Barclay.php   (working copy)
@@ -56,7 +56,14 @@
         $this->_paymentProcessor = $paymentProcessor;
         $this->_processorName    = ts('Barclay');
     }
-
+   
+    static function &singleton( $mode, &$paymentProcessor ) {
+        $processorName = $paymentProcessor['name'];
+        if (self::$_singleton[$processorName] === null ) {
+            self::$_singleton[$processorName] = new CRM_Core_Payment_Barclay( $mode, $paymentProcessor );
+        }
+        return self::$_singleton[$processorName];
+    }
     /**********************************************************
      * This function is set up and put here to make the mapping of fields
      * from the params object  as visually clear as possible for easy editing


Patch for ChasePaymentTech

Index: civicrm/CRM/Core/Payment/ChasePaymentTech.php
===================================================================
--- civicrm/CRM/Core/Payment/ChasePaymentTech.php   (revision 157)
+++ civicrm/CRM/Core/Payment/ChasePaymentTech.php   (working copy)
@@ -57,8 +57,15 @@
        $this->_mode = $mode;                         // live or test
        $this->_paymentProcessor = $paymentProcessor;
    }
+   
+    static function &singleton( $mode, &$paymentProcessor ) {
+        $processorName = $paymentProcessor['name'];
+        if (self::$_singleton[$processorName] === null ) {
+            self::$_singleton[$processorName] = new CRM_Core_Payment_ChasePaymentTech( $mode, $paymentProcessor );
+        }
+        return self::$_singleton[$processorName];
+    }
 
-
    /**********************************************************
     * This function sends request and receives response from
     * the processor

Ah - it's missing this too

    /**
     * We only need one instance of this object. So we use the singleton
     * pattern and cache the instance in this variable
     *
     * @var object
     * @static
     */
    static private $_singleton = null;

Ah but there's still time .. we're about to push the deadlines back slightly :-)