This module provides an entry-point into the system. It allows a customer to enter an order over an encrypted SSL connection. The front-end is designed in JSP (Java Server Pages), and can be customized for any company's needs. The order is received and stored in a database. If any e-mail or LDAP accounts need to be created for the user who entered the order, they get created at time of order acceptance as well.

If a credit-card transaction needs to occur, it happens before an order is accepted. Connectivity is provided for Authorize.net Payment Processing Gateway. Connectivity to additional Payment Processing Gateways like Cybercash can also be provided.

The order is stored in the database. Even if any internal errors happen in the processing of an order - network connectivity to the Payment Gateway, failure of E-Mail Server, etc., the application stores the order and flags the errors as required. If the database server fails, then the order is still logged in a file for manual entry by internal staff.

The module can be configured to send e-mail notifications about new orders to any number of personnel in the company. In case of failures or errors detected in order processing, system administrators can be notified as well. The e-mail's Subject can be customized depending on the nature of the notification (e.g. Successful new order, Error in Credit-card Payment Gateway, Database Failure, Email Server Failure, etc.).

Care has been taken for capturing the order without causing the user to be notified of any internal system errors. This prevents the customers from getting frustrated and turning away to some other vendors.

The order-entry module has its own separate denormalized tables to capture the order information. This keeps the logic simple, and less prone to failures. The data in these denormalized tables can then be extracted by background jobs and normalized into the real tables of the e-commerce system, so that it can be used across rest of the system. This also means that if the data has to be integrated into a company's existing system, then it can be easily done due to the clean separation mentioned above.

For companies that sell products and services in a combined manner, the order-entry module allows pricing these separately or in a combined manner. For example, if a company wants to sell wireless phones along with monthly subscription services, the application will allow definition of such pricing models. If the subscription services need to be activated instantaneously (like activating a cellular phone service), then the order information is communicated to the parent service provider through the Service Activation Module.

When a company sells products that could also be sold in Super-stores like Fry's Electronics, Walmart, K-Mart, etc., the application takes into consideration the fact that special shipping prices need to be applied when the customer is one of these Super-stores. If the product is usually sold along with a service or subscription (e.g. a cellular phone), the application knows that the service will be activated separately after an end-user has purchased the product from one of the Super-stores. Hence the products shipped in such an order have a special Service Status indicating that it is "Pending Activation".

The shipping module is useful when a company has an order-fulfillment center. This could be an external or internal center.

When an order has been received, it triggers a chain of events whereby the company's staff verifies the order, and sets the status of the order as "Ready for Shipping". Once this has been done, the Shipping Module extracts those orders and communicates them in a format required by the fulfillment center. This could be done via FTPing a delimited file, or posting the data to a website in any custom format.

The shipping module has pre-built functionality to do this kind of work, and it is a simple matter of customizing the format of extract files that need to be communicated to the fulfillment center.

The module also tracks the responses from order-fulfillment center, and stores the Shipment Tracking Number, and a variety of other information in the database. This is useful in analyzing the status of a shipment. Where there are failures in shipping a product, notifications are sent to appropriate staff in the company, and the database is updated to reflect such anamolies.

Where a company's business is to sell products as well as related services (e.g. wireless subscription plans), it is important for the service part to get activated when an order is accepted. Activating a service could be a simple task, wherein an internal database table needs to be updated, or it could be a complex task wherein the service information needs to be communicated to the system of the Parent Service Provider company.

When the order information needs to be communicated to an external system (Parent Service Provider), the Service Activation Module provides pre-built functionality to handle this. It extracts those orders whose service needs to be activated, suspended, re-activated or cancelled. This module has its own workflow for managing the requests sent to the external system, and tracking the responses received from it. If a "success" response is received, then the appropriate action is taken on the service. If the response is a "failure", many appropriate actions could be taken depending on why the failure occurred (e.g. Invalid Subscriber ID, Subscriber already Active, System Failure - Please Resubmit, etc.).

This module is aware of certain shipments of products shipped to Super-Stores, which should not be activated until an end-user has purchased the physical product. It therefore does not activate the service for such a product until the user comes in through a special web-page and confirms the purchase of a particular unit. Only then is the service for that product activated.

This functionality for service activation can be customized to each company's unique needs, though the core base for managing the workflow can remain the same.

This module provides a set of screens (either Web-based or Java Swing based) for internal staff of a company for managing the Service Accounts or Subscriptions of their customers. For example, if the customer wants to suspend his service for one month because he is going on vacation, the staff can update the status of his Service Account. This change of status is communicated to the external Parent Service Provider's system (if necessary) by the Service Activation Module.

This module allows recording of reasons for changing the status of a service or subscription, along with the staff's name and time when it was updated. This provides a complete audit trail of all the changes in a service's history.

This module provides a set of classes for managing communication with the Credit-Card Processing Gateway (Payment Processor). Pre-built connectors are provided for communicating with Authorize.net platform, while additional connectors can be easily implemented for CyberCash, etc.

The module can be configured to handle errors generated on the Payment Processor side. For example, if the Payment Processor returns an error message saying "Too Busy", then this module can wait for a few seconds and retry the same transaction. Also, if there are certain bugs on the Payment Processor which cause erratic behaviour intermittently, this module can be configured to recognize that and retry at certain intervals, or try an alternative URL for the Payment Processor. This ensures maximum probability of getting a transaction completed successfully.

This module also does basic Credit Card validations before submitting the information to the Payment Processor, thus preventing fake transactions being submitted by hackers.

When a company sells services or subscription plans which require periodic payments from the customer, this module allows for charging the customer's credit-cards at proper intervals. The module is capable of flagging credit-cards which are no longer active, and notifying the staff as well as the customer about such events. When a payment cannot be done automatically within a certain period of time, the module can be configured to suspend the customer's service or subscription automatically (with the help of Service Activation Module.

Customers with inactive credit-cards get a chance to enter new credit-card information to keep their service current. This is done by providing a hyperlink in the notification e-mail, which the customer can click and logon to their own account on the company's website.

The module allows for the company staff to prevent certain Service Accounts from getting charged. This is to allow for special conditions wherein a customer is actually a staff in the company, or a reporter who is testing the product, etc.

If the company has a network of Resellers who sell products and services in niche markets, they can ask their customers to enter orders through "branded" websites hosted by the main company. Or, it is also possible to provide special Web Pages for order-entry which would indicate that the customer has been referred to by a Reseller, and is eligible for special pricing.

The Order-Entry Module has the capability of processing orders received from Resellers or from customers of Resellers. Even orders entered by customers who have bought products from Super-Stores can be tracked, and commissions paid to the Super-Stores.

The Commissions module calculates the commissions that are due to each Reseller (with a maximum depth of 3 Resellers - i.e. a Reseller's Reseller's Reseller) based on rules configured in the system. These rules tell how much percentage of commissions to allocate to each Reseller based on factors like Volume of Sales, Types of Products sold, etc. These rules can be customized based on a company's policy.

This module is complimentary to the Reseller Commissions module. In addition to paying Resellers based on actual sales, a company may want to pay a Web Portal based on number of hits it generates on its website. This module stores complete information about the Re-directing Pages, and allows a company to monitor the success of their promotional campaigns by viewing statistics of each campaign.

The rules for calculating the commissions are stored in the Reseller Commissions Module. That module treats an Affiliate as any other Reseller, and calculated commissions to be paid.

This module provides a database-driven electronic catalog through which a customer chooses the products and services he/she wants to buy. These selections can be stored temporarily for a few days on the server, in case the customer wants to come back and buy them later. The cart allows for standard functionality for adding and deleting items, changing quantities, etc. Because the information is stored in a database, and not in the browser session, the user can login through any machine. For example, a user can initiate a purchase at lunch-time in office, and complete the transaction at home after dinner.