Child pages
  • [in-commerce] Reoccurring orders
Skip to end of metadata
Go to start of metadata

Imported From: http://groups.google.com/group/in-portal-dev/browse_thread/thread/f01ad53dbba3927a#

In In-Commerce we have such term as reoccurring orders. Here are steps to start using it:

  1. create a product of subscription type in Admin Console and on "Access & Pricing" tab check "Recurring Billing" checkbox (db field: Products.IsRecurringBilling)
  2. then, when user buys that product that reoccurring mark will be placed in his order and next charge time will be automatically set (based on subscription interval chosen at time of product adding to cart on it's detail page)
  3. then this order needs to be processed & charged by website administration to have "processed" (instead of "pending" status)

Then scheduled task in cron will periodically check for orders, who are processed, but have next charge time and: 

  • clone order
  • set it's status to Pending
  • set next charge date to next month (or whatever subscription interval is)
  • charge order, that will make it's status to Processed

This way order is cloned for each payment and In-Commerce keeps track when to do next charge.
User can cancel reoccurring charging at any time while viewing cloned order details from "My Orders" page on Front-End.

However these days payment gateways become clever enough to do reoccurring charging themselves and only report charged/failed status back to In-Commerce. This feature is called "subscriptions".
Sadly, but In-Commerce absolutely doesn't support this feature.

Here is how I see it implemented:

  1. add "SubscriptionProcessing = {None, Gateway, In-Commerce}" parameter to each payment gateway integration class
  2. only clone orders for charging (see above) if payment gateway, associated with payment type specified in order has "SubscriptionProcessing = In-Commerce" setting
  3. on order preview step during checkout we add some extra fields to create subscription on payment gateway side (instead of single payment) if  payment gateway associated with payment type from current order has "SubscriptionProcessing = Gateway" setting and user brough subscription with "Recurring Billing" checkbox set

Once order is approved payment gateway will automatically start charging user on a regular basis. Once charge happens (or fails) we'll receive notification to same /modules/in-commerce/gw_notify.php script and clone order (see above), but set it to processed right away so no extra charge will happen. 

P.S.
I saw some PayPal subscription handling code pieces in In-Commerce but database columns mentioned in code were not present in database and tags created for same purpose wasn't used anywhere too. Surely these are pieces of some old customization that are left without being noticed for a long time.

Related Tasks

MINC-99 - Getting issue details... STATUS

3 Comments

  1. Quite interesting observations Alex!

    Looks like you've been checking on very deep of Order processing if you
    noticed those half-customized fields we have there :)

    I think we can have this idea implemented sometime in a near future (5.3.0
    perhaps) so let's create a task so this doesn't get lost here.

    Cheers!

    DA

  2. I was curious how In-Commerce, which creates orders on it's own could work
    with PayPal subscriptions, where subscriptions are created on PayPal
    instead. I suspected, that behavior could result in double-charging of
    user, who subscribed to a group.

    Also payment gateway classes, that we have in In-Commerce are impossible to
    extend in Custom module and as a result every change needs to be made right
    into In-Commerce code, which might be overwritten during upgrade.

    On Fri, Jul 6, 2012 at 8:22 AM, Dmitry A. <dandre...@gmail.com> wrote:
    > Quite interesting observations Alex!

    > Looks like you've been checking on very deep of Order processing if you
    > noticed those half-customized fields we have there :)

    > I think we can have this idea implemented sometime in a near future (5.3.0
    > perhaps) so let's create a task so this doesn't get lost here.

    > Cheers!

    > DA

  3. Task:

    MINC-99 - Getting issue details... STATUS