Create Authorize.net ARB recurring fee handler

I have added some code in modules/uc_recurring.uc_authorizenet.inc which adds partial support for auth.net ARB.

There is one line you can uncomment to start testing what is there and it should setup the recurring payments as is. But there is currently not support for handling the renewals and recording them in ubercart.

I think you should disable/remove the edit menu, as changing the recurring fee in uc_recurring will not actually change the amount renewed by auth.net, so this option shouldn't be shown to users

+    'menu' => array(
+      'edit' => UC_RECURRING_MENU_DEFAULT,

How are you planning to handle the "silent posts" so the renewals can be tracked?

No 'edit' for recurring fees is about changing the recurring order (amount, intervals etc...), uc_recurring has nothing to do with credit cards, there are other ways to pay for things without credit cards so that is a payment gateway thing not a uc_recurring thing.

In your code you have implemented the user operation to update credit card info using the 'update' menu item.

My understanding of ARB is that you setup the recurring payment at auth.net and then they do everything and charge the same amount at the specified intervals. But when a payment is processed for a renewal they send a message back to your site, this should be passed to uc_recurring by calling "uc_recurring_renew" so that everything that should happen at a renewal will be done by uc_recurring.

At the moment renewals aren't going to be registered in uc_recurring - as far as I can tell. Since uc_recurring doesn't trigger them, ARB triggers them.

Although having said that... because there is already code in the core uc_authorizenet module for handling ARB, I'm not entirely sure what will happen on a renewal.

Whats in uc_authorizenet at the moment is related to the old uc_recurring-1.0, I don't think we can just break that - this is the main reason I haven't spent much time on this specific issue (not sure what is the best way to deal with the potential conflict)

This might be a hack, but we could snipe the authnet/silent-post menu to use our own code using hook_menu_alter(). It wouldn't "break" the existing code.

This is the type of thing I was thinking of also. Although the other thing I really want to avoid is having payment gateway specific stuff in uc_recurring and to include hooks like hook_menu_alter() you need the code to be part of the actual module, it wont work if its in the current *.inc file with all the other authorizenet specific stuff.

I have discussed this same problem for the Paypal WPS implementation: #569298: Create Paypal WPS recurring fee handler, in that case I have been thinking it is going to be easier/cleaner to have a separate module for paypal recurring. That could be an option here.

The other idea I can think of is having a number of wrappers functions for various hooks in uc_recurring which then loads the include files and attempts to call the hooks in those files - but I really hate that idea, mainly because I just don't want specific gateway code in uc_recurring, especially hosting gateways (e.g. Auth.net ARB and Paypal WPS) which I am just not as interested in as you are always going to be limited in the functionality that can be implemented with these. I want uc_recurring focus on full featured recurring subscription/billing systems and for that the focus needs to be on triggered gateways like Auth.net CIM which just store the credit card and we can trigger when and how much each payment is.

Actually maybe we could create a separate module to dealing with these two hosted recurring gateways (ARB and Paypal) to implement all these little hacks and extra hooks? - uc_recurring_hosted (this module could just go in the modules directory in uc_recurring)

As for the other hooks in uc_authorizenet that shouldn't be an issue as all the hooks I think have changed so the old ones shouldn't be called unless you have uc_recurring-1.0 installed.

Also is not exactly the case...

Is there an issue to remove the recurring code from uc_authorizenet, since it's being moved to uc_recurring?

Ideally I would prefer to see payment method/gateway modules look after their own code and it shouldn't be up to uc_recurring to maintain their interfaces and protocols. It was just realized that trying to get large patches (of new feature) into ubercart at this stage when they are trying to get the stable version 2.0 out is going to be difficult, especially when the uc_recurring api may still need some tweaking and changing.

So the idea is that the payment specific code for core ubercart modules should all reside in the modules directory in uc_recurring so if and when we needed to merge it back we just have to copy over the code in those *.inc files and hand back maintenance of the code to those gateways.

Anyone interested in getting Auth ARB support in uc_recurring-2.x please read/test and support this issue in ubercart:
#592420: Move UC Recurring Fees code out of Authorize.Net module

Without this patch being committed it is going to be very difficult to ever get ARB working in uc_recurring 2.x due to the conficts with existing ARB/recurring code in ubercart/uc_authorizenet modules.

Firstly if you can use Authorize.net CIM (instead of ARB), that is working and because it is more features already then ARB will ever be able to support.

If you still need ARB:
1) We need to convince the ubercart guys to commit the issue here: #592420: Move UC Recurring Fees code out of Authorize.Net module or people will need to patch ubercart with that patch in the meantime.
2) There is some code in the uc_recurring/modules/uc_recurring.uc_authorizenet.inc that was copied across from the core ubercart module.
3) The patch in #4 above is probably a little further along (although I haven't tested it myself).
4) We need to implement the following hook to handle the silent posts from authorize.net which need to call the uc_recurring_renew function:

hook_uc_auth_arb_payment();

5) All this needs to be tested.

@duellj, correct and that is what I was talking about in #11 - we could try and get it into the uc_authorize module or create another module just for these hosting gateways (like uc_authorizenet and uc_paypal) that need these extra hooks. I personally think it should be in the gateway as well, although the ubercart guys are not really accepting any new features so the easier solution is doing it in uc_recurring project.

@deggertsen, what it won't be doing is registering or showing the renewals, thats what the silent post that we need to sort is about.

+++ uc_recurring.uc_authorizenet.inc	8 Oct 2009 04:26:47 -0000
@@ -40,7 +40,17 @@ function uc_recurring_uc_authorizenet_re
+    'process callback' => 'uc_recurring_authorizenet_arb_process',
+    'cancel callback' => 'uc_recurring_authorizenet_arb_cancel',
+    'menu' => array(
+      'edit' => UC_RECURRING_MENU_DEFAULT,
+      'update' => array(
+        'title' => 'Update Account Details',
+        'page arguments' => array('uc_recurring_authorizenet_arb_update_form'),
+        'file' => 'modules/uc_recurring.uc_authorizenet.inc',
+      ),
+      'cancel' => UC_RECURRING_MENU_DEFAULT,
+    ),
     'own handler' => TRUE,
   );

I think the recurring info stuff for ARB probably should just go into the new module. Probably most of the ARB stuff may as well be in the hosted module and there also should be a module_exists('uc_authorizenet') around this as you wont be able to use it unless authorize module is enabled.

The 'edit' menu item needs to be deleted or use UC_RECURRING_MENU_DISABLE as changing the recurring fee in ubercart is not possible with ARB as it wont update what ARB is doing - if ARB has this feature we need to add a create its own form.

+++ uc_recurring.uc_authorizenet.inc	8 Oct 2009 04:26:47 -0000
@@ -348,7 +358,121 @@ function uc_recurring_authorizenet_arb_p
+
+  // Let other modules act on the canceled fee.
+  if (!empty($fee)) {
+    module_invoke_all('uc_arb_cancel', $fee);
+  }

We can delete this, uc_recurring has its own cancel hooks and CA triggers.

+++ uc_recurring_hosted/uc_recurring_hosted.module	8 Oct 2009 04:26:50 -0000
@@ -0,0 +1,27 @@
+  $fee = db_fetch_array(db_query("SELECT rfid FROM {uc_recurring_users} WHERE fee_handler = 'uc_authorizenet' AND data = '%s'", $post['x_subscription_id']));

The data field in the uc_recurring_users table should be an serialized array, so a quick hack would be to have something like... "data LIKE '%%s%'".

A cleaner solution would be to create a database table for the ARB_id -> recurring_fee relationship.

+function uc_recurring_hosted_uc_autho_arb_payment($post) {

Extra 'o' in there.

This review is powered by Dreditor.

I don't really have a lot of time to fully test the recurring part, but it looks good and appears to work, so I have committed it. I did notice a couple of small issues which i fixed before committing.

Probably should also remind anyone that you need the patch here: #592420: Move UC Recurring Fees code out of Authorize.Net module for uc_recurring to track the renewals.

I would like to leave this issue open as I would like some feedback on how we can allow people to migrate from 1.0 to 2.0 that are already using ARB without existing recurring payments failing.

I've committed the patch in #27.

I'm leaving this in "needs work" while the following are resolved:
1) #592420: Move UC Recurring Fees code out of Authorize.Net module
2) consider what upgrade path is available going from 1.0 to 2.x
3) confirmation that ARB renewals are being handled and new orders are created in ubercart on each renewal.

My understanding is that ARB generally works, it just needs that patch to ubercart to remove the uc_recurring-1.0 specific stuff that I mentioned in #29.

Anyone who wants this completely working without any patches should be pushing the ubercart guys to get that patch committed.

I did some basic testing it my patch above to the ubercart uc_authorizenet module did appear to work. Is it not working for you? Can people interested in this gateway start commenting on the ubercart issue so we can at least get the conflicting code out of uc_authorisenet to move this issue forward.

I do not care about this gateway as I don't use it, I have tried to do the work to get it working, someone needs to take up the cause and convince the ubercart guys to commit the patch.

I did some basic testing on my patch above to ubercart's uc_authorizenet module and it did appear to work when I tried it. Is it not working for others? I would ask that anyone actually interested in this gateway start commenting on the ubercart issue so we can at least get the conflicting code out of uc_authorizenet to move this issue forward.

I do not care about this gateway as I don't use it, I have tried to do the work to get it working, someone needs to take up the cause and convince the ubercart guys to commit the patch.

I did some basic testing on my patch above to ubercart's uc_authorizenet module and it did appear to work when I tried it. Is it not working for others? I would ask that anyone actually interested in this gateway start commenting on the ubercart issue so we can at least get the conflicting code out of uc_authorizenet to move this issue forward.

I do not care about this gateway as I don't use it, I have tried to do the work to get it working, someone needs to take up the cause and convince the ubercart guys to commit the patch.

Good news, the ubercart patch has been committed to ubercart-2.x-dev, I haven't tested the current state of this module myself (don't have ARB account myself), so if anyone can confirm everything still works that would be great.

What I also would like to find out is if anyone is trying to upgrade from uc_recurring-1.0 and what we might need to do to support an upgrade for sites with active ARB accounts.

This appears to be missing from the authorize.net ARB code, so I have added it. It is required for other hosted gateways like paypal. The patch I committed is below.

Hopefully someone who uses this gateway can do some actual testing.

No idea... I don't use this gateway, so can't really help with anything to do with this or most other specific gateways issues.

I am going to close issue since I believe the implementation works.

The issue that is still outstanding is:
#893812: Authorize.net ARB upgrade process for 1.0 -> 2.0

Any other bugs lets open new issues, so that can be specifically addressed.