Implementing a paid content subscription model on a Plone site

One of our customers has a new requirement to have part of their site accessible only to users that have a paid subscription.

As long as we have found, there are several services that offer the subscription management, but only take care of the payment process and regular notifications on the status of the subscription life cycle.

Does any body here had worked on a similar use case?

Where do you store the user base? Plone? Third party service? Which one you use?

Best regards!

1 Like

I'd take one of these services, then I'd add a non-plone service (maybe a tiny pyramid app using node.ext.ldap) to listen to those notifications and write/update users and subscription times (end-of-subscription) to LDAP.
With pas.plugins.ldap you can now add those users to Plone and give view permissions where needed as usal. The plugin supports user expiration.

1 Like

I had a similar use case many times ago when I was working for RedTurtle.

I presented it at the Arnhem Plone Conference.

At the time it was a solution based on Membrane + AT + postgres + getpaid + a lot of formlib forms.

The user base data where stored partially on postgrers and partially on ATs

The access was based on time and on remaining credits.

Maybe in the video of my talk there is something relevant for you:

1 Like

I actually have a very similar situation with a client asking for this, so I'm interested in this discussion.
In my case, the site is already using GetPaid for membership dues, and they want to extend this to allow access control to some paid content based on membership and/or subscription (which are not necessarily the same).

1 Like

We have a client that uses Salesforce for accessing subscription-based content. Areas they are subscribed to are managed in Salesforce, and all users have a profile in the Plone site that is hooked up to their Salesforce profile (similar to LDAP). Any changes to a profile in Salesforce will automatically update the profile in Plone. The areas they have access to are basically set up like groups in the Plone site, so each piece of content needs to specify which groups are allowed to see it.

1 Like

In our case, we map "subscribed" to an associated group membership and use local roles (sharing tab) to give this group appropriate permissions. Users and groups are in a Postgres database, but they could be anywhere.

1 Like

We use Plone to provide web-based services that hook to and complement a separate (non-Plone) on-site traffic logistics server (typically one such on-site server per customer) . For that I implemented a content type for "provisioned customer" and "provisioned service" (such as access to paid content), together with a traverser ('++provisioned++') that allows for convenient traversal to customers & services, and a view to list the customers & provisioned /available services. A new "customer" role is also thrown in, mapped to (very heavily) stripped-down Plone 4.3 UI. I am hoping to use dexterity.membrane to automate group creation (each "provisioned customer" a new group). Everything in Plone. There's no hook-up to payment systems; customers and services are provisioned manually.

1 Like

because of time and resource restrictions ($$$) we ended up by creating a simple add-on that does the following:

  • redirects an user, who wants to become a subscriber, to a third party payment platform
  • creates a normal Plone user (using subscriber's email as user id) when it receives a notification from the payment platform about a successfully processed payment
  • includes this new user into a Subscribers group
  • sends the subscriber a link to Plone's reset password view via email
  • deletes the subscriber's user when it receives a notification from the payment platform about a subscription cancellation

we created a special folder and set access permissions to it for members only.

we have no idea how many users we'll be able to support or how much additional resources (CPU and memory) we'll need.

if the subscription feature is a success, we'll have a different problem and we'll take care of that then.

sorry, but that's the way stuff works here.

1 Like

But it shows how amazingly feature rich Plone is out of the box. Congrats for breaking it down to such a simple good enough solution.


thats more or less how we have done it in the past. using workflow and membrane etc just add complications.
Now with rapido you can do everything you list above without creating a new addon at all.

1 Like

Hi Hector,

I was wondering if you would mind sharing any follow-up thoughts / lessons re: the approach you used for subscriptions now it's almost two years down the track?

We did so with Patreon and Plone last year or so, we paid for the Plone / Patreon SSO plugin development, and asked that is freely opensource and available, if you are able to use Patreon, or use the source code to see if fits the processing platform you are working with, hope that helps.

and asked that is freely opensource and available,

Can you please provide a link for others to that add'on if it's now freely opensource and available?

are you specially interested in something? unfortunately, I can't share the code neither too much information of the customer because this is a sensitive site and currently the political situation over here is complicated.

what I can say is that we have hundreds of users in Plone's database; we process dozens of notifications daily and we haven't touch the code in 18 months.

the site runs very fast with response times of less than 500ms most of the time, with limited resources according with traffic; it handles millions of monthly sessions.

we are using the same server specifications from the beginning; we didn't need to add memory or CPU at all; Plone is awesome! :wink:


That's a great summary.... Thank you for that!

I like the conclusion too: