Automated Recurring Billing Support

+1

Subscribing

Right now I have no plans to integrate the service. I suppose I can support it at an API level, but I have no intentions of attempting to develop and maintain a Drupal native recurring billing interface. My experience with UC Recurring proves it's very difficult to do well. Instead, I'll be focusing my efforts on integrating with Recurly via http://drupal.org/project/recurly. The best thing might actually be an alternate Commerce Authorize.Net ARB module.

subscribing

If you create any code, will you post it here, VMI?

Would it be possible to create an add-on module for Commerce that would handle creating these ARB (Automatic Recurring Billing) subscriptions on Authorize.net? The authnet API doesn't look too complicated to me: http://www.authorize.net/support/ARB_guide.pdf (They also have some sample code.)

Not being a programmer myself, I imagine the task this way:

1. Form for specifying the up-to-12 values that authnet API can accept for a subscription. This would be part of (or associated with) a single product instance (e.g, blue coffee cup without special coating).

2. Action code to send the ARB subscription info (the 12 values mentioned above) plus the customer info (including credit card info) to authorize.net

3. Some way to receive the response from authnet and display it. (e.g., "successful," "failed - invalid card", etc.)

4. A view that includes this subscription info in the customer's account page.

Is this accurate? Is there more to it than this? Ryan, I bet there are issues you're aware of that I don't yet see.

In any case, I'm interested in being part of the sponsorship pool.

Subscribing

+1

Subscribing...

Would be willing to chipin to fund a Commerce Authorize.Net ARB module.

I'd also be willing to chipin.

Any recent developements on this issue?

Check out this new module https://drupal.org/project/commerce_recurring

Did anyone succeed in integrating with either Authorize.net ARB or Recurly for recurring billing?

For my current project, my client specifically needs Authorize.net ARB support. So I'm going to take a shot at this.

Have other tried to write this module? Is there some code that I could finish in order for this feature to exist?

Please let me know, I have three weeks to write this module and I am determined to get it done on time and on budget.

Also, Ryan, can you let me know what dragons I'm about to run up against if the complexities and frustrations of this problemset are enough to turn you away can you let me know what they are so I can anticipate them.

Clearly the recurring billing is tricky. I am using D7 and need something that will handle recurring payments with Commerce as I have no intention to go back to using Ubercart. I tried Recurly, but the additional fees are no good and the module is in need of updating for compatibility with the latest API. I have Commerce Subscription Products installed but this provides no billing method. I am about to give the Commerce Recurring Framework a shot, as this appears to have some recent commits and activity. Would appreciate hearing from anyone about what might have worked.

I'm currently testing this recipe:
Drupal Commerce + Drupal Commerce Authnet (CIM + AIM) + Drupal Commerce Recurring

A lot of the rules to make the bare minimum of what I want are already there. I'm checking to see if it actually will send the recurring payment to my test account on Authorize.net presently. If that works then this will be my solution since it's based on Drupal Commerce and Drupal Commerce rocks!

Everything else seems to be working fine.

Edit: Everything worked fine. This is really awesome.

@cosmicdreams Hehe, you're in for a big surprise when those children Orders don't post Payments. The commerce_authorize module doesn't implement a charge callback that the "Process payments against recurring orders" Action in the commerce_recurring module expects to be there (see line 388 in commerce_recurring.rules.inc). I came upon this issue when setting my linux environment ahead in time using the date command to trigger recurring Orders and Payments. The Orders are built correctly, now the final piece of patching the commerce_authorize module needs to be done. I'm working on a patch right now and I'm in the #drupal-commerce IRC channel if anyone wants to chat.

Damn, if that's true, then I only have a few days to correct that. How long are you going to stay in the chat? I'll be back only into development mode in about 5-6 hours.

A good start #1418348: Integration with Commerce Recurring Framework

I have implemented the module (a sandbox project for a moment) providing an API to authorize.net ARB and implements ARB as a commerce payment method.
See: http://drupal.org/sandbox/vlkff/1572412
Hope it would be useful.

Did anyone ever get anywhere with this idea?

Someone from the maintainers should give a final word on the current status of ARB, as this is very confusing.

On the overview page of this module on Commerce Guys Marketplace it clearly says that it features "Automated Recurring Billing™ (ARB)* to handle online subscriptions.":
https://marketplace.commerceguys.com/extensions/authorizenet/overview

However, according to this issue, that is not the case.

What is the current status of ARB and this module?

Thanks!

This module does not offer ARB integration; Authorize.Net does offer and advertise (through our Marketplace) that they offer ARB, but that's listed in a set of general features of the gateway and not this particular module. Definitely confusing, will pass it on to their team to improve the listing in our marketplace.

Thanks for quick response Ryan!

I am also interested to know about the recurring.

Let's see if we can reboot this on D8. Adding support to this in D8 shouldn't be that hard. Also, linking in https://github.com/commerceguys/authnet/issues/12 for the upstream required changes.

Probably could use some automated testing, but this worked with manual testing.

I haven't had the chance to try this entirely but I did run into one issue. When using the ARB gateway there's a minor issue because it doesn't have a cca_status configuration option and AcceptJsAddForm seems to expect that.

Notice: Undefined index: cca_status in Drupal\commerce_authnet\PluginForm\AcceptJsAddForm->buildCreditCardForm() (line 177 of modules/contrib/commerce_authnet/src/PluginForm/AcceptJsAddForm.php).

re: #33
The error you are seeing is un-related to these changes. They are related to the fact that you have a default config stored in your active state that does't include the recent changes fro CCA. You would get those errors with or without this patch applied.

Here's one more small tweak I added for DX reasons. In my case, I have a bunch of items that can be purchased and some things that are a recurring donation. I end up extending the AcceptJs gateway class to weed out my donation line items and handle them separately. With that in mind, the TransactionRequest cannot assume that all of the money in the Payment gets assigned to this non ARB transaction. We should rather loop over the collected line items and set the amount from there. That one change means I don't have to copy/paste the entire method and change that small calculation.

Fix undefined index error on += addition.

Nice reorg, was it done to allow for more tests. I don't see more tests.

re #37:
I did the upstream changes in commerceguys, then built something here for general use. Then ate my own dog food and used the API in commerceguys to write my own custom payment gateway that extended from AcceptJs. When doing that, I discovered that the code in AcceptJs made a fatal assumption and /just/ a little tweak would fix it. Still needs tests.

Switching to more proper math.

Re-rolled patch to work with D8.6.1

Patch 39 update

Fix code standards.

Remaining task:
Need to fix the automated test.

update code standards.

Rerolling for 1.3.0. Only change is the removal of the change to UpgradeConfigTest, which was committed in another issue.

An update hook may be needed. I get an “Entity/field definitions” error in my status report:

Mismatched entity and/or field definitions
The following changes were detected in the entity type and field definitions.
Payment Method
The Subscription ID field needs to be installed.

Fixed add-payment-method form path

I don’t see the point of having the new payment method type authnet_arb just so we can show the user a “payment gateway assigned identification number for the subscription” in the payment method label. Additionally, it is possible for a payment method to be used on multiple subscriptions so the subscription_id would constantly be updated anyway which renders it useless for any programmatic purpose it could potentially have.

Also, it wasn’t working for me anyway :)

I think it should be removed.

For what it's worth, take a look at:

• The underlying commerceguys/authnet library, which does include some recurring methods
• membership module as well as membership_provider_authnet

I'm of the general thinking that recurring is super dependent on local business logic, e.g. in my case I am using payments but not orders, and membership entities and "membership offers" to encapsulate the purchasable entity. You get the idea. Not saying this approach isn't valid, but as heddn points out in #38 and Ryan in #5, this is probably a bit far afield from the core authnet module IMO.

Hello, It better to integrate with Commerce Recurring ?

https://www.drupal.org/project/commerce_recurring

need integrate here ARB with commerce recurring? Somebody have code for sandbox or some example?