Specification for changes to E-commerce (recurring products, role assignments and user account provisions)

I have a few comments.

Notes: From now on I will call subscriptions recurring payments. That is to say, a product that is paid for by the day/month/year and has to be renewed is a recurring payment.

Addition of roles should be called role membership as per the draft module that has been made.

The first job should be to remove any trace of roles and recurring payments from the core. As per Gordon’s comments, this should include the database tables as well as code. I would like to see a working copy of ecommerce tested and working before any more work starts.

Recurring Payments

I like the proposed changes. I would like to see an api for recurring payments that include ‘on expire’, ‘on renew’ and ‘on first purchase’ (or something like that). I would also like to see functions that return the time until the product expires (this could be used with a cron hook to send emails).

A feature that would extend the payment time from the expire date is important too. If a site offers a product by the year and a renewal is paid a month before it expires, the renewal payment needs to extend the expiration date a year from the last expiration date.

Ec_actions.modulem

I would like to see a module that works in the same way as the action module does for the rest of Drupal. It would take every event hook (‘on payment complete’, ‘on checkout’ and the new ‘on expire’ etc) and add actions from there. Maybe it could work with the actions module.

I came up with this idea after I made a site where members pay to submit extracts from books and publishers can read the book extract and contact the writer. I wanted to have the writer pay for a role, but when the payment expired unpublish all the nodes (of a type) and place them in a ‘writer demoted’ role. I wanted to do something like this:

[product page]
-[actions]
On payment complete:
-add to role: writer

on renew
send email

on expire
-remove from role: writer
-add to role: writer demoted
change nodes: unpublish nodes of type: book

Have a look at the actions and workflow modules for an idea of what I am talking about. I don’t think that ecommerce should provide all these options, but an api to handle this would be great! I think this should be one of the core modules.

Role membership

If the above ec_actions is agreed on and made, this module should be very simple. It will be something like the store_change_role function in the store module at the moment, only exposed to the ec_actions module. It wouldn’t need to deal with any events directly because ec_actions would.

User accounts

Again, I think this should be independent of the other modules, as there are many cases where you would not want a user account to be made. This could also be part of ec_actions.

I think the user should be able to log in before the payment is complete, with a lesser role like ‘[role name] pending’. This could allow them to get to the ‘my orders’ page so they can pay for the account at any time after (if the payment gateway crashes out, the user will be left without an active account an unable to use the username they just tried). All the registration logic should be dome by the user.module.

Sammy, I am interested to know how much of the work in the pdf you are going to do. I was planning on removing the code from the core myself, but I have no problems if you or anyone else wants to do it! I would be willing to take on some parts of the changes, so maybe we should start assigning tasks?

Sammy and Sime,
Sammy, thank you very much for taking the time to write this detailed spec.
Sime, I have a use case just like yours and so your structure for unpublishing will work very well for me.

My comment is about the payment gateway.
Sammy is only planning to implement Paypal.
Now, Paypal does not accept credit cards for recurring payments, so this will only sign up users who have a paypal account. I think this will be a major deterrent.

I am looking into installing the authorize.net module so that I can receive recurring payments via credit cards. How easy or hard will it be to integrate this? With authorize.net, I have the option to not store any credit card data (so short of security alerts like the one we received when the data was accidentally stored). Sammy, would you consider that, or do you think the possible security holes in Drupal would still pose too much of a risk?

Hey Sammy

This is a great document, thanks for sharing.

Some comments after reading the PDF specs (a bit late, but better than never).

• Paypal Subscriptions is the most convenient way for site owners (provided it is available in their country). The advantages are : no storage of credit cards needed, no need for SSL, no gateway fees, no merchant account, and best of all, customers do not have to take an action to renew.

• Payment by cheque is needed, since some like to pay that way. We can use the COD module for this and create the transaction manually, or the user can create it themselves.

• It is OK to ask customers to create accounts before purchasing. This ties their ID with the transaction and hence they get the role.

• Page 7 point 2 for account creation. Delayed account signup does happen in paypal_subscriptions.module by using the email address, but that is because it is sent in the IPN. I like the idea of an email with a link. Logintoboggan is a good example of this. Of course, if the customer already has an account, we can skip this part.

• Page 7 point 3. Better use "user" followed by the next sequence for the user ID rather than random characters. This will be guaranteed to be unique, and match the uid.

• Where will the expiry timestamp be stored? Will it be per user, per transaction or per product? I mean it all is determined initially from the product, but upon payment, the time remaining is known, and we can just store the timestamp associated with the user somewhere. We can have a uid, txnid, timestamp. txnid will tell us what the product is and hence what the role is. The timestamp makes it easy for cron to expire the role. Issues arise when users have more than one transaction for the same product (one from last month and one from now, the SQL becomes complicated and potentially "heavy" on the system. Should we just denormalize and store uid, rid, timestamp?

• For trial purchases (free trial), there can be a special product with a lesser period (e.g. one week vs. the normal month), and price is 0.00. Users are only allowed to purchase this once (but they can sign up as another user and then enjoy it for another week, and so on ...)

• I have a client who can use this functionality, but the time frame is 6-8 weeks for delivery, and hence has to be on 4.7 (can't wait for 4.8/5.0). If this is not ready in that time frame, I will write a custom solution to meet their deadline. If there is a way to get it before then, I can co-fund the project (once we finalize the deal with the client). Contact me via the contact form or at 2bits.com for further discussions.

Coupet's comments are great, but can be phased in future releases. Rather than waiting for a long time to get it all done, better take one bite of the elephant at a time.

Howdy,

i am a bit reluctant to post in the "cave of giants", since i am no coder at all.

Still i am following the Role Membership discussion on Drupal.org since some time, so why not step up and stick my (inexpensive and easily trascurable ;) two lines from a user point of view?

• About role expiration: when roles are stripped from users upon expiration, to which lower role are they demoted? Just to the "authenticated user" one?
  If this is the case, it would be nice to have a default "demoted" role specificable by the administrator. This is usefull in sites where users roles are separated from advertisers roles, to prevent demoted users to end-up as generic authenticated users.

• About "Trial purchases allowing different (e.g. introductory) pricing " (#14): i would allow also different pricing (e.g discounted) for recurring purchases if possible, so to incentivate users to renew.
• Admin reports: maybe this is more of an optional suited for 4.8, but an "admin report" panel would be desirable, showing resuming and statistic data (e.g. Total subscribers per role, New subscribers this week/Month, Suspended subscribers)
• Possible conflicts: since the main use of this mod is to block access at some levels, someone in a thread (can't remember who or where) pointed out that Role Membership shouldn't conflict with other node access modules as Organic Groups, TAC, CAC, and similars. Carefull, i don't know what i am talking about here!

Pardon if this post lacks depth of vision or knowledge, but if there is something to say is better to do it now here. Big Thank You to all the people involved and to Sammys for the thoughtful document!

Marco
(Drupal.org: kiteatlas)

There's some overlap with this one:
http://drupal.org/node/73727#comment-138769 which implements Paypal subscriptions.

You'll find the new file here.

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

Dear all consultants/execs,

I want to ask for your help here. Sammy Specs from Synerger will be working on this important functionality of e-commerce, and I will be helping him with some funds.

However, I cannot contribute as much $$$ as I wish. I would like to kindly ask everyone interested/benefited to pledge a contribution in order to reach 100% of the budget. More little contributions of more people will make this module better, will make the community stronger and will make our businesses grow bigger!

Please contact me or Sammy for more details, thanks very much