Authorize.net - recurring

[Eileen]

My first guess is that $arbXML is malformed because it contains characters that have not been url encoded.

Have you tried dumping the contents of $arbXML to see if it is valid XML & contains the expected fields.

[lcdweb]

Perhaps someone who wants to take the lead with the "contracting" piece of this can create a ChipIn account so others can contribute/pledge $$: http://www.chipin.com/

Early in this post there were some numbers going around as to the possible cost. Just curious if those were generic estimates, or if someone's been identified to do the work.

And on that note -- if no one's been identified -- Eileen, are you available/interested to take this on?

Re: functionality --
The important piece to me is the ability to have callbacks from the payment processor to CiviCRM for the future contributions. PayPal Standard currently does this (when a future payment is made, it is logged in Civi); PayJunction does not -- only the initial contribution is actually logged (details about the future payments schedule are recorded, such as the number of recurring contributions committed, but the actual contribution record itself is not recorded at the time the payment is processed).

[CiviTeacher.com]

Eileen, I do appreciate your response but I already mentioned the XML checks out OK.

Everyone, I just took matters into my own hands and tried to get this working myself.  I think I have succeeded, at least in my environment.

I have spend another couple of hours editing AuthorizeNet.php and TA-DA I got the recurring working to the point where CiviCRM will start a recurring subscription with Authorize.net.  There were a few problems with the code as it existed prior, mainly around lack of CVV2 (back of the card code) data and the logic which detected recurring transactions in the first place was faulty.

To get this to work on your system take the following steps:

1) edit your civicrm_payment_processor table in the database.  (for God's sake backup your DB first hehe )
   a) set column is_recur = 1 on your Authorize.net processor(s)
   b) add     https://api.authorize.net/xml/v1/request.api to the recurl_url column

2) Use the attached code to replace CRM/Core/Payment/AuthorizeNet.php

3) If you use CVV2 (back of the card 3 digit code) then you must make some edits:
   a) add at around line 217 of AuthorizeNet.php

Code: [Select]

$template->assign( 'cardCode', $this->_getParam('cvv2') );   b) add below Expiration Date in <your-custom-templates-dir>CRM/Contribute/Form/Contribution/AuthorizeNetARB.tpl

Code: [Select]

<cardCode>{$cardCode}</cardCode>

I'm sure there's some kind of auto-switch that could be written to detect if you use CVV2 on your system and alter this automatically, but I really don't have time to mess with that right now.

I have not built in functionality for a user to modify or cancel their subscription.   My client is ok handling cancellations and modifications manually.  I know that a recurring contribution does show up as such in the "Find Contributions" report page, but whether or not that contribution continues to show up each week/month as a new donation remains to be seen...I'll let you know in a month.  :-)

If you guys think this is useful and want to commit it to the project I would welcome help doing so.  I do not know how to create a patch file and can't find any documentation on how to do so.   And I would like someone else to test this on your system before I commit it anyhow.

I would be willing to explore the other ARB API functionality (cancellation or editing subscriptions via CiviCRM) in the near future if some person/coalition would be willing to compensate me financially (my clients or yours) to do so, but my personal requirements are satisfied at the moment and I hope this helps you guys too.

Let me know, thanks.

[Eileen]

Well done! I was thinking after your last post (and a very quick flick at the code) that the processor might be closer to working than I had previously assumed. I think Lobo estimated the number of hours early on in the piece which is what all the previous figures were based on.

Anyway, sorry I misread but well-done!

[Donald Lobo]

so, does authorize.net do a callback for the remaining part of the recurring contributions? i.e. the first contribution is recorded out of a series of 10. does it do a callback for the remaining 9 when they are fulfilled? Dont see the code here or or u potentially do it

lobo

[CiviTeacher.com]

@Eileen Yeah a lot of the work was already done.  Whomever made the code had it ALMOST working.  Would still like to know who that person is.  Anyhow I think that some testing is needed some of the other folks with this requirement please take the steps outlined above and see if it works for you.

@Lobo Authorize.net can send a transaction response to CiviCRM via email or "SilentPost" here is a snippet from page 19 of this document http://www.authorize.net/support/ARB_guide.pdf

If you would like to receive a transaction response for each payment in a subscription, you must enable the Silent Post feature in the Merchant Interface. When this feature is enabled, the payment gateway will post a transaction response in name/value pair format to the URL specified in the Silent Post field of the Merchant Interface.

This functionality doesn't exist in the CiviCRM code to handle this Silent Post yet.  I have not created it but it's not a client requirement, their budget is stretched already.  They are happy just to be able to start transactions.

[Eileen]

Here's your answer

http://forum.civicrm.org/index.php/topic,5578.msg26888.html#msg26888

(I read your post properly this time 

So, will your clients check manually to make sure the transactions have all succeeded? I guess automating that is the tricky part.

[Donald Lobo]

marshall and dave lange also wrote a script for 1.7 to process emails (bin/ProcessAuthorizeReport.php) and automate the recurring part. Authorize.net can send u an email OR do the silent post thing

with paypal standard we opted to do something similar to "silent post" and automate the process. So a large part of the code exists and needs to be tied in. Note that our estimates included automating the silent post part

lobo

[CiviTeacher.com]

As it stands this minute CiviCRM will notify Authorize.net to start a recurring billing and that initial billing will be recording in CiviCRM as a contribution of "recurring" type with X number of installments in $X amount.

From then on I don't expect Authorize.net to send any more information to CiviCRM.  The client will be responsible for checking that further installments are processed and canceling and/or changing the subscription within Authorize.net  I realize this is not ideal, but it is the current functionality that CiviCRM has with PayJunction as I understand.

My client is satisfied with the situation for now, although budget for improvements later are possible.

[CiviTeacher.com]

ok Lobo it's good to know that Email code exists.  It would be worthwhile to see if that code could be recycled or if a Silent Post is the best option.  I'll either let someone take this ball and run with it or I'll check back with this issue in a few weeks (budget permitting) and continue it myself.

I still would appreciate some help testing and determining if my code as it stands currently should be added into the codebase or not.

[Eileen]

I think there were a few people out there who were keen so no doubt they'll be testing shortly.

I'd be surprised if silent posts weren't the easier option - this is the option used by Paypal Std and by DPS Payment Express so it's quite well established. (although DPS doesn't use it for recurring as they only do 'triggered' recurring payments

[Donald Lobo]

we'd be reluctant to add it to the codebase without the silent post option working that completes the recurring loop 

lobo

[CiviTeacher.com]

Fair enough.   If I get Silent Posts working we'll revisit it again.  Until then this will be a stopgap measure for people who want recurring for Authorize.net

[preacherboy86]

Not sure if this message will get through or not - but is there an update to this? Has the "silent post" issue been resolved? Does this need user funding (am willing to help out with this.) Bottom line is we need a recurring payment solution that isn't PayPal Payments Standard. Thanks!

[Eileen]

Hi, Someone else was recently trying to use Moneris for recurring payments recently. I'm not sure if they got it going or not. I believe the code is all there but the documentation was a bit out of date