Only recently starting to use DynReg.

We have a setup where a site will have several levels of paid subscription, which will be renewed annually and no refunds given for cancellation.

The setup we are currently looking at using is

For New Registrations; 1 DynReg instance viewable to only unauthenticated visitors which handles the first signup and process the payment (only for the initial registration) and add the user to the role for 365 days.

For Renewals; A copy of the initial DynReg instance viewable to the users in the member role/s that processes payments for both new and updates and adds the user to the role for 365 days

For Updates; A copy of the initial DynReg instance viewable to the users in the member role/s but not doing any Payment processing

On a side note a good companion to DynReg would be a modified USER skin object that can be configured to send a site visitor to one location to initially register and the standard dnn defined User page for updates.

Looking forward to hearing from some more experienced users.

TIA

Antony

Hi Antony,

Your idea will work but here's a suggestion to streamline:

You can combine the New Registration and Update Registration with some settings.  1) Make the page/module visible to all users.  2) set payment gateway and all related completion events to initial registration only.  3) Edit all payment related fields and hide them from registered users.  This way, you don't need to maintain too many separate instances of the module.  The unauthenticated user can click on register and the registered user can click on their name on the skin and get to the same page.

Your idea for the Renewals will work well.  On the 1st registration page, you might want to have a text module visible to registered users only that says something like "Click here to renew your membership" then redirect them.  This will also work very well with our Renewal Reminder module.

Candace

Thanks Candace for the info.  We are going to be using your Renewal Reminder.