Authorize.net Recurring billing module

Posts: 6
Joined: 08/07/2008

Hi

I need to integrate to the Authorize.net recurring billing API (ARB), and I figure the best way to do that is create a sub-module to the uc_authorizenet module, because ideally there should be a secondary payment process spawned if there are any products purchased that require recurring billing. For my requirements, I am using the Donation module, and I have defined a donation product with an attribute of Frequency, where frequencies can be defined (and hopefully applied to the recurring transaction).

Any recommendations for me? I'd like to start simply so I can get this client's needs met quickly, so I don't think I will be adding the attribute through the module to start with.

Thanks

-Dave

Edit: Actually, I think the best way might be to update the uc_authorizenet module itself...

Posts: 5617
Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Re: your edit, exactly what I was going to say. In fact, I was planning on starting this in the morning for someone who needed similar functionality and commit the improvements to core. I'm happy to collaborate, or I'm happy to have you do testing for me. I'd also be happy for you to use our affiliate links if you don't already have an Auth.Net account. Eye-wink

I think the best long term solution is to have the core Auth.Net module handle AIM, CIM, and ARB.

Posts: 6
Joined: 08/07/2008

Having the options within the module admin is definitely the way to go. Yes, I'm more than happy to collaborate and/or test. Unfortunately the client already has an account Laughing out loud, but I'll send a couple of future ones through the affiliate links!

Posts: 84
Joined: 12/28/2007
Bug FinderGetting busy with the Ubercode.

Hi Dave,

If you want to get Authorize.net recurring payments working quickly, you might consider using their Customer Information Manager (CIM) service and the uc_cim module (http://www.ubercart.org/contrib/2537). I think the only downside is that it costs $10 more per month. On the upside, it gives you some more flexibility than ARB and it's already written. Smiling

Of course, it would be great to see ARB integrated too, and I'm sure Ryan will have that knocked out in no time... Smiling

Chad

Posts: 46
Joined: 11/17/2008

chadcrew wrote:

I'm sure Ryan will have that knocked out in no time... Smiling

Any updates on this?

Posts: 5617
Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Yeah, ARB has been integrated for a little while now and works through the core recurring module. The main limitation is that you don't get notified when a payment fails from Authorize.Net.

Posts: 46
Joined: 11/17/2008

Ryan wrote:
Yeah, ARB has been integrated for a little while now and works through the core recurring module. The main limitation is that you don't get notified when a payment fails from Authorize.Net.

Well, isn't being notified from Authorize.net important or is there some other way of handling that. Ryan, I would really, really appreciate some input here. I am pulling my hair out over this because all the posts on this issue are 1+ years old. Thank you so much in advance.

Posts: 5617
Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

Basically what I'm doing for a client is keeping track in a custom DB table when the next payment is expected. If it doesn't show up for a few days after that, then I mark the account as past due. It's not solid yet, and it's hard to test b/c Auth.Net doesn't process ARB payments in their test server... That's the general way to go for now.

Posts: 46
Joined: 11/17/2008

Is that done in workflow-ng or manually?

Posts: 5617
Joined: 08/07/2007
AdministratorHead Code Monkey - I eat bugs.

I had to write custom code for it to work, unfortunately. And because it's tied into their other systems, it's not something really generically usable or sharable.