Documentation Improvement

Happy to accept any contributions towards documentation.

Although I will state this module has nothing to do with Authorize.net (I don't even use it so can't really help with documenting its features - leaving it up to people using that gateway).

The goal of this module is to provide an API between ubercart and the recurring features in payment gateways, the target audience of this module is more developers then end user who can implement the recurring API in their payment gateway modules.

The only reason we are shipping Auth.net code is its impossible to get gateway specific code committed to ubercart where it belongs in its own module.

e.g see #781720: Refactor the Paypal WPS IPN code, which was posted over 4 months ago and was an attempt to try and remove a large chunk of paypal code from this module to ubercarts paypal payment gateway. I would prefer to not encourage people to think that any payment gateway code will end up in this module, it is only there because we can't get the code into ubercart where the payment gateway code should actually live.

Its possible I may have read your original post incorrectly, but I took it to mean you were wanting documentation related to working with specific gateway, ie: when its best to use what. Most people don't have a lot of choices on gateways and need to use the gateways that exist in their own country, which is why I want to avoid suggesting this module is about supporting any specific gateway (which I can never do) and keep its focus on the core recurring functionality.

If people would like to document their experience with particular gateways thats great but I can't offer to do this when I don't use Auth.net or Paypal in any active projects, I use other gateways.

But always happy to accept documentation, as a developer working on this it's hard to know what documentation is required, so often documentation from users like yourself is more useful then what I might think is useful.

If you would like to make suggestions for the README, then that is probably best done as patches

I'll take a stab at this. I need to figure it out for a client anyway. :)

Tossed a stub page at http://drupal.org/handbook/modules/uc_recurring since it's much easier to edit a node than to pass README.txt patches around. :)

Here are screenshots for the UC Recurring Order module:

As far as I can tell, the point of it is to give the *user* control over how frequently recurring billing happens. I'm not quite sure of the use case here. I guess if you wanted to order the same socks every 6 months or something.

OK, have fleshed out http://drupal.org/handbook/modules/uc_recurring enough so that it's probably ready for review. It includes a tutorial on how to use the module in a basic way. Would love a look-over for accuracy and whatnot.

I do not use Authorize.net, so I don't know how to respond to the OP's questions, but hopefully he can figure it out and add it to the page. :)

(I haven't in-lined the screenshots yet because doing so moves the input format to a "special" one that not everyone can edit. I'll do so once the page is more-or-less complete.)

Awesome stuff on adding the documentation!!!

The screenshot above is from alpha4, in the current -dev this has changed slightly, for example you can configure those recurring intervals. The uc_recurring_order module is about making the entire order re-occur, so you can have your shopping order automatically placed for you every two weeks :)

One major change in the current -dev is that there is the addition of another module uc_recurring_products, meaning uc_recurring really does nothings itself, its just a core/API for these other modules like uc_recurring_products and uc_recurring_orders, which add a recurring payment to individual products (like a site subscription) or duplicate entire orders (e.g. office stationary/printing order)

Hopefully that help explain some of the pieces that might be causing some confusion.

Ah! Good to know. I'll update to -dev and adjust.

Thanks for the review!

Webchick, thanks very much for working on this. If you are working on it further, adding clarification for the sub-modules would be most helpful. The role of of the hosted sub-module etc. is a bit confusing. I think further clarification on some of the settings would be useful too. The enabled triggered renewals toggle, for example, is not quite clear.

I think where this module is design for use with a variety of payment processing methods and it isn't often clear what module is handle what part, understanding the settings and sub-modules is confusing in knowing how to apply to use of a specific payment processing method.

@WebNewCastle - there are two type of payment gateways ones that handle everything about the recurring payments and other that just store the credit card details for you and allows uc_recurring to trigger payments at anytime. This is how uc_recurring works for gateways that it looks after, when its due it attempt to charge the credit card on a cron run (that option just allows you to disable this from happening - good idea if you are running a testing site where you don't want payments actually attempted).

For gateways with limited functionality like Paypal where they don't allow you to control when payments occur, this feature will have no effect. The payments will happen at their end whether you like it or not.

@webchick - now that you have change the input format of that documentation page. There is no way for me to edit it or update as things change in this module.

Is it easier for me to try and get access to a role with permission to edit a page or could we divide up the page and put the tutorial part on its own page?

I just gave you "documentation maintainer" privileges so you should be able to edit it now! Use your new powers for good, not evil. ;)

webchick, looks good... just 1 suggestion with step 9:

To test that recurring billing is working, ensure your test user has "view own orders" permission. Set your system clock to 1+ month ahead and run cron.php. Now, if you view your list of orders from My account→Orders, you should see two charges, each a month apart. 

instead of resetting your system clock (this option has global system consequences) how about simply updating the table value uc_recurring_users.next_charge datetime stamp to be some time in the past (or whenever you want the hook_renew() to be called). beats waiting, say, a month for testing results and any unintended consequences for the system clock setting... even though the trade off is that transaction records aren't going to be dated quite how you wanted.

cheers, jay

@jaypark, you are a lifesaver! Your method worked perfectly! Thank you!

I am closing this issue, since it's for a Drupal version no longer supported.