CiviCRM Community Forums (archive)

I agree that it was strange that the developer made a drupal module instead of a CiviCRM payment plugin, but it is my understanding that there was an issue with CiviCRM integration with Authorize.net's silent post functionality that may have lead to this approach.  I hope that the code can be integrated into CiviCRM without the need for a separate module.  I look forward to your feedback. 

Any thoughts or suggestions that anybody feels should be passed on to the developer, please let me know and I would be glad to pass them on.

i took a brief look at the code and i suspect before it gets into core, we'll need to make at least a few changes:

1. reduce the number of additional tables to a smaller number (currently 4 tables are created). ideally we should figure out which tables can some of the columns be merged into

2. the silentPost i suspect is similar to paypal's callback url (IPN) and should preferably follow the same model

lobo

Hi, I have been following this thread for a while.  I just downloaded the code.  I am surprise it is a drupal module too.  A guy on my team is bright and can develop good code.  We are interested in helping/contributing to the effort.  Could someone summarize what it would take to get this code right so it could be committed?  ie, highlevel steps that could be passed of to a developer so he could run with it.

if your developer needs more info than the above, please contact us on IRC

i also think the module needs to be split into 2 parts:

1. support recurring authorize.com  "payments". this hopefully can follow a similar model to paypal standard / paypal pro recurring

2. support recurring memberships linked to the above. This will be extending memberships to handle recurring payments and change status based on that

lobo

I just had a discussion with Matt about this.  I also looked at the code closer.  Looks very tuned towards Memberships, which at the moment isn't something we are all the interested in.  In an interest to move this forward here is what we propose.

We are going to take a look at solving item 1.  We are going to attempt to model the paypal standard/pro implementation.  Two areas we are unclear of

1. What was the issues the silientPost?  Doesn't paypal do that?
2. Is the payment processor expected to provide emailing and links to updating/cancel ARB?  Or is civicrm expected to implment that? (we are asking in IRC now, but want to get this into the forum for posterity).

Once we get this nailed down and a working patch, perhaps someone can pickup the ball on the membership portion.

Yes, Paypal handles the silent post. The file called is extern/ipn.php but I think this file is also used: civicrm/bin/ContributionProcessor.php

pxIPN is for Payment Express & GoogleNotify is the google silent post code. I started looking at the civicrm/bin/ContributionProcessor.php
 code for Payflow Pro but Payflow Pro is a little different in that you run a CRON to check the outcomes rather than use silent posts.

The main difficulty with Silent posts is that the information returned with them varies from processor to processor and sometimes a bit of thought needs to go into what to send out/ what to interpret from what is returned back.

I had imagined that the processing of recurring payments would work by reenabling the code in the Authorize.net processor (as Stoob did) to send the payments out (I think this developer used a hook) and then using something similiar to ipn.php file to cope with the returns. I'd always been a bit unsure estimating how long this would take, however, as unexpected things always come up when dealing with Payment processors - leaving about 10-15 hours difference between how long I hoped it would take and how long I feared it could take.

The developer has also done a load of work on other functionality which is described in these posts as 'item 2' and would be amazingly useful to some people I expect.

Here is our plan.  We are going to try and handle the first part describe above.

* We are going to model the PayPal method.
* It will be pure CiviCRM code
* It will send out notification during a silentPost with a link to cancel the subscription
* Hopefully plug into some admin functionality that let's admin's cancel for them.
* SilentPost records the transaction
* Further send out a notification prior to the customer so then can cancel ahead of time according to how the contribution page is setup.

We are hoping you are interested in the membership integration.  We are in #civicrm as pearcec and xfortymatt.  If you have concerns with our approach let us know.

From what we found the cancellation links are proprietary to paypal.  So here are our restated goals.

Phase I

1. Modified the database so Authorize.NET is set to is_recur, plus it should set contributeMode == 'direct' (how ever that occurs) -- this changes the language on the Thankyou page telling you to contact an email address for cancellations (for now a person can just log into the authorize.net merchant account to cancel)
2. Test the existing Authorize.NET recurring POST code for setting ARB -- My developer tells me there is code out there.
3. Implement the silentPost back for recording the transaction.  -- Going to try and crib off the paypal implementation.

Phase II (Bonus round self service cancellation)

1. Set contributeMode == 'notify'
2. Sent out a link with each civicrm receipt that links to the civicrm for canceling the recurring.
3. The link should give the user the option of canceling, Yes or No, then it should attempt to cancel the ARB.  This will probably require we storing stuff into the database.

I don't know if it'll help but here's two blog posts by John Conde about this topic:
http://www.johnconde.net/blog/handling-authorize-net-silent-post-with-php/ and http://www.johnconde.net/blog/all-about-authorize-nets-silent-post/

From what we found the cancellation links are proprietary to paypal.  So here are our restated goals.

Phase I

1. Modified the database so Authorize.NET is set to is_recur, plus it should set contributeMode == 'direct' (how ever that occurs) -- this changes the language on the Thankyou page telling you to contact an email address for cancellations (for now a person can just log into the authorize.net merchant account to cancel)
2. Test the existing Authorize.NET recurring POST code for setting ARB -- My developer tells me there is code out there.
3. Implement the silentPost back for recording the transaction.  -- Going to try and crib off the paypal implementation.

Pearcec,

Thanks for taking this on. Curious what your time table is. Have a client anxious for this feature and was curious if you had started and needed any help either coding or testing. I know there are a number out there that are anxious for this feature. Let us know when you can.

Thanks,

Hi All,

Just wanted to you let you know that I am currently working on having automatically renewing Memberships in CiviCRM using Payment processors that use the doDirectPayment() API (so the user does not get redirected to another website). 

The following thread outlines my progress and methodology a bit: http://forum.civicrm.org/index.php/topic,4977.msg53310.html#msg53310

Most of these changes were in the workflow for processing Membership Payments, the Membership config pages to configure the auto-recurring info, and on the Contribution pages to auto-fill the recurring billing info behind-the-scenes.  All of the changes use the basic Payment Processing hook doDirectPayment().

Currently I have modified the PayPal Pro Payment Processor doDirectPayment() to use their REST API to create the recurring billing subscription.  I am right now finishing up modifications to the PayPalIPN to deal with the differences in the PayPal Pro IPN (Instant Payment Notification) vs. the PayPal Standard IPN for recurring billing payments. 

So basically, to take advantage of all these changes for Authorize.Net ARB, you would only have to add the ability to create the recurring billing subscription in the doDirectPayment() method and create the appropriate ARB IPN page to handle the ARB Silent Posts (which it sounds like is almost done by xfortymatt & Pearcec.

A contribution of funds toward the development of the auto-recurring payment functionality would speed up my development process and allow me to include additional features like Cancelling Subscriptions from within CiviCRM and documenting Payment Processing failures within CiviCRM (right now, failed payments are not well documented by CiviCRM - there are no Reason Codes documented in the Contribution records).  Please contact me for pricing info.