Forums / Developer / handling "prepaid" subscriptions to content

handling "prepaid" subscriptions to content

Next topic

Author	Message
Massimiliano Bariola	Monday 17 July 2006 9:32:57 am Hi, I am on the verge of developing an eZ site for a local newspaper. users of the site must be able to: 1) subscribe to the restricted accesss area (creating an user account after successful credit card authorization) 2) browse all the content they want for N months (N dependent on the type of subscription they buy) 3) buy a "prepaid" number of issues (e.g. 12): when this type of users wants to see an issue of the newspaper (e.g. July 4, 2006), they will spend one of their prepaid "credits". from that moment on, the user will not pay other credits to browse again that specific issue. I can picture that point 1 is not trivial and point 2 rather messy, but AFAIK, point 3 promises to be, well, a bloodbath, or, to be optimistic, a nice case study .. :-) it will involve not only permissions on the single user and on the single issue (which can be a folder, thus a subtree), but also keeping some kind of table somewhere which maps which user has access to whose nodes. has anyone done anything remotely similar? or can someone give some hints on how would they do it to make the fullest use of eZp's builtin capabilities? cheers, Max
Kristof Coomans	Tuesday 18 July 2006 3:24:02 am Hello Max This topic could be interesting for point 3: http://ez.no/community/forum/developer/access_right_per_user_per_node You will definitely need to create an extension. If you want to use the existing role/policy possibilities of eZ publish, then I would assign a role - with policy content/read - to a specific user - with an assignment subtree limitation on the specific issue Of course you will get a long list of role assignments, this could have some performance impacts. You can also create a new user group for each issue, assign the a role with content/read to the user group with an assignment subtree limitation on the specific issue. Now if a user subscribes, you only have to add that user to a group. I think this approach is slightly better, you won't end up with user-assigned policies and view caching will work better. independent eZ Publish developer and service provider \| http://blog.coomanskristof.be \| http://ezpedia.org
Fabricio Guerrero	Tuesday 18 July 2006 4:12:50 am Hi, I've done a similar website to the you mention. Please visit: http://www.ccbriefing.co.uk/ Here the site has 2 user levels Bronze(Free) and Silver(Paid) and the Articles are also classified by leves Bronze and Silver. Access Rights: A Bronze user can only view Bronze Articles. The Silver user can view both Bronze and Silver articles. I've done this by just adding an attribute to the Article Class to set the Access Level and when an Article is loaded from the front end I check the Users Group and decide wether or not to show Article to User. Buying an Issue: This is the online edition of an UK monthly magazine which can also be bought online. This was rather simple. For this I just use the built in ezShop functionality Subscribing/Paying Users. The way the system works is that all users automatically get signed up as Bronze or Free Users (Bronze User Group). If the user selected for the paid membership Immediately after he is redirected to paypal he returns to an extension which remembers the Users NodeId and moves him into the Silver/Paid Group(Silver User Group). Hope this makes sense.. If you need some code examples just let me know. Regards, Fabricio http://www.solobromasychistes.com <<Joomla Site :P http://www.recipesforhealthyfood.com/ <<Drupal Site :P http://www.ezforge.com/ <<future ezCommunity, Articles, forums and more...
Massimiliano Bariola	Tuesday 18 July 2006 5:19:49 am Hi, @Kristof: Thanks, i browsed the link you gave me and indeed it seems like what I want to do, on a core / PHP level. but I don't think I am so proficient or how will the performance impact be, so I think I'll opt for a template - level solution (see below) @Fabricio: yes, this is somewhat similar to what I wanted to do, and actually I was thinking to move the check to the template level, instead of fiddling with roles etc. luckily the site is still very simple, for now. But I do not get this - if you let them buy the single number via the eZ shop, do they still manage to see it online when bought, or you let them download it instead of viewing it online? The client wants it to be always available online (the full view of the issue will also have the possibility to download it). I was thinking tonight of a solution, refined from what you both say. Let's have three different users. anonymous, subscribed for a time period, and prepaid users. anonymous don't see anything. that's said for them. those subscribed for a time period will have a date attribute signalling expiry. a cronjob will deactivate those users. the prepaid users will only be able to watch those issues to which they have an object relation to. I'll write an extension with a frontend view which will allow users to subscribe to an issue, by adding an object relationship. the template will check if the current user has relationship to the currently viewed node and act accordingly. I think this could be the way to go ... but have to think a little about caching, and I do not know if it's a roboust enough security (e.g.how many templates do I have to insert that check into? full, print full, etc ........ I might forget something). What do you think of this? cheers, Max
Eirik Alfstad Johansen	Tuesday 24 April 2007 7:24:39 am Hi Massimiliano, Did you ever get around to solving this and, if so, how did you handle the "date of subscription expiration" problem? Thanks in advance ! Sincerely, Eirik Alfstad Johansen http://www.netmaking.no/
Massimiliano Bariola	Tuesday 24 April 2007 9:04:27 am Hi Eirik, no, I hadn't advanced further on that problem because we didn't get the client :-) sorry sincerely, Massimiliano
Betsy Gamrat	Friday 27 April 2007 9:36:54 pm Hi, I've been building subscription code. It isn't ready to share - but my approach is as follows: Created a custom class for the product that the person is subscribing to Created a payment extension to handle the credit card interface Created a subscription processing extension that the payment extension uses to handle renewals and cancellations. This uses a new table in the database. Important considerations: Credit card subscription processing may be gateway dependent - so it makes it easier if there is a custom class for the specific gateway. If you are allowing multiple gateways, you're braver than me. If more than one subscription can be purchased, each must be managed separately at the gateway level to allow independent renewal and cancellation. Many gateways have recurring payment systems that allow you to pass them the credit card data, and they initiate the renewal payments through a postback. Consider building an application independent gateway module, that can support multiple applications with a single instance. Sometimes, complex sites have more than one application handling ecommerce. Be prepared to invest a significant amount of time - it is a complex interface.