move subscriptions to own module

If your saying that subscriptions would be a separate checkout and payment process in a separate module I believe I'm going to have to disagree as I am working on a website that will be offering both and I don't think we'll be wanting them to have to checkout through separate processes.

I am just about to create the ability to have subscriptions. I had just decided to go with ecommerce module as I need a way to accept a gateway that doesnt have any payment module written for it yet: cybersource.

I had decided to use ecommerce because I needed address info also in the subscription model.

I am about to very very actively plunge into this, so would love to be working on something people will find use ful in the future or are currently working on...

-

excellent idea, will allow for easier maintenance and feature enhancements

Oh, then right on. I agree 100% :)

Will this task be implemented in 4.7 port release?

Is anyone actively working on this?

There are two distinct features to the current code:

1. recurring payments and reminders
2. role addition via product purchase

The feature I am most interested is a membership product were the user receives an additional role for a specified time period. At the end of the subscription time period, the user role is removed or replaced with a different specified role. I am currently working on a site that would like the user role 'current member' to be added at the time of purchase and then the role 'former member' applied at the end of the time period.

• A default product setting could be specified (i.e. 6 months from purchase, add role 'current', add role 'former', end period remove role 'current')
• The time period could be different for each product. (e.g. Get 1 year for the price of 9 months)
• The role assignments should be configurable for each product. (premium and/or different content)

I am planning on building something like this for my own use. If you have requests you can add them here. (Although, I am not promising anything... )

wpd,

presently, nobody is working on it!

If you decide to code it, then I suggest moving the code to a new module as gordon suggested, with existing functionality and the new ones that you require.

Further features can be added later.

An idea:
-The ability to buy a membership should not be restricted to upgrading the account that purchases the product.
-By uncoupling the user/the purchase/and the role upgrade this allows for gift subscriptions, etc.

I will try to work on this task over the weekend.

Orgedude does not have his contact form enabled.

I am planning on everything being product based with some global configuration settings.

Products & Categories
--------------------------
One-time products are charged just once on purchase.

Recurring products are charged on purchase, along with any setup costs, and are also billed on the schedule selected by the user from the defined list of available schedules: weekly, monthly, quarterly, semi-annually, annual, and bi-yearly. Recurring products can be configured to allow/disallow user cancellations and billing schedule changes (upgrades/downgrades).

Trial products allow a special introductory rate for a recurring product, after which the normal rates apply.

Each product can be assigned a tiered pricing structure based on the user’s group access. So group A gets the product for $10/month + $5/setup fee, while group B gets the same product for $5/month + free setup.

Each product can be assigned unlimited attributes to collect information from the user and/or charge for optional services. The pricing for attributes can also be tiered in the same fashion as products can.

Products can have associations that do any of the following:

1. Require that a user have purchased a specific product prior to purchasing the current product.
2. Grant free access to another product with the purchase of this product.
3. Grant access to a group or groups for a specified period of time with the purchase of this product.

Products can be defined to create a discount for the user when purchased.

Invoicing and Autobilling
----------------------------
Generate all recurring charges for subscriptions, trials, etc., including:

* Invoice Generation Notice
* Payment Due / Overdue Notice
* Service Cancellation / Suspension Notice
* Payment Decline Notice
* Payment Received Notice

i guess this task is (was?) carried on by ogredude here.
ae2000 hired him as developer, and is (was?) coordinating this and collecting donations to carry on the job.

if what you guys are talking about different features, than pardon me, but things about ecommerce and subscriptions are still very scattered/confusing...

The link you referred to is a seperate task (http://drupal.org/node/51181). They are working on 4.6 and it works without the ecommerce module.
This work is for 4.7 (ecommerce) and is take code that is scattered across several modules and refactor it into a new module.
There are a couple of other differences:
-this is for any payment form (not paypal specific)
-the membership/role changing features do not have to be associated with a recurring payment

Anyway, I am still working on it when I can find the time. I think I have identified most of the code and moved it into to new modules. My current plan is to not add any functionality until the new modules are separate and in CVS.

Wpd, just knew some news about the 'other' paypal subscriptions module. It looks like the current developer couldn't see a way around the email address problem and the timezone problem, so they may shift the focus over to 4.7 and ecommerce module framework instead of 4.6 and paypal framework module.
Any comment or feature request can be left at drupalecommerce.com here.
Also, anyone willing to donate for the cause can contact ae2005.

Thank you

Does anyone know what the db field ec_product.auto_charge is for?
I can find a reference to it. I just want make sure I am not leaving anything out of the reccuring module.

My guess would be that it would imply a reacurring payment. More importantly that we are to automatically try to charge them. This may not be true for all reacurring payments as some may just warn the user or something. That would be my take but like I said its just a guess.

That is my guess as well, but as far as I can tell it is never set or used.

I can help with testing with ready.

I've done a little work on it. Mail me.

So...is anyone working on this? I need to sell a role on a site, so should I make my own module (I don't think it will be that hard with the ecommerce and user apis) or wait for someone to do this?

Can I help anyone?

sym,

I strongly suggest giving it a try!, also given your recent experience with auction module, this might be a breeze. gordon suggested it, wpd did some work but never published. I have contacted smoothstr as suggested but no response.

we do not want to forget about this one.

Darly

I've never touched the auction module....

If I make a module that will allow you to make a new product, selet the role that the user is assigned and then assign it on payment, would that do it? I think the apis would make that easy. I will give it a go, and post it for someone else to polish.

"also given your recent experience with auction module, this might be a breeze"

sym <> sime
:-)

Agree, excellent knowledge of the new APIs is the key, also initially a module with core functionality as described should be perfect, further enhancements as needed can be implemented later.

understand and sorry in referenece to sym <> sime !

I talked to gordon about this and he mentioned it was probably too late to make in the 4.7 release. He wanted to hold of the core changes till after 4.7 release(very soon) and then once they're sorted out backport. I tend to agree as they will probably require reworking a lot of code across a lot of modules.

That doesn't mean we can't get something useable started. I'm also interested in working on this, mainly from the sense of getting it out of core, but also in getting the module working as I'll be wanting something like this eventually. I haven't looked into the funtionality we'll be wanting to much but you're welcome to contact me offlist.

Right, I have made a module that allows me to make a sellable role. When the payment is complete the role selected in the product is assigned to the user. This is working fine, but I now need to think about other options.

For example:

How to I check if the payment cycle has expired (if using it)?
I want to un-publish all of the users posts once they are demoted, and republish them after they buy another year. (I think this is easy)
Do the users have to wait until the last cycle runs out before they can buy another one? Or can they just buy it again a week before it runs out and have it topped up? Also, could they buy 2 years or more at the same time?

I want to start removing the old code from the core modules, but I don’t think I know enough about it at the moment to do so. Would someone be willing to go though it with me (over IM/IRC) so we can look at what’s needed and what should be a new module?

I think the recurring payment could be a module in itself, but would that start to dilute the core too much?

I’m looking for guidance more than tech knowledge here.

I will be working on this over the weekend, and I would really like to have something up and running by Monday, is anyone about over the weekend for me to talk to?

Thanks :)

Recurring products are billed on the schedule selected by the user from the defined list of available schedules: weekly, monthly, quarterly, semi-annually, annual, and bi-yearly.

Recurring products can be configured to allow/disallow user cancellations and billing schedule changes (upgrades/downgrades).

APIs are the core in Ecommerce, Non-API code could be rearranged to allow for modularity and easier future enhancements. Agree, code unique to Recurring products should be moved to new module.

Notes:
Scheduler module can Publish/Unpublish nodes, but it is not automated.
Actions module allows the configuration of Drupal actions.

sym,
just wanted to make sure you knew about the mailing list and the irc channel since you wrote about getting a hold of someone
http://www.drupalecommerce.com/drupal_ecommerce

thanks so much for working on it

hehe, thanks!

We are actually the same person! Sym = screen name Simon Roe = real name.

Thanks for letting me know though, I will follow up tomorrow (UK time)

I'm confused. According to this statement in the thread some role by product purchase features already exist:

There are two distinct features to the current code:

1. recurring payments and reminders
2. role addition via product purchase

Where are these options within the normal ecommerce module?
Also, Sym, you say you have some working code that does this. Is your module available?

At the moment, I think that if recurring payments are activated, then the role is granted automaticlly (settings under product settings?)

I have made a module that will allow you to buy in to a role, but that not the same as being added to a role when you buy any product. You're welcome to look at it, but I've not tested it for a while so it might not work with CVS/4.7 any more.

Let me know if you find any problems - I've not made an install file for it, so you'll have to add the tables yourself...sorry, I'll get to this soon.

@ sym, does the module provide option to assign duration of role assignment?

also, tables referenced are not attached!

No it doesn't - the point being that the two shoudn't be tied. If you want recurring payments then there should be another module that will deal with it for any product type IMHO.

I did say the tables wern't attached - I wasn't really ready to post it, but jasonwhat asked to see some code. I though this might be a starting point for him.

I will package it up with an install after the weekend.

I tried your module and it is an excellent start. This is something I am interested in working on so I will keep an eye on this thread. I am looking for a system where people can buy different levels of advertising on a site. With this module they can but a role then I will have to develop access rules so for level 1 they can post 5 adds, level 2 - 3 adds etc. This module seems like a good basis for that system.

Thanks for your work so far.
gpdinoz

To get default value working Line 45 should be

 '#default_value' => $node->rid,

gpdinoz

@sym, interesting idea, then there will be a need to assign a schedule and automate process

1. create a module that fires an action instance at appropriate times when you want. (requires Actions module)

Schedule or Scheduler are 2 modules that could be used to assign schedule.

just for you guys to know, a list of desirable functions for ecommerce paid role subscriptions (gathered from different posts about this subject on Drupal forum) has been posted at http://www.drupalecommerce.com/node/734

cheers

Sym, This looks to be just what I need, thanks. I have installed your module and put a table {ec_product_role} (nid, rid) into the database. It seems to work, at least doesn't give any errors to press. I didn't get any roles in my select box and saw there was a TODO so I put this in, which did what I thought ought to be happening. The default value doesn't pick up the previous value which needs fixing.

		$result = db_query('SELECT * from {role}');
		$options = array();
		while($data = db_fetch_object($result)) {
			$options[$data->rid] = $data->name;
		}

I will try buying some roles and see if it works.

Paddy

I think we're all on the right track here. My inital idea was to clone the generic product module, but add in the option to specify which role to elevate the user to once they've purchased that subscription. I'm working on a site where we want to sell monthly and yearly subscriptions to acces content, but also have a "premium" level which gives you access to additional content and discounts when buying regular items.

Thanks for the help with the default vaule!

After writing that module I have changed tack a bit. I think we should have a way of adding "actions" to any product, and then doing something when the state changes.

Any module could make an action and it would show on any product page.

For example, simplenews could have one that would allow you to sign someone up to a newsletter when they buy a product with it selected. the same with roles and subscriptions. That way to make a role subscription you would create any sort of product (generic would fit best), write your text and select the actions that sute you:

on payment: Assign role: "paid user"
on payment: Subscribe to newsletter: "Members news"
on payment: start recurring payment: 30 days
on expire: remove role: "paid user:
on expire: remove newsletter: "Members news"

I would like to hear some feedback on this. I've not written any code yet, but I will get on it soon if people like it. I know that all this can be done with the APIs at the moment, but making a fieldset on every product type would change the way ecommerce works quite a lot I think.

for Bioneers project we need to allow the store to send an email to
the customer whenever the status of one of their purchases changes. I
think there is some statuses that doesn't need email notifications.

As I saw in ecommerce transactions, there are two types of statuses.

1- Workflow:
This type follow a rigid receive->invoice->ship flow. Currently the
workflow steps are:

- transaction received: this is the stage a transaction is set to when
the customer places the order. This sends an email to the customer
confirming the order was received.

- invoiced: when store admins click in "print invoice" action, the
transaction is updated to "invoiced". This action currently doesn't
send any email to the customer.

- shipped: clicking in "shipping notify" will display a form allowing
store admins to customize the message that will be sent to the
customer (e.g. adding a shipping code to allow customers to track your
orders), plus this changes the workflow status to "shipped".

- awaiting customer response: this can be used if we send an email to
the customer regarding the order, and we need to wait for a reply
before continuing the process. This doesn't send any email to the
customer, because it assumes that we already did that. I'd suggest an
"ask customer" action to be added to the transaction list to allow
store admins to quick send an email to ask the customer something.

- canceled: doesn't send emails to the customer. We can add another
action like "cancel transaction" to warn customers that his order have
been canceled.

- completed: we need to set this if we know that the order was
successfully sent to the customer. Currently doesn't send any emails.

2- Payment Status:
Not sure if there is emails being sent that is directly relationed to
that. This might depends on the payment type. The options are:

- pending

- completed

- failed

- denied

- refunded

- canceled

I need to know if the workflow emails with those who I've suggested
are sufficient. And if you agreed that this can be added to the
ecommerce package.

Thanks,

Henrique Recidive
CivicSpace Labs

I think it's good to call this "paid membership" module and not "subscriptions." There are already (1) subscription and (2) subscriptionS modules, for email subscriptions to topics. If we call this subscriptions also it'll get very confusing.

definitely good idea! that was pretty confusing to figure out

Just quoting a reply on a forum thread that might be usefull:

I have a website with microsoft frontpage - wallstreetwindow.com - and have two subscription options using paypal. Payal ineracts with an apache script on my site which adds or deletes the people in my mysql database as they subscribe or unsusubcribe. Seems like someone could just do the same thing with drupal - have paypal go to a script, which changes the options in the database drupal is using for the members/subscibers?

Here is a working module called "role_membership" based on the module above.

I tidied up the code, added a settings page that allows changing the description, and a .install file to create the database table.

It works well with 4.7.

Thank you very much for submitting this. I installed it into the modules directory. (Should I have installed it into contrib for ecomm?)

I got this warning.

user warning: Table 'mysitename_drupal.ec_product_role' doesn't exist query: INSERT INTO ec_product_role (nid, rid) VALUES (1070, 5) in /home/mysitename/public_html/drupalecommerce/includes/database.mysql.inc on line 120.
user warning: Table 'mysitename_drupal.ec_product_role' doesn't exist query: UPDATE ec_product_role SET rid = 5 WHERE nid = 1070 in /home/mysitename/public_html/drupalecommerce/includes/database.mysql.inc on line 120.
user warning: Table 'mysitename_drupal.ec_product_role' doesn't exist query: SELECT * FROM ec_product_role WHERE nid = 1070 in /home/mysitename/public_html/drupalecommerce/includes/database.mysql.inc on line 120.

@edrupalec: the .install file failed for me as well, try running the database query manually from phpMyAdmin.

Also be sure you have installed the required ecommerce modules:
. cart
. payment
. product
. shipping
. store

@kbahey: you are the man, many of us non-coders were waiting for this!

I got the following error when i submit a new role product:

warning: in_array(): Wrong datatype for second argument in /home/kiteatla/public_html/drupal/modules/ecommerce/product/product.module on line 703.

Too bad. What happened is that I had the .install file working fine, and then as I was bundling for upload, it got accidentally overwritten, so I coded another one, but it was untested.

The client is not using this after all, and going for a Paypal oriented solution. Going this route with him.

Try the attached version.

(Another thing, I have not tested if this will expire roles properly or not. Can someone test that?)

great, that warning (#53) vanished with above version!

BUG: if i go to administer >> settings >> content types >> product i do NOT see the roles_membership product type in the 'configure product types' fieldset at the top of the page...

(i happened in this trying to disable comments for role_membership content-type, any other way to solve this?!)

thank you

I am not using this module anymore (not even ecommerce) since the client is asking for an alternative solution that will not use ecommerce (Paypal Membership).

If I recall correctly, the settings for the module are under the store -> settings menu.

The actual settings are when you do create content -> product then you should be able to see a "Role Membership" product.

kbahey, do you know if it is possible to run Paypal membership along side ecommerce? It has always been presumed that they conflict due to IPN's returning to the same place (or something) but perhaps there is a quick one-line fix to run them side by side. ecommerce can be used for intergration with userpoints, and Paypal membership can be used for role assignment.

which module is supposed to create ec_product_role? Is there a module that needs to be patched to create this field?

@drupalec

kbahey, do you know if it is possible to run Paypal membership along side ecommerce? It has always been presumed that they conflict due to IPN's returning to the same place (or something) but perhaps there is a quick one-line fix to run them side by side. ecommerce can be used for intergration with userpoints, and Paypal membership can be used for role assignment.

"Paypal membership" is still under development.
But yes, they would conflict if you enable the paypal module and the paypal_framework module at the same time. Even if you create two unique IPNs (e.g. paypal/ipn and paypalfwk/ipn), your Paypal account can only be pointed to one IPN URL at any time.

The issue is that ecommerce has no way of using Paypal subscriptions which do automated renewal.

@maric
which module is supposed to create ec_product_role? Is there a module that needs to be patched to create this field?

When you enable the role_membership module, there is an .install file that goes with it that should create the table.

Thank you. The new .install still didn't work for me. I had to use a very stripped down one .mysql file.

CREATE TABLE ec_product_role (
nid int NOT NULL ,
rid int NOT NULL ,
PRIMARY KEY (nid)
) /*!40100 DEFAULT CHARACTER SET utf8 */
;

And then I got these 2 errors. However, to pay, I am using the userpoints module. So it could be an issue with the (extremely useful) userpoints module.

user warning: Duplicate entry '9-shipping-0' for key 1 query: INSERT INTO ec_transaction_misc (txnid, type, vid, description, weight) VALUES('9', 'shipping', '0', 'Shipping', '9') in /home/public_html/drupalecommerce/includes/database.mysql.inc on line 120.
user warning: Duplicate entry '1-5' for key 1 query: INSERT INTO users_roles (uid, rid) VALUES (1, 5) in /home/public_html/drupalecommerce/includes/database.mysql.inc on line 120.

Thank you.

The good news is that despite the warnings/errors, the buyer was promoted to the correct role. Tomorrow I can see if the person will be correctly demoted.

More good news. Multiple roles seems to be working correctly. Also, this works even when address module is disabled.

Now if we can get rid of the duplicate error, have a "Your transaction was sucessful" type message in place of the error message, (and assuming demotion and payment with real money work) then the module is done!

Thank you.

user warning: Duplicate entry '9-shipping-0' for key 1 query: INSERT INTO ec_transaction_misc (txnid, type, vid, description, weight) VALUES('9', 'shipping', '0', 'Shipping', '9') in /home/public_html/drupalecommerce/includes/database.mysql.inc on line 120.

This one is not from the role_membership module.

user warning: Duplicate entry '1-5' for key 1 query: INSERT INTO users_roles (uid, rid) VALUES (1, 5) in /home/public_html/drupalecommerce/includes/database.mysql.inc on line 120.

This one is from that module, but maybe the users already had that role before the transaction?

Now if we can get rid of the duplicate error, have a "Your transaction was sucessful" type message in place of the error message, (and assuming demotion and payment with real money work) then the module is done!

The message is easy to do, but remember that the user may not come back immediately to the site ... An email is better.

I just checked. The user did not have the role before. I did it 2 times. Thank you. But the role does upgrade correctly.

With address disabled, the notification email says "Dear ,".

30/06 scoonz wrote:

I have added cron hook to role_membership module in order to remove expired subscriptions roles. Only reccuring subscriptions roles are removed, non-reccuring subscriptions are considered persistant. Please, submit it to appropriate place.

please find attached .zip file.

thx

You are doing great work, however I was thinking about doing something different.

I think we should make a recurring payments module that could be used on ANY product. I also want to make a role module that can also be used on any product.

I am finishing a project at the moment so I can't do anything, but next week I will start working on these ideas so you can get an idea of what I am talking about.

sym is right, long term. I still see value in what we are doing though, at least as a short term solution.

kiteatlas, the expiry cron will be very heavy on a large database due to many joins in it. It is better to have a variable that will prevent it to run at every cron invocation, and only once a day or so (parameter).

Also, another parameter is whether a warning email that has to be sent before the role expires, and how many days before it expires.

sym, your idea of recurring payments that apply to any product is just fantastic!

What needs to happen is this:

1. Remove the recurring payment logic from the payment.module to a more generic product.

2. The roles would not span all products, but would be product specific (i.e. each product can have a different role to be granted, like the role_membership.module that I attached earlier). The duration for this role is already per product, so that part is OK.

3. Roles should be expired based on the duration. This is already per transaction (and hence per product).

4. The final area would be for Paypal as a payment method to have more processing for subscriptions (check txn_type, and if it is subscr_payment then grant the role, if subscr_cancel or subscr_eot, then revoke the role).

This would mean that users can be granted roles instantly if they pay by credit card (for example), and when the payment status is moved to completed by the site admin when they get a cheque (using the COD module). It would also mean that automated renewals are possible via Paypal as well.

kbahey, the role_membership (paid_membership) module is now promoting correctly with Paypal sandbox. Tomorrow I'll see if it demotes correctly.

I think I know the source of the duplicate error. What role to promote to is set in 2 places. First, in admin--store--settings--recurring payments (there you can only set one role.) Secondly, when you create a product. I removed any choices from admin--store--settings--recurring payments. I also disabled userpoints. (I do hope to get userpoints working with ecommerce error-free eventually.) Then role_membership promoted correctly without returning any error messages.

@ sym in reference to comment #45

could also add:
on payment: Publish n CCK nodes for x days
on expire: UnPublish CCK nodes after x days

also as mentioned in #71, removing the recurring payment logic from the payment.module to a more generic product would greatly facilitate further development in subscription module.

kbahey, the role_membership (paid_membership) module is now promoting correctly with Paypal sandbox. Tomorrow I'll see if it demotes correctly.

What I meant is that it does proper Paypal Subscriptions, and not just payment via Paypal. With PP Subscriptions, the renewal is automatic and no action is needed from either the customer or the site owner. This is a major requirement for some sites since people forget to renew and sites lose revenue.

It will not demote. I have a patch to store.module and payment.module to streamline this more and hopefully expire things properly.

I think I know the source of the duplicate error. What role to promote to is set in 2 places. First, in admin--store--settings--recurring payments (there you can only set one role.)

I have that fixed too in my version. I will test more and then post the patches.

also as mentioned in #71, removing the recurring payment logic from the payment.module to a more generic product would greatly facilitate further development in subscription module.

In the patch I am developing, I removed the recurring payment from payment.module, and rely on it in role_membership.module only. However, it is not yet generic enough to add the role to any product.

Here is a version of role membership that should work with expiration correctly.

The trick is to let ecommerce do the role granting via its existing mechanism, which also does role revocation. You will not see duplicates any more.

This requires a patch to payment.module and store.module so as not to use global roles, and make them per product.

I would like to restrict this module to one item per cart, and a quantity of only 1. This paves the way for Paypal subscriptions using IPN, since they cannot be done with multiple products in the same checkout. I put in code for this in role_membership, but that hook is not firing properly.

And here is the patch, against 4.7.

It is hackish in nature, and therefore I don't expect it to be committed as is, but it does work for those who need this.

I missed what you are trying to say. Maybe because it is past midnight, and I have a parsing error.

Not sure what core here means: ecommerce core? Why replace core? And with what?

Thanks gordon for the clarification ...

Here is a version that makes sure that no quantity can be assigned for a role membership item.

It also prevents the user from adding more than one role membership item in the cart.

Now, the paypal module can be expanded to process Paypal Subscriptions payments ...

Here is also my modification of role_membership.
1. Quantity is considered as number paid billing cycles so that expiration date gets procrastinated (I wonder nobody requested this feature before), but this requires a patch for cart.module (included) in order to consider all reccuring payment products quatities are number of billing cycles.
2. If user is/was already subscribed to the certain subsciption while adding it to cart, it converts to renewal (prolonging expiration date). E.g. lets consider billing cycle = 1month. Then simply 'buying' the subscription in quantity of 3 and next day 'buying' the same subscription in quantity of 2 will make it expire only in 5 months.
3. Ofcourse, it removes the role when the subscription gets expired.

I am making a new module called 'recurring_payments' that will handle recurring payments for any product type. I hope to include a basic API that will include 'expire' and 'renew' cases that things like the role membership module should use. (I would like to unpublish all nodes made by someone who has just been demoted, but that should be done with a 'demote' hook in role membership I guess).

Anyway, my question is; what do people think about removing the is_recurring, price_interval, price_unit, price_cycle and auto_charge fields from the ec_product table in favor if a ec_recurring_payment table?

scoonz and sym both have good ideas. sym's goes well with a standalone module to replace what is in core ecommerce now.

One thing to take into account is Paypal subscriptions. This is the most convenient way to get automatic hands-off renewals for both the customer and the site owner. No one needs to do anything.

If the payment is via the paypal module and it is a recurring product, we can make it a subscription. What we need is to send the appropriate data to paypal and handle the txn_type having subscr_* in the IPN.

Sym, if you have code, pass it my way (use the contact/feedback form on 2bits.com), and I will see what I can do.

I don't have any working code yet, but it's coming.

I am very keen to stay within ecommerce and drupal for these modules. ecommerce is nice because it doesn't tie in to any 1 payment system. I don't use paypal and I have no plans to do so at all....therefore I would like to leave the payment up to ecommerce.

Thanks gordon.

The role_membership is mainly to allow "buy-a-role", and even that module wants the subscription to be external to it.

Regarding paypal subscriptions, I agree with you that subscriptions should not be tied into any payment form. This is one beauty of Drupal's ecommerce: its open nature.

Having said that, I have too many clients asking for subscriptions to be handled by Paypal since people forget to renew if reminded by email. This is why paypal_framework and paypal_subscriptions exist, but they leave a lot to be desired (e.g. if some people want to pay by cheque, there is no mechanism for that at all, while in ecommerce this could be handled by the COD module).

The best way of handling this is to incorporate the paypal subscriptions in the ec paypal module (or split this into two: paypal and paypal_subscription?), so when we get an IPN of the subscription (subscr_payment), we use the item_number as the txn id and renew the subscription. We can also act on subscr_cancel and subsc_eot (End or Term). Those who pay by credit card can continue to renew the way they want.

Thanks everyone for all the active development

Re #82 from sym, I would NOT want to unpublish nodes by people whose memberships have expired. However, having that as a configurable option would be nice.

Scenario 1: Say, it's a travel site. Someone subscribes for 3 months, writes some good pieces, and then let's their membership expire. I don't want their contributions to go away.

Scenario 2: Someone posts jobs. Their listings are only active while they are members.

If it's not configurable, I'd want scenario 1. I don't want to lose content.

I agree with sym's other ideas.

I agree with kbahey that it would be nice to have a paypal subscription (or paypal membership) module as long as it doesn't conflict with ecommerce.

Anyone interested in integrating this with Google Checkout?

Regarding unpublishing of content from those who do not renew the subscription, this is better handled as a hook. The hook fires at the event of unsibscribing, and then contrib modules can do what they want (e.g. unpublish articles, revoke roles, send email to the person, send emails to the site admin, ...etc.) This way it is a totally open architecture.

Regarding Google Checkout, it is currently a US only product, unlike Paypal.

kbahey, see my comment #45 for my thoughts on that. I think that recurring payment should be a module with some hooks in it (like 'on expire' 'on renew' etc) and role adding and anything else that might want to use recurring payment can do anything from there.

As mariun pointed out, there are many cases where one wouldn't want content unpublished, but in my case (a site where text is showcased after paying, and read by people in another role) I do would need it. Having a setting of the role payment module or even another simple module to do this would be the best option IMHO.

Great to see some progress on these long desired features. You've all had some great ideas and i'm very excited that we're going to finally have some decent support for roles and subscriptions.

As promised on the mailing list i've amended my specification document by adding some of the good feature requests noted in this task thread. I'm yet to go through Jeff Veit's document (34 pages!). I'm sure there is a large amount of good stuff in there too.

You'll find a link to the specification in the d.g.o thread dedicated to this. I'm looking forward to reviewing your modules. I'll most likely be the one ripping the old stuff out of core so keep me posted in IRC when something is ready (hopefully you'll check the specification to see that it matches first :).

--
Sammy Spets
Synerger Pty Ltd
http://www.synerger.com

Sammy's document is excellent. I want to encourage everyone to comment on the specs it details. (It's for 4.8, not 4.7)

Sammy is planning not to offer support for credit card payments, only via paypal (regular, not pro). I've heard paypal is terrible, because they can freeze your account at any time. I'm interested in using authorize.net for recurring payments. I've posted a question about that on the other thread.

Thanks to scoonz and kbahey for posting new versions. I'll try to test those today.

Here is a good list of payment gateways and whether they offer a recurring payment option. (Has anyone tried amember?)

http://www.amember.com/paysystems.php

It appears that authorize.net does not support recurring payments if the credit card is not stored (the authorize.net SIM option).

On the above list, these payment gateways do NOT store the credit card data but do support recurring payments: ccbill, chronopay, egspay, ipayment.de, paypal (not pro), standardpay, verotel, worldpay, yowcow. Drupal has modules for worldpay, and paypal only.

drupal has modules for:
COD
paypal
paypal pro
authorize.net
eway
exact
itransact
linkpoint
payflow
worldpay
and no doubt many more.

Making a payment module isn't all that hard, so you can extend it to include almost anything. Where did you get the idea that "Drupal has modules for worldpay, and paypal only."?

I meant of the list I gave of gateways that offer recurrent billing and does not store the credit card, Drupal only has modules for 2 of those.

Right now it looks like Verisign is my best option. It offers recurrent billing without storing the credit card. It's a well-known trusted brand (and is actually a subsidiary of paypal now.) It costs quite a bit less than the others. Verisign is sold under 2 names: payflow pro, and payflow link. CVS shows 4 dead files for payflow link, 4.6. There is a thread with a 4.7 prototype for the much more expensive payflow pro. Can I interest anyone in doing a 4.7 module for payflow link for recurrent membership billing? I don't know how to code. If it's very simple (basically doing a global replace on the authorize.net module where I replace authorize.net with the correct payflow link url) I can attempt something like that. Thank you.

I tried to install scoonz' 0.zip version. When I applied the patch to store.module, I got an error Hunk #1 failed.

Hmmm... I get "Hunk #1 succeeded at 1008 (offset 5 lines)" with the HEAD version of store.module.
Try simply locating line
$item['expires'] = strtotime($item['price_interval']. ' '.product_unit_nice_name($item['price_unit'], $item['price_interval']), time());

and replacing it with
$item['expires'] = strtotime(($item['price_interval']*$item['qty']). ' '.product_unit_nice_name($item['price_unit'], $item['price_interval']), time());

scoonz, thank you. I'm using the 4.7 version of store. When I tried to manually change the line, I seem to have introduced some sort of syntax error, because then the admin/module page won't load. But it will load if I remove store.module. Maybe I made a typo somewhere (that I can't find) or the 4.7 version is not compatible with the patch.

News hot off the press

New Drupal 4.7 module to allow paid subscriptions using PayPal - testers wanted

LeeMcL - July 14, 2006 - 09:12
I'm completing a Drupal 4.7 module to allow paid subscriptions using PayPal. I'm currently still testing against PayPal Sandbox and am looking for some volunteers to help complete testing. Also I've writen it to provide the features I need but it would be good if it was more comprehensive. So I would like to have input on features required.
I did have a look at various other solutions but none seemed both appropriate for my needs and known to work with 4.7
This module has been writen from scratch using only the documentation and examples available from PayPal. I should also point out that this is my first Drupal module - so there may be some inellegant code!
If anyone is interested and has the time to help out please post a followup to this article.
http://drupal.org/node/73727

This is being handled in the 4.7.x-3.x release series and most of the large changes are committed so any problems can be handled in separate issues from here.