Payment Collection System and Parameters explained

The Reseller Control Panel comes built in with a customizable Payment Collection agent which you can use to ensure timely collection of Payments from your Customers and Sub-Resellers. It is important to understand the different financial instruments available within the Control Panel before we delve into a discussion of the Payment Collection module.

Your Customers and your Sub-Resellers in the course of their operations will owe you money for specific reasons. These reasons can be as follows:

• They place an Order.

• You enter a Debit Note in their account.

• A payment made by them in the past charges back

• You add an Invoice in their account

There are two types of transactions which you can use to collect money from your customers and Sub-Resellers. These are Invoices and Debit Notes. You have the ability to raise Invoices and Debit Notes yourself, as well as the system will occasionally raise them for you in specific circumstances. For instance when your Customer places an Order an Invoice for that Order is automatically raised by the system.

An Invoice and Debit note are quite different transactions. An Invoice is always related to an underlying Order, and may actually have some action of the Order dependant on the Invoice. For instance an Invoice for Renewal of an Order, has the action of renewal dependant on the Invoice. A Debit Note on the other hand is not related directly to any Order. Both of them share some common characteristics with respect to Payment Collection. An Invoice however has extra and more powerful Payment collection parameters.

Reminder Days

Let us first examine the single shared Payment Collection parameter that an Invoice and Debit Note have. Both an Invoice and a Debit Note have one field in common, namely the Reminder Days. This is a simple Payment Collection parameter which allows you to send a Payment Reminder to your Customers and Sub-Resellers for their Pending Payments. Every Invoice and Debit Note has a Reminder Days value. This includes Invoices and Debit Notes that we automatically generate as well as Invoices and Debit Notes which you feed in.

Reminder Days is basically the number of days the System waits before sending the next Payment Reminder for a particular Invoice/Debit Note, to your Customers. If for instance the Reminder Days value is set to 5 days for a particular Invoice of a Customer, then the Customer will receive a reminder to pay for that Invoice EVERY 5 days, until the Invoice is FULLY Paid. The Reminder days value is irrelevant after an Invoice or Debit Note is fully paid.

Default Reminder Days for Invoices

To begin with you can set a default Reminder Days value per Product, which will be used by the System when it automatically generates Invoices for that Product. This can be done from the Settings -> Finance & Billing -> Payment Collection Settings. If for instance you set the default Payment Reminder Days for Product A as 10 days, then for EVERY Invoice generated for an Order of Product A, will have a default Invoice Reminder days set to 10 days.

Default Reminder Days for Debit Notes

You cannot set a default Reminder days value for Debit Notes. This is a hard-coded value, set to 5 days, for ALL Debit Notes. Therefore any Debit Note that the system generates automatically will contain a Payment Reminder Days value of 5 days to begin with.

For any Invoice or Debit Note that you add manually you can specify the Reminder days during the creation of that Invoice or Debit Note. Simply point to Customers / Sub-Resellers -> Billing -> Add Invoice / Add Debit Note and you can specify the Reminder days for that Invoice/Debit Note while adding it.

Reminder days can be an extremely powerful feature, and it ensures that your Customers/Sub-Resellers are constantly reminded about any pending payments until they are cleared.

Reminder days are also the only Payment collection feature available for a Debit Note. Remaining features in the Payment Collection system are only available for Invoices. Read on to find out about these.

Invoice Specific Payment Collection features

Apart from Reminder days there are three other fields that Invoices can have to facilitate Payment Collection. These fields are:

• Request Cancellation Date

• Order Suspension Date

• Order Deletion Date

Note that these fields are available only if the Invoice is unpaid. They are not available for Paid Invoices since there is no Payment Collection pending for paid Invoices.

Request Cancellation Date: This field is available to any Fully unpaid Invoice which has a Pending Request associated with it. An Invoice associated with a Request can only be automatically generated. This field basically serves to cancel any Order or Request placed and then not paid for for several days. For instance if a dummy Customer comes to your website and Registers for a domain name. An Invoice is raised for this domain name. Now if the Customer does not pay for the domain name, within the Request Cancellation date then on the Request Cancellation date the Invoice and the Request for registration are both cancelled.

Lets take an example to understand this better. Lets assume a Customer of yours - Customer A, has the following Invoice -

Invoice ID: 1
Invoice Description: Renewal of abcd.com for 1 years
Status of Renewal: Pending
Invoice Amount: USD 100
Pending Amount: USD 100
Invoice Date: 1st Jan, 2003
Request Cancellation Date: 10th Jan, 2003

The above Invoice would be created when Customer A requested for the renewal of abcd.com. After this the Customer would continue to get reminders to pay for this Invoice every "Reminder Days". The following situations can now occur -

• Customer pays for the Invoice. In this case the Request Cancellation Date would cease to exist. The payment does not have to be a full payment. Even if the Customer pays only USD 10, against the Invoice amount of USD 100, even then the Request Cancellation date would cease to exist.

• You execute the Request without a payment. You can do this using the Execute w/o Payment button from your Control Panel. This would also cancel the Request Cancellation Date

• In case neither of the above occurs, the Invoice and the associated Request would be automatically cancelled by the system on 10th Jan, 2003

The logic for the above is that if an Invoice is partly paid, or if you Execute the Request, then the Invoice should not be automatically cancelled by the system, because both these actions mean that the Invoice should be paid for completely. If however an Invoice is simply created and not paid for or its underlying Request not executed for a long duration, the System performs a cleanup based on the Request Cancellation Date.

Since a Request Cancellation Date appears only for those Invoices which are System generated and have an associated Request, the Request Cancellation Date is automatically set by the System, based on your default preferences. These default preferences are specified per Product under Settings -> Finance & Billing -> Payment Collection Settings.

Order Suspension Date/Order Deletion Date: These two fields are the most powerful Payment Collection parameters allowing you to suspend or Delete an Order of your Customer or Sub-Reseller automatically within a predefined time period if they have not paid for a particular Invoice. These fields are available for System Generated (with the exception of Domain Registration Orders) as well as manually raised Invoices.

The purpose of these fields is quite explicit. Basically both these dates can be set to specific dates. When that date is reached and if the Invoice for which this date is set still continues to remain unpaid, the Order is then Suspended or Deleted as the case maybe. While these fields are powerful, use them with great care. A Suspended Order becomes immediately inactive. More importantly a Deleted Order cannot be recovered at all. Once an Order is deleted the process cannot be reversed. These fields are both optional, and their values depend on default settings you have made, as well as any specific modifications you make.

Lets take an example to understand these fields better. Lets assume a Customer of yours - Customer A, has the following Invoice -

Invoice ID: 1
Invoice Description: Invoice for Web Design of abcd.com
Invoice Amount: USD 100
Pending Amount: USD 100
Invoice Date: 1st Jan, 2003
Order Suspension Date: 10th Jan, 2003
Order Deletion Date: 30th Jan, 2003

The above Invoice could have been manually created by you. At the time of creation of the Invoice you set the Order Suspension Date, and Order Deletion Date. The following situations can now occur -

• Customer pays for the Invoice in full. In this case the Order Suspension and Order Deletion Dates would cease to exist. The payment however MUST be a FULL Payment. As long as the Invoice is not FULLY Paid the Order Suspension and Deletion dates will continue to exist.

• In case if the above does not occur, the Order will be Suspended automatically on 10th Jan and subsequently Deleted on 30th Jan

• If after the Order is suspended the Customer pays for the Invoice in full then the Order will be reactivated

• You can always Unsuspend an Order which is suspended, you can however never undelete an Order. Once an Order is deleted it cannot be recovered again

As you can see these parameters take the Payment Collection load off your back. The System sends several reminders to your Customers/Sub-Resellers, clearly mentioning that the Order would be suspended/deleted if it is not paid for, and if they do not pay despite those Reminders then the System will automatically Suspend/Delete those orders. Similar mails are sent to yourself informing you about the pending payments of your Customers/Sub-Resellers.

For every Invoice you create you can specify an Order Suspension/Deletion Date at the time of creation of the Invoice. Additionally the system itself sets Order Suspension and Order Deletion dates on System Generated Invoices based on your default preferences per Product. These default preferences are specified per Product under Settings -> Finance & Billing -> Payment Collection Settings.