Paid Subscription content, and creating a module that can use as much of existing drupal functionality as possible

Intro

I am in the process of creating a subscription module for enabling drupal sites to set up paid subscriptions and then the user's can subscribe and post content which is enforced by the subscription rules.

There are 2 typical kinds of subscription sites, 1) Paid access and 2) Pay to Submit. Mine is the latter meaning that everyone can view the content for free but you have to pay to post your content. What the subscriber is paying for is visibility, marketing, maybe advertising as well.

Brief History

We first did this with searcy.com (now under different ownership) where we used lm_paypal to set up subscriptions for posting directory listings. It worked decently well but we couldn't really modify the subscriptions very easily, and paypal forces you to get a paypal account. But this is the concept I was to use.

Basic functionality

The basic idea is that you subscribe, and then can submit content. There are rules that enforce visibility, so premium levels have better visibility and maybe more fields.

Core Modules

In every drupal site I rely on these 2 crucial modules and for subscription sites it would be no different:
1) CCK
2) Views

Additional Modules

My thought is to set up roles and for those roles to be granted/removed based on their subscription.

1) CCK Field Permissions? - for granting access to certain fields based on your role
2) Maybe some form of access control?
3) Quota by role - I think this should accomplish allowing certain roles to submit only a certain number of content

Payment

I would like to use Authorize.net ARB as the backend payment module but try to make it plugable so that possibly other types could be used later. ARB requires SSL and collecting the payment info, but it's easy to create and manage a subscription and the user doesn't have to have an account.

More discussion

I think most of the sites we launch will have a few subscription "buckets" and then a few levels within each. The user can subscribe to multiple subscriptions but only one level within each.

It seems the simplest way would be rely on user roles. When you subscribe you are granted a user role. For each view that is created it looks at the content type and user role to determine whether or not it gets displayed. Say you create some block views on the homepage for premium users. Using the "author role" filter in the view setup you filter which roles you allow.

And in the .tpl view for the content you can again view the content author's role to decide which fields get viewed and maybe how it's viewed.

So roles/access control + views sounds pretty good. Using the quota by role module I can assign limits to how much content can be submitted by each role. I don't like that it shows the "quota by role" page to all users by default, I may have to make some changes.

Obstacles

To me the main obstacle is how to treat content as subscriptions are modified. Here are the cases for content changing:

1) Subscription is upgraded
2) Subscription is downgraded
3) Subscription is cancelled

I think for simplicity there should be a 1-1 relationship between a subscription and a content type.

Upgrades

If the subscription is upgraded, you just remove the previous role, add the new role and usually the new role has more visibility and let's you post more content (views+quota by role handle that). And you're probably not having to touch the existing content out there.

Cancellations

If the subscription is cancelled, you remove the role and a job or trigger function looks for any nodes of that content type which is bound to the subscription and "unpublishes" it. The user cannot republish it without subscribing again.

Downgrades

I think this is tricky only for deciding which nodes get unpublished. If you were allowed 10 nodes for a content type and now only 5, then which get hid? My thought is that upon downgrading the user has to select which nodes to unpublish and that once they do that in their content section they will see 10 nodes but only 5 are published. They still will not be able to publish any more content without deleting existing content.

Conclusion

This is my idea for a subscription/configured drupal site. Ideas, comments, suggestions? I might create a drupal project at some point if I think it's built in a way that is reusable.

So in review the modules utilized are the staples 1) views and 2) CCK, with a perhaps modified 1) Quota by role and 2) CCK field permissions. The only custom module would be the "subscription" module which allow the user to create subscriptions and levels. Each level would be tied to a role. Each subscription level also would have payment properties: price, duration, etc. Each subscription bucket would have to be tied to a content type, CCK or otherwise.

The subscription module really wouldn't do much enforcing of the rules, which is kind of nice that the rules of the subscription would be "decoupled" from the subscription module itself. The rules are tied to the role that the subscription levels grant. So access control determines what the role can do, CCK determines the visibility, quota by role determines quantity, CCK field perms determines fields that can be posted.

How's all that sound? Thanks for your help, -Jay