Authorize.net - recurring

[Eileen]

Hi there,

I had been under the belief that Authorize.net did recurring transactions as the code is there in the processor file but I just noticed that is_recur is set to NULL in the civicrm_payment_processor_type table to indicate it is not implemented. Can anyone confirm whether it does / doesn't work for recurring?

[Donald Lobo]

authorize.net had a funky protocol (email based) for recurring and someone (dave lange?) got it working in 1.7

however no one supported it after that and for 2.x, and hence we turned off the "recur" flag. I think they also have a new better protocol to deal with recurring and that should be looked into in case someone is interested in doing/sponsoring this work

lobo

[CiviTeacher.com]

I would be interested in re-activating recurring payments in Civi to support Authorize.net.

If I am qualified to do the work myself I am certainly willing to attempt it.  If I am not capable of doing the work myself I am willing to sponsor it.  Could someone please give me a primer on how to access this code area and where to look for the Civi "recur" code you are speaking of?

Thanks!

[Eileen]

I think (off the top of my head) that if you start in civicrm\CRM\CORE\Payment\AuthorizeNet.php you should find it

[Donald Lobo]

note that the recurring code is not as well generalized / tested as the one off code since we only have one example to work off (paypal). also authorize used to notify recurring stuff via email which i think has changed in recent releases

lobo

[jsimonis]

Yea, getting this up and running is definitely something that is needed.

What needs to be done to get this running? I'm not a developer in the sense of being able to write code for this kind of stuff, so it's not something I can code myself. But it is obviously something that is needed. Without the ability to do recurring payments, you lose a lot of campaigns and non-profits who really need that ability. And using Paypal is a hassle because of all the verification hoops they make you go through.

For instance, we had a person who did not previously have a Paypal account who tried to make a recurring payment. It made him create an account. Then it wanted him to wait until he got his credit card statement, look at it, find a code that was linked to that transaction, come back, and put that code into Paypal. Until then, the payment wasn't completed. That is a lot to expect a donor to go through.

Heck, if we had a manual way to grab the credit card numbers, we could at least set up a contribution page that is just for those and then enter the information over at Authorize.net ourselves.

But we definitely have to get a solution up and running besides Paypal.

[Donald Lobo]

What needs to be done to get this running?

1. Organize a group of folks who want the same feature and are willing to contribute / sponsor it financially

2. Find a developer willing to do it (Eileeen from NZ and Web Access India are definitely qualified and interested)

3. If i had to guess this is a 40-60 hour project.

lobo

[jsimonis]

One quick question -

Is there a way we can turn on the ability to have it ask about recurring and such for Authorize.net, and then continue to do the manual turn on of the subscription over at Authorize.net?

Right now we're recreating those fields via custom fields, but it would be great if we could use the ones that are already there.

This will at least do us for a while until enough groups can get together to cover the cost of getting true support of recurring payments.

Thanks!

[Eileen]

Is what you are talking about covered by CiviPledge?

[Dave Greenberg]

One quick question -

Is there a way we can turn on the ability to have it ask about recurring and such for Authorize.net, and then continue to do the manual turn on of the subscription over at Authorize.net?

Right now we're recreating those fields via custom fields, but it would be great if we could use the ones that are already there.

This will at least do us for a while until enough groups can get together to cover the cost of getting true support of recurring payments.

Thanks!

My recollection is that setting is_recur = 1 in civicrm_payment_processor and civicrm_payment_processor_type will allow you to configure contribution pages to ask about recurring. CAVEAT*** - not sure what side-effects there might be so test carefully if you're trying this.

[CiviTeacher.com]

It seems we have at least a couple of people with common interest in getting Authorize.net ARB (automatic recurring billing) to work with CiviCRM.  I'm vaguely familiar with it as a developer, but may or may not be qualified enough to actually make it work.

I am going to do some technical research first, and thanks Dave Greenberg I have turned on CiviCRM is_recur flag for Authorize.net and it doesn't appear to break anything.  It succesfully processes the request and sends it to Authorize.net, whether Authorize.net recognizes it as a recurring charge remains to be see, but we don't have an "error" yet per se.

@Jsimonis  Would your organization be interested in co-sponsoring CiviCRM/ARB functionality with my organization?  Perhaps we could form a coalition of sponsors and reduce the cost of sponsorship.

According to Lobo's estimate it would be a $2000 project approximately.  Split two ways we could hire someone for $1000 each -- find more sponsors and the cost goes down...$667, $500, $400 etc.  Any other takers?

[petednz]

I don't think the client we are working with who will be using Authorize.net requires recurring - I will check in case we can squeeze anything out towards this though.

[jsimonis]

It's unlikely they'd be able to chip in towards the cost. A huge chunk of their budget comes from local and state governments, and they are seeing very large cuts in their funding because of it. So until that changes, they're not likely to be able to afford anything towards it, so I've been having them run it manually.

The quote I got for this was $2400. If we could find enough people who could chip in towards it, our company may be able to throw in a few hundred bucks.

[lcdweb]

I have interest and might be able to rustle up a few $$ from clients.

[CiviTeacher.com]

Hi folks,

Just an update.  I did a little research myself into the CRM/Core/Payment/AuthorizeNet.php file than handles the ARB transaction.

To start from the top, "ARB" means Automatic Recurring Billing and it's an additional feature of your Authorize.net account.

The basic idea is that CiviCRM configures the payment information and parses it into an XML format which is received on the Authorize.net side and processed.  An API exists so that our CiviCRM software could theoretically eventually be used to interact with the ARB and update, cancel or modify subscriptions in addition to starting subscriptions.  I personally, would settle merely for just starting the subscription through CiviCRM.  The rest we could handle manually.

It appears that someone has already started down this path to creating ARB compatibility in AuthorizeNet.php.  An XML template already exists and is being parsed.  However, there is a cURL error in the code of AuthorizeNet.php.  The request is possibly not even being sent to Authorize (much less returning a response) because it can't get past this cURL error.

The cURL error code is "3: malformed"  Now I will say that I have done some extensive testing and these are the results:

1) The XML that is being parsed and sent with cURL meets the ARB requirements, I have checked it with a fine-toothed comb.
2) Just in case I missed anything, I simply copied and pasted a hard-coded (un-CiviCRM-parsed) code directly from the ARB website that Authorize offered as a "working example".  This should have worked but...

Neither one works.  So evidence points to: the XML itself is not the problem, I theorize it's cURL or some curl_opt misconfiguration.

Any of you experts out there know who wrote this code, why the cURL doesn't work, what this error "3: malformed" means and what I might do to fix it?  Thanks!

Code: [Select]

       curl_setopt($submit, CURLOPT_RETURNTRANSFER, 1);
        curl_setopt($submit, CURLOPT_HTTPHEADER, Array("Content-Type: text/xml"));
        curl_setopt($submit, CURLOPT_HEADER, 1);
        curl_setopt($submit, CURLOPT_POSTFIELDS, $arbXML);
        curl_setopt($submit, CURLOPT_POST, 1);
        curl_setopt($submit, CURLOPT_SSL_VERIFYPEER, 0);
        $response = curl_exec($submit);

        if ( !$response ) {
            return self::error( curl_errno($submit), curl_error($submit)


PS. As far as budget is concerned I've recently been informed of a limit of a "a few hours" only.  So I'm hoping I can kick start at least the start subscription portion of this code in that time.  That's why I'm asking for any knowledge or help to be most efficient.