Get uc_authorizenet CIM working with version 2.x

I am going to try and use this patch.

I have implemented and authorize.net api in a custom cms before but this wll be my first inroads into the Drupal development process.

I just have a few questions.
Is there anyway to get at the raw data we are sending and receiving?
maybe logging anything i wana see with watchdog?
is this even a possible point of failure due to this patch?

I might be answering my own questions here in a little bit. Im going to be digging into this.

THANKS!

Ok i applied the patch but that made a PHP Parse error.
After further inspection, the problem was in payment/uc_authorizenet/uc_authorizenet.module line 788
i attached a patch that replaces the patch above. it doenst patch ontop

I have made a order with uc_cim/uc_recurring attached and everything seems to be working. The initial payment went to Authorize.net and I voided it there. So it looks like this patch, at least at initial inspection , works.

The only issue i have is possibly with uc_cim/uc_recurring. Everything looks good in the backend so far as the linking form order->recurring billing->cim customer profiles, but when i log back in as the user that made the order i can see the "Recurring fees" section and the "Click here to view your recurring fees" link. After clicking the link im am taken to user/3/recurring-fees. The problem is this lands me back on the users home page only with the url of user/3/recurring-fees.

Any Ideas?

There is a permission to enable/disable the ability for users to view their own recurring fees, thats probably all you need to do - although sounds like there is a bug there as you shouldn't see that link if the permission isn't enabled.

I thought that as well and was surprised to see that I had that permission enabled for authenticated user and all other roles as well. I confirmed that after removing the permission uc_recurring module-> view own recurring fees -> authenticated user it made the header and link go away. This user is only authenticated not part of any roles.

Note: even as user 1 viewing that user i cant navigate to recurring fees.

Is there a recurring fees tab on the users profile or just the link in the profile? as there should be a tab as well. Drupal's default behavious is if it cannot match all the url it will just send you to the page for the part it can match

so:

There is definitely a menu item defined for the recurring-fee bit:

Assuming you have checked you have the latest version of uc_recurring installed, maybe try clearing the menu cache?

This worked. Thanks a lot. I forgot Drupal cached this kind of data.

I just noticed a problem with this patch its not going to record the actually payment as being entered against the new order, ie the balance will always show something owing.

Added the following after calling uc_recurring_renew($fee);

This patch modifies what is in #3

I'm not sure what to patch against, so I'll just explain the issue.

I was getting an implode error on line 50 of uc_recurring.admin.inc. I traced the issue back to line 803 of uc_authorizenet.module (against the patch above on comment #8) missing a return call.

So, line 803 should read.
return uc_authorizenet_recurring_fee_ops($context, $fee); // just use the old function

Otherwise authorize.net seems to be working as long as you have a set length for billing period rather then unlimited.

Thanks, fixed that error in this patch.

Also fixed so that it should allow you to select unlimited rebillings in uc_recurring (although in authorize.net its actually setting number of billings to 9999).

So in order to do recurring billing with Authorize.net we need this module, this patch, and the silent post URL configured?

This patch is about getting the existing uc_authorizenet module in ubercart working with the new 2.x-dev version.

I understand that, just wanted to confirm that all of those are necessary for recurring fees with Authorize.net. On their site it says when you enable Silent Post, this changes all orders to use the Silent Post URL, which I'm not sure if I need or want. So I guess I should ask instead, is the Silent Post URL required?

I have applied the latest patch and assigned recurring fee to my test product. When I want to checkout I get the following error:

•There are no payment methods configured for orders with recurring fees!
•Please contact an administrator to solve the issue.
•Checkout cannot be completed without any payment methods enabled. Please contact an administrator to resolve the issue.

What else do I need to do to get this resolved?

This is pretty urgent and I would be glad if someone could help.

On the "There are no payment methods configured for orders with recurring fees" error, I've tracked down whats happening.

On the Product Configuration screen, there should be a field to select which payment method uc_recurring will use. In uc_recurring_settings_form, line 783. The invoking of _payment_method_list from uc_payment returns for me an array of one element, and that is from uc_credit_payment_method. So therefore, the only hook of uc_recurring_*_fee that is attempted to invoke is uc_recurring_credit_fee, which doesn't exist.

I see from the patches the addition of uc_recurring_authorizenet_fee. This is never invoked since uc_authorizenet doesn't have a hook_payment_method.

Given this, I can't understand how this works for anyone!

I guess what needs to happen then is the creation of a uc_recurring_credit_fee method in uc_credit that itself invokes uc_recurring_authorizenet_fee. Any thoughts on this?

I'll post a patch if I can figure it out..

In addition uc_recurring_authorizenet_fee which is never invoked, there is also uc_recurring_authorizenet_arb_fee_ops and uc_recurring_authorizenet_arb_renew. Following with the thinking in #15, I can't discern how these would ever be invoked by uc_recurring.

Please if someone could give me a clue.

sorry, I should have included a link to the following patch as well which is required for any credit card payment methods: #483494: changes to ubercart to work with uc_recurring

I have updated the front project page to show the dependencies as they are at the moment.

What I need if for people to test all this stuff and confirm its working as expected so we can push to include these patches in ubercart itself.

Sorry, I had found a solution for all this and forgot to post back here as well. Go to http://www.ubercart.org/forum/support/11356/there_are_no_payment_methods... and use both patches there and it should work together with the settings mentioned above. Our tests have been successful so far.

BTW, this is another example where I think it's a bad thing to have drupal.org and ubercart.org as two separate boards to discuss and support the uc_ module family.

Can these two patches be applied to the dev ubercart or only the RC?

I can't tell about the dev release, I've applied them to RC3

Hi all,

There were still plenty of problems I was encountering with the latest round of patches for both uc_recurring and the ubercart core mods like uc_cart and uc_authorizenet

Here are two patches, the first against Ubercart 2.0rc3 and the second against the latest uc_recurring dev build. They are mutually dependent, as I have had to make a few uc_recurring specific modifications to Ubercart. Most notably, I introduced a new hook_order $op "approved" which is invoked immediately after $op "submit" in uc_cart_checkout_review_form_submit. uc_recurring_order now engages on $op "approved" rather than "submit". I did this because I don't think recurring charges should be added if an initial credit card authorization fails in uc_credit.

There's a lot of little dits in here. I just had to plow through this and get it to a point of reliable functionality for my subscription based site.

There were many problems I detected with things like multiple recurring payments being created, improper arguments being passed to the xml handler, improper hook names, and much more. I have tested this as thoroughly as one burned out coder can, but I have inspected the raw back and forth data from auth.net and am satisfied that everything is happening the way it ought to. Other tertiary functions like the admin recurring fees screen have had some problems I addressed as well in this.

I also introduced a few hook invocations in critical places which I found necessary to things like when an order is for $0 but has a recurring fee, to only then do an authorization for the amount of the first recurring fee. (this isn't included, but i'd be happy to share)

Cheers guys. I hope this is helpful. I feel good about it. I guess I'll get some flack for a few of the choices I made like the extra hook_order invocation.

the attachments aren't patch files, if you need help see here: http://drupal.org/patch/create

I'm keen to review though.

Also keen to review these patches when available, reubidium.

I'm hopeful that we're getting closer; thanks for your hard work on this, reubidium and univate.

Now I just have to figure out how to turn those files into patches...

they're not? sorry.. i'll post some fresh rounds soon, i've also been working on the silent-post handler and renewal processing.

I was able to successfully apply uc_recurring_authorizenet_ubercart_2-x_compat.patch from #22 (it looks like the patch wasn't created correctly, so you have to manually define which files to patch against).

The other patch failed on a couple hunks against the latest dev release of uc_recurring. It seems like there's a few unnecessary changes:
-all of the changes in uc_recurring.admin.inc are comment style changes
-in uc_recurring.module, there's a change made to the $Id$ tag (which causes the patch to fail)

Keep up the great work everyone; I look forward to being able to get this working!

OK folks, here we go. These patches supercede what I posted in #21 (and hopefully are correctly done and usable)

These might want to be considered for 3.0 instead of 2.0 if lots of people are already invested in 2.0. A lot of function parameters and return values I've fiddled with, trying to get things standardized and more in line with what I feel as Drupal design pattern goals.

I have tested this pretty intensively but I imagine there's still some goobers in there I haven't yet seen. One bit of functionality in particular is the silent-post from Authorize.net ARB for renewal payments. If anyone knows how to fire off a manual silent-post from ARB, please let me know. I tried to lower the intervals in the initial create call, but it won't go under 7 days minimum.

There's probably also a missing bit for those who want to do recurring billing without using ARB on Authorize.net. There's a @todo in there asking if this is possible, and I do believe it is, because this is how the site I've been rewriting was doing it with Ubercart 1.x and uc_cim.

Note that update.php needs to be run with this, as there is an additional table I thought necessary in uc_authorize.net

I haven't actually attempted to apply these patches and test, but from a quick scan over the patches I think there is definitely some good stuff in here and would like to get a lot of this in.

Couple of comments:
1. It appears that a lot of the uc_recurring changes are just fixes/cleanup that could easily be put in a separate issue unrelated to authorize.net - the one thing I would like to avoid in the development of uc_recurring is focusing on any specific gateway/payment methods, so being able to separate what are general fixes from specific gateway issues is useful to see.

2. The ubercart patch is huge!!! I realize is includes my current patches for uc_credit and uc_payment_pack, but I am also concerned about changes to uc_cart and uc_product in there as well as the actual patch for uc_authorizenet.

My strategy has been to get a working uc_recurring module with some decent api and improvements over the previous 1.0 version and then package up a release (which I think we are close to being able to do) and work on getting any of the changes to other ubercart modules into the actual ubercart project. My concern is if we try and push a patch of this size on them its not going to make it easy on them to get it included.

So I think it would be better to aim for a number of smaller patches then 1 really big one, I think atleast separating the changes for the uc_authorizenet module from everything else. If there are changes to uc_cart/uc_product, like new hooks I would assume that they are not uc_recurring specific and could be submitted to ubercart right now (although I can't see where you are using that new 'approved' hook?).

I will try and apply and test this patch in the next day or so.

In the next days, I will split up these patches into atomic chunks and describe the problems I observed and my thoughts on improvements. Totally expected this would be everyone's first reaction ;-) I'm rather under the gun (as are we all I'm sure) to get my own project out, so this represents a few days of straight cranking "just to get it done" kind of thing.

The only change to uc_cart was the addition of an invocation of hook_order with an op of "approved" just after successful "submit". I did this in order that uc_Recurring would not be invoked unless all the other first-line payment handlers were successful. More for our own purposes with this project, but maybe others might want the same thing? (if customer's credit card is declined first round, then we don't start a recurring subscription for him)

Well, I'll get to splitting this up into more sensible pieces.

Thanks,
Reuben

Alright there are a handful of patches for a handful of modules, including a link to the "changes to ubercart to work with uc_recurring" thread. Can someone just lay out what needs to be done to get uc_recurring working with authorizenet, etc. Also specify which patches are needed / working, etc.

It also looks like theres a newer uc_recurring dev since reubidium's patches were posted, which probably explains why it's failing (2/36). What would you suggest doing for this?

And also, as reubidium pointed out, it seems pointless to use and pay for ARB and CIM. If the credit card data is stored through CIM, these modules should be able to initiate the payments when we want them to be. ARB seems useful for low-tech subscription sites that don't have cron or some other mechanism to handle the subscription payments...but at this point I'm interested in whatever works as soon as possible..

Thanks

Yeah, I agree with mikesteff, I'd be happy to test this but I'm not sure what module to apply to which version of ubercart to use with which version of recurring.

I've updated both patches so they apply correctly with the latest dev version of uc_recurring. I've removed some of the styles changes so uc_recurring.admin.inc isn't patched anymore, as well as unnecessary changes to uc_recurring.info. There's a lot more that I didn't get to though.

Also, there was a bug in test_gateway.module in uc_recurring_test_gateway_fee_ops(): $fee was being used as an array, where it's being passed in as an object. Patch updated to reflect changes.

Subscribing.

subscribing.

I'm working on getting uc_recurring working with the eway gateway, so this patch is a good start.

thanks!

I'm having trouble applying the uc_recurring_authorizenet_ubercart_454952_32.patch to the latest dev build of ubercart.
is this because it needs to be applied to a specifc build? if so, which one?

sorry, am a bit new to the "patch" process.

Okay i'm getting closer... managed to get your patch applied. hooray :)

I found a couple of problems with your new uc_recurring_fee_save function though and thought i'd post them here so you can roll fixes in to your patch (keeps it one place etc)

Firstly, uc_recurring_fee_save doesn't actually perform the insert to the uc_recurring_products table because of the third $update argument (and because it was trying to update the users table)
So i added a check in to see if this was going to be an insert or an update.

Secondly the uc_recurring_fee_delete function was making object references instead of array references, so the deletes were failing
a just changed all mentions of $fee->pfid to $fee['pfid']

Will let you know if i find anything else

-Tim

Hi

If we apply these patches to get the latest code, are we sure they will make it into the next releases of UC, so we can upgrade UC as it is released?

sub

This is a reroll of the first patch from #32, with the fixes described in #36 included.

I also took up the @todo to use -1 instead of NULL for unlimited recurrences, as this was giving me some trouble. This includes changes to uc_recurring_update_6005, so other testers should uninstall the module after applying this patch.

Note that uc_recurring_authorizenet_ubercart_454952_32.patch from #32 is still required.

subscribing

subscribing

error in the uc_recurring patch as reported here #524796: Using Attributes for Various Intervals of Recurring Fees Not Working...

I'm not sure which patch, but the following was somehow dropped from the updated query in uc_recurring_find_applicable_fees_for_order.

rp.model IN ('". implode("', '", $models) ."') AND

Without this little bit, any product added to a cart did not have it's distinguishing "sku" or "model" that is associated with it's attribute/recurring fee. Not sure how it's worth it to make a ~50 character patch (plus, I don't really know how).

subscribing

I missed a change required for my patch above.

Change line 313:

to:

[edit] This is a reply to #42 [/edit]

Can anyone confirm that we need to add this code?

After patching uc_recurring.module with #39, starting on line 1159 I have:

Should this, in fact, be below?

I'm running latest dev of uc_recurring and Ubercart RC3. I've applied patches from #32 and #39, and made the fix in #44.

With this setup, users marked "View Own Recurring Fees" and who have a recurring fee that never expires will not have proper permission to view their recurring fees.

To fix, Make a change in uc_recurring_user_access. (edit: fixed code)

Change:

to:

I just wanted to say that I've tested the above on two sites and it appears to be working fine on both. I'll let you know if I run into any problems.

Any word yet on how these patches will apply to Ubercart RC5?

with the setup mentioned above (Ubercart RC3 Patched, Latest Dev of uc_recurring patched and all mentioned minor changes applied) it works fine for me with a test gateway.

I've tested it now with Authorize.net in a live account, and for the most part gotten it to work.

If the product is set to unlimited charges, authorize.net returns the following error:

One other small bug I noticed, on the product features screen the display of the recurring feature always says "And will be charged $0.00 every..." no matter what price you set for the recurring fee.

Other than that...so far so good. I'll know more tomorrow and over the next week when I can actually check out my recurring fees.

vood002...

i'll confirm that your second piece of code in #45 is correct - you need to have the rp.model piece of the query.

i've only tested locally with the test gateway, but that piece is required for varying "attributes." for example, i have a radio buttons (for the method of choosing a product's attribute) of monthly, quarterly, and annual "recurring" fees.

this should be a fairly robust solution to collecting donations (coupled with a 'patched' uc_varprice -- http://drupal.org/project/uc_varprice).

the "product" skus are essential to determining donation frequency.

So I've:

1. uploaded ubercart 2.x and set up auth.net
2. uploaded uc_recurring
3. made uc_recurring changes apply to ubercart
4. applied patch in 32 and 36
5. made changes in 44,45, and 46

I then:

1. put through a non-recurring order - success
2. put through a recurring order - order success but php warning - Missing argument 3 for uc_recurring authorizenet_fee ... in uc_credit.module like 880.

I looked at the code and it's only got 2 parameters...I look at the patches in 27 and there's a change to that function.

I assumed with the text from 32 that 32 was to replace the patch in 27? now I can't apply 27 because I've already made all the other changes.

Can somebody put together a single straightforward patch with all the changes thus far rolled into 1 change for ubercart and uc_recurring? I think at this point this thread is so complicated it should pretty much be closed and started over from scratch with the current working patches.

Expressing my support to get all the patches and improvements integrated into a coherent form that we can all use as a new starting point. My head is spinning...
Thanks so much to those who know what they are doing and can help the rest of us!

mcaden-

I applied everything in this thread using the patches from #32 rather than #27. I kind of sum it up in #46.

I've got recurring fees working without the error that you received in a production environment, with Auth.net registering all the recurring fees sent to it.

I've yet to see if the recurring fee will grant the roll associated with the product...I'll know that when my test case fires again in a couple of days (auth.net minimum time for recurring fees is 7 days).

I support getting everything here coherent as well...never made a patch though and I've got too much else going on to take that step right now.

There has been work on integrating all the ubercart core payment gateway code into this module (#534296: Make uc_recurring completely independant from ubercart, uc_recurring will handle all ubercart core payment methods via inc files). This means we wont have patch ubercart or get anything commited into ubercart and we can be free to continue updating and improving uc_recurring as we need to.

What that means is we will be combining all the authorizenet code into one *.inc file which will be part of uc_recurring so everything will just work by downloading uc_recurring

This post is Just to let everyone know where things are going and hopefully we will have something to download test over the next few weeks.

@vood002 - I looked at 32's patch, it seems the updated function is in that patch. Apparently I didn't apply correctly. I'll revert to a fresh install of ubercart and repatch. After that I'll try and make a new - single patch with all the updates

@univate - that's nice and probably how it should be, but "in a few weeks" doesn't help projects that are due "in a few days". Thanks for your hard work on rectifying the need for this mess anyway.

Additionally,

As I understand it...you have to either use ARB or CIM for this to work, right?

I though I might add that I don't have access to a authorisenet account to test this gateway myself, but I am going to be attempting to package whatever code I can find here into an *.inc file and commit it into uc_recurring 2.x-dev along with the patch that is almost ready to be committed here #534296: Make uc_recurring completely independant from ubercart, uc_recurring will handle all ubercart core payment methods via inc files

I've been waiting for this for a while now, so if that's the case, I do have an authorize.net account and will test for you.

Univate, You can get a developer's test account at Auth.net. You just have to ask nicely and they very happily will give you testing credentials for their dev gateway.

My first recurring fee tested correctly with Auth.net ARB, this side seems to be working well.

This did not, however, refresh the role that is associated with the product. Should I have "Multiply by Quantity" selected on the role assignment feature? I currently do not.

I've checked out my conditional actions and it might have been caused by one condition I added to the "renew purchased roles" when I was screwing around with a free trial period...I'm going to try another 7-day test to see if this one returns correctly. Has anyone else had the role-renewal work or fail yet?

As far as recurring fees go, I've had two cases fail so far. In each case ARB did not return an error (and I can't find anything in my log--see below), so my assumption is that it was never passed the recurring fee at all as part of the product. One of these was when an Coupon was applied to the product using uc_coupon, the other was when the user changed the Attribute from the Monthly to Yearly option. I looked over all of these carefully and I can't see any errors in my settings. I've changed my dblog settings so I'll see if I receive an error next time this happens.

EDIT

I've been getting another error rather spontaneously... everything will appear to go fine with the recurring fee order, it will be successfully sent to Auth.net, but in the uc_recurring_users table the UID will be set to 0. This has happened to me on three non-sequential orders of the same product (split up by successful orders), and I can't tell why.

I see that my dblog was set to record last 10000 lines, but errors keep getting pushed out of it because I get this huge error about rebuilding the menu router table that I still haven't solved. ---thus, I can't tell if I received an error when this recurring problem happened. I've changed my dblog settings and will report back if I can figure out where/why this error is occurring.

subsribing

I've been trying to workout what to do with this issue... what started out as an issue to create the necessary code for authroizenet to work with uc_recurring api's, has to turned into hacks on both ubercart and uc_recurring that should have been posted as separate issues so we can resolve each issue. These patches make it impossible to understand where the problems are or were in uc_recurring with trying to integrate with authorize.net

As it stands I would not recommend anyone try to use these patches as they will not be compatible with any future version of ubercart or uc_recurring. Actually they are probably no longer compatible since the recent commit to uc_recurring have broken these patches.

I think looking forward we need to start this from scratch again...

I am thinking that it might be best to completely ignore the ARB part of authorize.net and just implement everything bases on CIM. It appears that there is an implementation in ubercart for authorize.net CIM - although no idea if it works. If it does work then it should be straight forward copy of the test_gateway function and replace them with calls to the CIM functions.

I am not personally that interested in this gateway myself, so don't know if there are any issues with this plan? Are there reason (price?) to use ARB instead of CIM?

The core CIM funtionality in Ubercart 6.x-2.0-rc6 does work. The thing it doesn't do at the moment is interace with recurring payments.

The older UC_CIM module from comment 28 and 30 at http://www.ubercart.org/contrib/2537 also works and does a pretty good job of handling recurring payments.

Here is a description about the difference between the two:
http://www.ubercart.org/forum/support/11990/authorizenet_cim_feature#com...

I for one would prefer sticking to ARB because it is half the price of CIM and it seems a lot of the benefits of CIM are already built into Ubercart. Plus, we're already using ARB because this module aimed to utilize it. I think on price alone, even, it makes the most sense to stick to ARB.

I for one would prefer using CIM because it would allow us the most flexibility and the best user experience. If we really want to focus on making out customers experience as simple and painless as possible CIM is what we need. It would allow return users to avoid entering their credit card information again. This means returning users can go from product screen to invoice in ~10 secs. Also recurring billing could be more flexible.

In my opinion the extra $10 is worth it, but hey Im not the only one here so please voice your thoughts!

ARB = $10/month
CIM = $20/month

There is no reason that we can't have both (in time), my evaluation of the two though does suggest that CIM will offer a wide set of features and better user experience, so I would probably recommend CIM over ARB if some asked by opinion on which was better.

But I was not aware of the cost difference between ARB/CIM and understand that ARB would probably a cheaper solution for those that didn't require the additional features like being able to update/change a members recurring fee from within uc_recurring.

Since ARB is cheaper and does less (so it's easier to implement?), perhaps get out a working version of that and focus on CIM in the long term?

If the CIM code in ubercart works then it should be a no brainer to get that working, it would just be a copy and paste from what we have already done to create the test_gateway and just replace the internals with the calls to the code already in ubercart, in theory that should just work and I will try and post something shortly.

ARB only has less features because they do everything and don't allow you to control the recurring fees, meaning any advanced stuff we might want to support (e.g. upgrading/downloading a subscription product) will never be able to be supported with ARB.

The initial setup and testing of either CIM or ARB is not really going to be that different, since they both need atleast the basic functionality to work. If anything ARB probably has more stuff you need to setup initially because you have to do all the background "silent posts" stuff as well as the normal processing of credit cards.

If you need this right now, ubercart and uc_recurring 1.0 works with Authorise.net ARB, so I'm less wanting to make that the priority, since there is already a solution for this that works. Not say we would never support ARB and while I personally have no plans to use this gateway at all, I'm willing do my best to get something working, but what we really need is someone who is interested in this payment gateway and can offer to support it.

Ah, thanks for the detailed explanation. So for ARB, UC Recurring 1.0 works with even the latest dev version of Ubercart? Or only for a specific version?

@butler360 - to be honest I have no idea, I really have no interest in using this gateway myself, so I can only go on what I have heard. uc_recurring was branched at Ubercart 2.0 RC2. 1.0 is still the current recommended stable version of this module, but previously it has only been documented to work with authorizenet ARB. I assume that how it worked at RC1 should be almost the same to now at RC6. Of course it wont have some of the improvements we have been making.

I have attached is a quick attempt to get something that should work for authorizenet CIM, there is a #TODO in the code as I haven't worked out how to retrieve the ref_id required to do the rebilling, but otherwise this should work - although be aware that none of this has been tested so maybe someone with a little debugging skills can take it have a play with it?

Chris,
I looked at your CIM module that you posted here and I wonder if we also need a _uc_authorizenet_cim_profile_create() function (as we see at ubercart/payment/uc_authorizenet/uc_authorizenet.module on line 249) as part of your uc_recurring_authorizenet_cim_process() function? I couldn't see how a CIM profile would be created otherwise.
Thanks again for you help in moving this forward,
James

A new profile should be created when you do a reference_set transaction:

As for the other issue here (where the #TODO is marked in the code), I think the profile id (ref_id) can be found in:

problem is this is actually an array of possibly more then one reference, so which one do we charge? there is also a date logged next to each reference so we could sort through them and use the most current? the easiest method might be to just use the last reference.

So this should do it for the renew function:

More progress...

I tested this out on the same clean ubercart and was able to:
- configure the Payment method to Credit Card with Authorize.net as the default gateway
- configured the gateway to Authorize.net using CIM

But when I went to set the recurring payment method at /admin/store/settings/products/edit/features I did not see a Credit Card checkbox there for that.

Hope this is helpful....

I got this patched and going on Ubercart RC3 with UC_Recurring Dev.

I found that recurring won't kick off unless you specifically set the SKU, "Any" won't work.

So I got purchases showing up in UC_Recurring. However, when I look at the transaction in Auth.net it says:

Recurring Billing Transaction: N

So...it didn't work? Or is it actually still going to be processed?

I'm using ARB and I have it set to production and have the MD5 set up.

Can you share your patched files?

With CIM, think that the "Recurring Billing Transaction: N" makes sense because as far as authorize.net is concerned it is not a recurring payment. Ubercart knows that it is and will run the new order at the end of the interval.

I could be wrong, but that is my understanding.

I'm using ARB.

As for source I was waiting till I got it actually working.

@mcaden as I stated above my code is for CIM only.

I have committed the above code to dev - hopefully it makes it easy for every to test out?

I have also just committed code to check that the gateway being used is actually supported, so you shouldn't accidently be able to use a gateway unless it has the supporting uc_recurring functions to go with it. In the case of this gateway it means that you will need to go to the authorize.net payment admin settings and enable CIM for this to work.

This is still completely untested.

Anyone have a clue how to log the request to authorize.net - I keep getting an error:

REJECTED: Recurring Billing is required.
Amount: $4.99
AVS response: P - AVS not applicable for this transaction
CVV match: -

With and even when this module is disabled. I've been pulling my hair out for two days on it. Apparently it is leaving recurring blank or is missing one of the fields and throwing things off.

I could troubleshoot this if I could see the request. UC logs the response, but I'm clueless as to how to see the request that was sent.

@#77

I'm in the same boat, could you provide the code you have at least semi-working and then we can put two heads to work on it?

@univate - I'm using the pre-CIM stuff. (see 55).

@paulcouture & bearstar - This is what I'm working with. It's full source and not simply patches - a bit easier to deal with. As it's not just a patch I've used my host to host it instead of attaching here.

This is pre-CIM so it expects ARB.

http://www.katalyststudios.com/downloads/uc_recurring_authnet.zip

Thanks so much mcaden, I'll see if it helps, and what I can contribute back to this important process.

@mcaden, ok now I understand, please make sure that anyone that uses mcaden's code has ready my comments in #63 about future support in uc_recurring

For anyone who hasn't seen, bearstar has tested my CIM code and reported back here: http://drupal.org/node/567896#comment-2034748

That means that authorize.net appears to be working from his testing using CIM and this code is in uc_recurring-2.x-dev right now.

So this issue can now continue on as an issue to get ARB support working.

Also I thought I should repeat the comment bearstar made in the issue I linked to above, if you are using authorize.net CIM as your recurring gateway then when configuring the authorize.net settings in ubercart you need to make sure that the CIM settings are not disabled (ie: either set to "Production" or "Developer Test")

Using the link that was posted in #81 the only change I needed to do was:

Uncomment line 465

in uc_authorizenet.module to get this working properly with ARB.

I need to verify that the hook_cron isn't firing, but as long as you use silent post with ARB, I was able to create and cancel and update subscription based products in ARB.

@paulcouture @mcaden sounds like you guys haven't enabled the ARB feature under admin payment settings for authorize.net in ubercart.

I have attempted adding ARB support to the current version of uc_recurring with the attached patch. I have tried to reuse whats already available in uc_authorizenet, so hopefully it should create the recurring subscription correctly (assuming that code work, and if not then lets correct it in uc_authorizenet by providing the ubercart team with patches)

You will need to enable ARB instead of CIM in ubercarts settings, if you enable CIM it will default to use that instead since that superior and provides the ability to make use of features we might think of adding in the future. Since authorize.net ARB takes care of the actual renewals, they should happen, but they wont be handled in uc_recurring yet or the existing code in uc_authorizenet may try and handle them with un-predictable results.

None of this code has been tested on a real gateway yet.

I have it working in production. I have disabled CIM and enabled ARB, perhaps my post wasn't clear (it was close to 4 AM)

I was constantly, even without uc_recurring enabled on a clean ubercart install getting an error because uc_authorizenet.module had the line commented out "x_recurring' and authorize.net didn't like that at all.

Once I passed a value all the problems cleared up using the code that mcaden provided. Took a while to find the cause of the issue, but it is working.

@univate ARB is set to production, CIM is disabled. Additionally silent post URL is set and the MD5 is set.

@paulcouture Odd, I wasn't receiving that error, but you say it's working for you? Did you see the transaction in Auth.net has recurring: Y? Or is bearstar's post in 76 accurate and cron will take care of it?

@paulcouture and @mcaden, the reason I though that you had not enable ARB is because in #85 your hacking the charge function to do recurring billing... If you really need ARB why don't you guys just use uc_recurring-1.0 which is stable and only works with authorize.net ARB?

Auth.net works with 1.0 as-is? I thought it never worked and this was an attempt at getting it working in 2.0.

@mcaden - please ready my comments in #69 and #71 above

I don't know how I missed that. I'll give it a shot.

Argh this is frustrating...

I switched back and uninstalled and reinstalled ubercart and uc_recurring 1.0

Everything seems to show up fine in drupal, and the order shows up in auth.net but it says "Recurring: N"...

So I look around Auth.net quite a bit more and I find ARB subscriptions are completely separate, and it has 1 order! so I look, hoping it's the one I just put through...unfortunately it's one I put through 4 days ago. So it would be the one from the codebase I coded on the 11th and uploaded here on the 12th.

EDIT: I just re-uploaded my old code, put through a test transaction, and it still says "Recurring: N", AND there's NOT a new recurring subscription...this is giving me such a headache.

One thing I was wondering, is that I'm being told Auth.net works in uc_recurring 1.0...but I see nothing about authorize.net in it's settings. There's no authorize.net payment handler for it. There's only a credit card handler which is using the authorize.net gateway. Is this right? Am I missing something here?

EDIT2: After thinking on it a bit more, I suppose the reason for "Recurring: N" is that it's reporting that this transaction it's waiting to settle was not caused by ARB which is correct. So I guess the only problem at the moment is why ARB subscriptions don't seem to be being made.

EDIT3: Tried again completely removing recurring...I think I forgot to run update.php last time so it missed some database stuff. I disabled recurring, uninstalled recurring, and reinstalled. It worked like a charm this time.

mcaden,

As I understand all you need to do is in ubercart/uc_recurring-1.0 in the configuration area is set:
* Payment settings and enable the ARB settings for the authorizenet gateway
* Then you go to the product settings and from the drop down box select authorize.net to handle all recurring fees.

After that it should work.

... but there are limitation with 1.0 that 2.x is attempting to solve, firstly I want all recurring fees to be treated as new orders, so they have seperate invoices, 1.0 treats recurring fees as just payments on the same order. Because they are not new orders they can't trigger a role renewal as well.

In 1.0 - Authorize.net wasn't in the dropdown - only "Credit card". Credit Card was set to use the Authorize.net gateway though.

Anyway, I couldn't get it to work, and I got 2.x to work. So will 2.x trigger that new order/role renewal?

@mcaden - from your previous posts it appears you are using a hacked version of 2.x and not the current dev, I made a few points in #63 about this since it appeared to me that people were forking the project. Since there is no code in uc_recurring that official supports ARB yet and no-one has provided patches against the current dev for me to test/commit all I can tell you is that as far as I know ARB doesn't work with uc_recurring-2.x

I have committed further improvements to the CIM gateway, should now correctly record the payment against renewals as well as support users updating credit card details on their account.

univate -

In #94 you said:

... but there are limitation with 1.0 that 2.x is attempting to solve, firstly I want all recurring fees to be treated as new orders, so they have seperate invoices, 1.0 treats recurring fees as just payments on the same order. Because they are not new orders they can't trigger a role renewal as well.

Will the first payment of the recurring fee be considered a new order? And will this trigger a role creation? Then will the role stay active until a cancellation has been processed? That would be sufficient for me.

I have 2.x - Is this limitation solved for 2.x? Does 2.x/uc_recurring work like above "sufficient"?

vitis

Nope, this was one of the main issues with 1.0 - there has never been a way to properly manage roles/recurring subscriptions

The idea in 2.x is that all renewals are treated as new orders, so just as a new order can trigger adding a role to a account a recurring order should now be able to do this as well.

So, is uc_recurring working well enough for me to use it for role subscriptions with a monthly fee?

If uc_recurring is functional, what modules and patches are necessary to run it with (1) Authorize.net, (2) credit cards, or (3) the gateway you recommend?

Looking for:
ubercart - which version?
uc_recurring - most recent dev?
patches - which?
code hack - where / what?
special setup instructions that are not mentioned in uc_recurring READ ME or uc_recurring project page?

If this is not the proper place to post this - where should I post this?

Everything is working great to do exactly what you need, I am going to write an article on it for everyone to have on hand.

ubercart - which version? BZR or RC6
uc_recurring - most recent dev? Yes sept 17
patches - which? none
code hack - where / what? none
special setup instructions that are not mentioned in uc_recurring READ ME or uc_recurring project page?
Authorize.net with CIM

Product needs two features, a role assignment of 1 month. and a recurring fee of one month.
Every month the recurring fee will be charged and the role will be extended.

If the renewal fails the role will not be extended.

Awesome! Is "Authorize.net with CIM" the same as the core auth.net module? I kept seeing references to uc_cim here and there, so I wasn't sure if that was in any way related.

no need for any uc_cim, or any patches, everything works now, docs, writeup/screencast in the works.

Killer... can't wait! Nice work, everyone!

I had actually change the title to getting authorize.net CIM working, but I think due to the length of this issue it might be best to close this one of pat ourselves on the back for getting this functionality working and start a fresh with the ARB integration in a new issue.

#101
thill_ - September 17, 2009 - 15:09

Everything is working great to do exactly what you need, I am going to write an article on it for everyone to have on hand.

Excellent!

Automatically closed -- issue fixed for 2 weeks with no activity.

Subscribing....