Recurly API version

adding a tidbit to this issue. it's kind of a separate matter but until this module gets a rewrite for the new Recurly API, there is some additional functionality that may be worth patching against the Recurly 0.25 api, namely the $subscription->reactivateSubscription which can be very helpful if you want to try and make it easy to bring back customers after they cancelled their subscription.

the patch files for this function are here, its basically the same as ->create() but $data is not necessary and there is '/reactivate' appended to the $uri

I first looked at Recurly as an option for payments in Commerce. Now I'm rethinking this heavily. Especially with the Card on File module that has been released and the recurring payment module recently going live as a project here on Drupal.org.

Recurly has a lot of nice features that I like. The cost and it's maturity is in question though.

@sanguis there is also this one as well https://drupal.org/project/commerce_recurring Which uses the card on file module! I will be investigating this one within the next week before the holidays.

FYI I've implemented a Recurly 'card on file' functionality so subscribers can update their card. This allows for only one card per subscriber to exist in a 'recurly billing' table. When they want to update their card on file, I'm calling Recurly to get the last 4 digits on the card, etc and pre-populating a form that submits to Recurly and upon success, updates the local values as well. This is enough for me.

One thing I wanted was a complete transparency with Recurly, so user's can update their subscription SKU, credit card and billing info, etc within Drupal. Then I'm using the user->uid as a token for all the notifications that Recurly sends out, like "click <a href="http://www.example.com/user/{{uid}}/billing/edit ">here</a> to update your billing info".

I can post this 'recurly_account' module somewhere if anyone's interested. It just extends the Recurly module to provide the above.

Any new developments with this?

@blasthaus -- I would be interested in seeing the 'card on file' work you've done.

I actually went ahead and pretty much rewrote the Recurly module to use version 2 of their API along with Drupal Commerce specifically to work for a client. It just keeps track of the last card used (last 4, etc) and allows subscribers to update their card number with a credit card form on the user profile. Assuming you already know about the Commerce cardonfile module which provides this functionality (but allows for multiple card data (last 4, etc) to be stored. I'll see if I can post some cleaned up, simplified version of my Recurly module as a few more people asked to see it by now and I just haven't found the time.

That would be very helpful. Thanks for pioneering the work on this.

@blasthaus This is so very interesting. Even thought there is the card on file and commerce_recurring I am still very interested in Recurly cause they have some nice tools. Recurring billing is a bear of a problem that I would love to offload to a service that I can use that has a robust API like Recurly has been developing.

I would be very interested in helping you with this. Possibly look into applying for co-maintainer of this module as I don't think Ryan has the cycles or requirements to devote to this project - I spoke to him in person about it at a Drupal Camp in Atlanta.

I have done quite a bit of research on recurring revenue solutions for D7 and came to the conclusion that Recurly offers the most complete solution (dunning management, reporting, ease of use, customer engagement etc.) out there. If anyone is interested in forming a group to pay a developer to do it let me know.

@blasthaus Any chance you could post your module, please?

i'm working on it this week (since yesterday). i have to strip a bunch of stuff out since it was a custom module with about 60 functions (and i was of course lazy :-) i'm trying to make it as 'generic' as possible. Still i'm unsure it will be usable for everyone as it was developed for a specific use case. Nevertheless it would be helpful to know what people want to do with it. For example, does everyone want to use Drupal Commerce? Does everyone want full transparency from Recurly? These are two major points that this module assumes. So I would like to get this in a sandbox this week and get feedback on what everyone thinks.

Here's some text from the README draft:

Overview

1. Integrates with Drupal Commerce to provide upon successful cart-checkout, a Recurly account and subscription.
2. Allows subscribers to update or change their billing information and credit card (ala Card on File type of functionality)
3. Allows subscribers to change their subscription to a different one (hooks suggested here to get the most out of it)
4. Allows subscribers to cancel their subscription
5. Allows subscribers who cancelled to reinstate their subscription

Admin

1. Provides a jQuery 'datatable' for viewing/searching all active subscriber accounts, subscription details, invoices and transactions
2. Above stores locally subscriber's account and subscription data and is intended to make it easy to view basic info without having to login to Recurly. Roadmap here is to make this functionality work on a cron tab, so you can always have fresh data locally. Right now the module recursively just keeps calling (via curl) accounts and subscriptions until it fetches all that are active. In other words, if you have thousands of subscribers, this may be cumbersome. But there is a cache mechanism there so once you visit the admin page once you won't have to wait for that procedure for some time. This is primarily for customer service, so you can quickly see what is going on with someone's account/subscription/transactions.

Limitations:

1. Currently works only with Drupal Commerce
2. Works as transparent gateway to Recurly and is not suitable for anyone wishing to allow/expose users to view/edit their account directly at Recurly
3. Add-ons are not supported in this module yet although are planned for the future. (Recurly charges extra for add-on transactions)
4. If you offer multiple subscriptions, this won't work at present. (Although it could be in the development roadmap) The design of the module was that each subscriber could only be subscribed to ONE product. So each possible variation of the product needs to have a unique sku. For example if you have "Product A, monthly billing" and "Product A, annually billing", those are 2 different products/skus even though it's the same product.

Once I set up the sandbox, let's just move the dialogue over there. I'll post here when it's set up

For example, does everyone want to use Drupal Commerce?

Does everyone want full transparency from Recurly?

Yes and yes!

The readme seems helpful and straight forward.

Thanks for contributing!

@blasthaus Thank you very much for contributing. If you do start a sandbox let me know. I want to help!

I'm also highly interested in this and would love to help, too.

--Ben

thanks guys. i'm close to getting this ready. spent the better part of last week and this working on a serious release. i don't want to put something up until i make a few more adjustments. the stuff that tripped me up was dealing with the fact that I built in the option to buy as an anonymous user as well as the ability to pass in the user id into the recurly acct code. headaches abound. Drupal Commerce payment submit forms are out of scope of form API, so I had to create my own table to store form['state'] type of values (like recurly acct code, user email, etc). If you are interested, some of this frustration is documented here http://drupal.org/node/1512920

Note: the reason to pass in the user id to recurly is for the purposes of using this as a token for their Dunning management emails. i.e. to edit your subscription, change your billing click <a href="http://www.yoursite.com/user/%accountcode">here</a>

So as it stands everything seems to be working as it originally did for my client and I will take the next week to wrap up the testing. There are settings also that can enable you to subscribe users to start billing on the first day (actually first second) of each month with a pro-rated fee for the current month, rather than immediately, don't know if that's important but it was for my client. i think it's pretty cool feature.

In general this will need a lot of testing from the community to make it full proof. All of the payment gateway-type functionality has been done according to the DC standards out there, however since it is a subscription, we're obviously doing a lot more stuff. Additionally I've put in several hooks for things like building the recurly account code as well as theming templates for subscription and billing info, etc.. for subscription change it's a form which just gets all products in one select list, so it's better to override this in the supplied hook as well.

thanks everyone for the patience and interest, hang tight, we're almost there. i look fwd to getting this one out there, believe me!

Sounds good, look forward to testing it.

Ok so let's start with the rewrite of Recurly. http://drupal.org/sandbox/blasthaus/1534668

Warning: this is a module named recurly just like the current module. i.e. name collision in a big way can spell problems unless you know what you are doing, so it would be advisable to use a fresh install of Drupal to test this out. I just cloned it into a new Commerce Kickstart and its working as expected.

This version of the module requires v2 of the Recurly API, just download the latest one. It also works well with the CTools and jQuery plugin Datatables library. Download them as sites/all/libraries/recurly and sites/all/libraries/datatables

The actual Commerce Recurly stuff is coming next and builds off of this.

Awesome! I just subscribed to your sandbox. I'll clone the repo this week and start taking a look at it. This is pretty exciting and coming at a good time.

After committing #1289192: Recurly API changes break authentication, this module now uses the latest API again, though it still needs lots of work.

@blasthaus: I'm taking look through your sandbox and pulling/porting the code back into this project. I don't think a dependency on Datatables is really necessary, but through some minor theming it should be easy to support (since you basically just need to add the JS to the page).

hey thats great! I have a new commit for the sandbox which I'll try and put up today. The main reason for Datatables was to just to be able pull in all the data on active subscribers and accounts into one view. With the commerce_recurly module (soon to be a sandbox as well), I am using the links as a pager, so we integrate that approach here as an alternative too. Look fwd to being in touch on this.

Great, thanks @blasthaus! I'm pulling code liberally from your sandbox back into the project but adapting quite a bit as I go. So far I've attempted to stick with the SDK's approaches rather than falling back to doing HTTP requests directly against the API, so our approaches are diverging a bit. Still the code has been most helpful and I hope we can get all our work merged back together. :)

@quicksketch That's fine, you'll see in the new update, that I've fallen back to that approach after discovering how to do it via their API %-) There are really only two points that I truly need for commerce_recurly. The first is the pseudo 'hooks' in the function recurly_accounts_overview for the commerce_recurly_setup module, the second is this (new) function which eliminates the following functions: recurly_get_all_data, recurly_record_by_curl, recurly_data_by_curl, and recurly_xml_to_object

<?php
/**
 * Taken from the Recurly 2.0 API, this simply takes a method, a url and option xml and returns an array of elements: statusCode, 
 * header, body(array of data converted from the xml string) and a main_element which is the main element of the xml string 
 * returned. If $all is TRUE, then the function will iterate through pages of results to retreive them all and return one numerically 
 * keyed array.
 */
function recurly_send_request($method, $url, $xml = '', $all = FALSE) {
  // this is the new approach taken from client.php in the API
  $client = new Recurly_Client();
  $request = $client->request($method, $url, $xml);
  $object = simplexml_load_string($request->body);
  $request->body = @json_decode(@json_encode($object), 1);
  $request->main_element = $object->getName();
  if (isset($request->headers['Link']) && !empty($request->headers['Link'])) {
    $request->links = recurly_get_curl_links($request->headers['Link']);
  }
// after this, we return the $request unless $all is TRUE in which case we use the 'next'
// link to continue fetching results and then return only the results as a numerically 
// keyed array
}
?>

As for the recurly_settings_form, I can hook into that for the commerce_recurly stuff, so you can take it out. I'll try and get this up on the sandbox today.

@EDIT just to clarify, the reason for the function above is that we definitely need headers in the case of multiple pages of results (Recurly limits to 200 per call and will not automatically fetch all results except in the case of the Recurly_PlanList::get();) . Additionally, with commerce stuff I need the full xml payload and statusCode a lot of times, and this is not possible via their SDK.