Payment options were limited to two methods:

• Instant Payment where the customer pays by debit/credit card and gets instant access to the site.
• Postal Payment where the customer goes through the same ordering process but send back a print confirmation page along with their payment. Once eChalk receive the payment they can then make the account active.

The first issue we tackled was how to secure the subscription site and manage the users logged in. We decided after some research to opt for .net’s Forms Authentication to protect the files in the subscriptions area, but also added out own layers or protection beneath that to compliment the Forms Authentication method.

Our client likes to manage the web files of the subscription area themselves, so early on we decided not to layer all the pages with ASP.NET code, which could get damaged while he is editing his files, but to create shell that sites around the subscription content. This keeps all of the code abstract from his files and causes less problems for all concerned.

Unlike the shop we had created for eChalk, the subscriptions site behaves in a different manner and required a different approach to its development. Since our client would be maintaining the content, we only had to worry about developing a system to manage the subscription packages, the users and their annual renewals.

There is a Manager system in place for the subscriptions which allows our client to:

• Create new subscription packages (number of users, cost and duration of the subscription) and archive older packages (please see the section below why packages should never be deleted).
• Manage every aspect of the customers details from finding them in the database by a variety of means (eMail, postal address, post code etc) and editing their details (also the ability to change their package and subscription dates).
• Show currently logged in users.
• Record the number of users per day for later statistical analysis via the manager pages.
• Ensure only the recommend number of users are allowed to log in based on the subscription package purchased.

User and Administrator Modules.

When a customer buys a subscription package, two accounts are created: an administrator account to allow the school to manage their subscription, and a student account which is given out to all their students to use to log in with.

When a student logs in, they are greeted by the standard welcome page from where they can browse the site for information.

When an administrator logs in, they are able to alter their contact details and username and passwords for both their own and the student account.

Subscription Management module (invoicing renewing etc)

Each subscription bought by either the automated PayPal processed or by postal order, is added to an invoice database. Subscription packages are never deleted from the database or edited to ensure the price on the invoice matches the package they’ve purchased.

When a subscription is due to expire, a warning is displayed on the student and administrator welcome page. From this page they can either renew or upgrade their subscription package. An administrator can also upgrade a subscription part way through if they need to add more users to the package.

Session Management Module (logged out users)

Each time a student logs into the subscription site, their login is recorded in a real-time database. Each session is monitored and “timed out” after a certain period of inactivity. This is achieve in various ways:

• The page times out and automatically logs them out.
• They click on the logout button.
• If they closed their browser without first logging out, or some other reason has left a state session in the database, upon the next login of that user, any stale sessions in the database older than the timeout period are removed freeing the slots for new users.

Each account has a “graced” fresh hold to allow continual login of users even if the maximum has been reached. However, this is record and if abused the customer is advised to upgrade their account.