In-Portal Issue Tracker

Welcome to the In-Portal Open Source CMS Issue Tracker! This is a central management / tracking tool for all types of tasks / issues / bugs for the In-Portal Project. Before reporting any issues, please make sure to read the Guide into Issue Tracker and How to Properly Test and Report Bugs!

Viewing Issue Advanced Details [ Jump to Notes ] [ Wiki ]

[ View Simple ] [ Issue History ] [ Print ]

Category

Type

Reproducibility

Date Submitted

Last Update

0001347

[In-Portal CMS] Refactoring

feature request

N/A

2012-07-10 11:20

Reporter

alex

View Status

public

Project Name

In-Commerce

Assigned To

Developer

Priority

normal

Resolution

open

Platform

Status

active

OS Version

ETA

none

Fixed in Version

Product Version

5.0.0

Target Version

Icebox

Product Build

Time Estimate

No estimate

Summary

0001347: Reoccurring orders API

Description

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.

Steps To Reproduce

Additional Information

Issue History
Date Modified	Username	Field	Change
2012-07-10 11:20	alex	New Issue
2012-07-10 11:20	alex	Reference	=> https://groups.google.com/d/topic/in-portal-dev/8BrVPbujkno/discussion
2012-07-10 11:20	alex	Change Log Message	=> Adds reoccurring payment automatic system
2012-07-10 11:20	alex	Estimate Points	=> 2

Relationships [ Relation Graph ] [ Dependency Graph ]