About Incomplete Registrations
Club administrators will notice, when when viewing received registrations, they will often see notices like "Payment Incomplete or Pending" or simply "Payment Incomplete". These messages are normal and can occur for several reasons.
| • | The person registering may have run into difficulty at the payment stage. |
| • | The payment provider may not yet have updated the registration database to reflect the fact that a payment has occurred. |
| • | The payment provider may have been unable to accept a credit card. |
| • | The person registering may have had a change of heart part way through the registration process and decided they did not want to complete the registration at that time, but they may still wish to do so later. |
| • | They may have run into a problem with their computer such as a browser hanging or accidentally closing the browser window. |
As a matter of design, we want to be very careful about discarding or ignoring registrations since they usually represent business for your organization. Your customer will have taken time to register, and they will be understandably upset if they are asked to re-key their data again. For this reason, we purposely retain on-line registrations as incomplete, even if payment was mandatory and the user did not complete the registration fully by providing payment.
We tentatively commit registrations to the database (and we also tentatively hold spaces in the class or event that the registration applies to) based on an assumption that the customer or user did in fact mean to register and we leave the decision to the administrator as two whether incomplete registrations should be deleted.
Within the first five minutes of an incomplete registration occurring, the registration will show up as Incomplete or Pending since it is still possible that the payment provider interface is simple slow in processing the payment, or that the user is still on-line interacting with the payment provider. When there are high volumes of registrations all happening at once it is not uncommon to see a dozen or more registrations all in the "Incomplete or Pending" state since these dozen users are concurrently in the process of providing payment details.
Five minutes after the payment screen or a registration is presented, the system will judge that too much time has elapsed and that the registration is therefore very likely incomplete (although if payment is provided, payment will still change to "Paid in Full") The administrator will see the state of the registration change to "Payment Incomplete" as shown below.
Note that in the example above, depending on the configuration of the registration setup, the site may say "scheduled for deletion" as above.
In most cases, club administrators will want to call or send an e-mail to the person who registered, ask them what happened with their registration, and invite them to provide payment - possibly on-line, or possibly through another means like providing a credit card number over the phone or dropping off a cheque.
If the administrator determines the registration really was made in error after speaking with the customer, they can simply delete it. If payment is made in some other way, the administrator can edit the registration record, update the amount paid, and if the registration is paid in full, the status of the registration will change accordingly.
Notification of Incomplete Registrations
Normally the administrator of the event is not sent an e-mail when they receive an incomplete registrations. This behaviour can be changed however under "System Setup" / "Preferences" / "Registrations" in the section "Policies for received registrations". If event level registration notification is turned on, the setup can be configured to send notifications event when an incomplete registration is received.
By default the system will wait at least 20 minutes before notifying administrators of an incomplete registration. (the person receiving the registration receives no notification of an incomplete registration, since as far as they are concerned they abandoned the transaction in most cases) This delay of 20 minutes is intentional since sometimes users can take a fair amount of time complete a registration transaction. This is especially true in cases where registrations are conducted in shopping cart mode. As items are placed in the cart they are tentatively reserved against appropriate schedules, however there can be a long delay between placing an item in a cart and providing payment.
Automating the handling of on-line registrations with Grace Periods
While contacting customers individually to deal with incomplete registrations works well for smaller organizations, in higher volume registration environments, this may not be practical. To deal with this, facilities can provide a "grace period" for registrations. The Grace Period refers to amount of time from when a registration is tentatively accepted, until when the registration will be canceled for non-payment automatically assuming payment does not occur.
Grace Periods work as follows.
| • | Grace periods are configured by the Administrator under "System Setup" / "Preferences" / "Registrations" under "Policies for received registrations" as shown above. |
| • | The default grace period of "0" (zero) means that registrations will stay in the system indefinitely (occupying registration slots) until a registration is specifically deleted by the administrator. Deleting the registration removes all traces of the registration, however if the registration was of a sort where a member account was required, the member account will persist so that this person will be able to login the next time they register rather than re-enter their personal information from scratch. |
| • | A value of "-1" means that the system will quietly and aggressively delete incomplete registrations without notifying the customer registering or the web-site administrators. Note that the registration slot still needs to be tentatively held for a short period since users will often take several minutes to provide payment. |
| • | You may enter a grace period up to an arbitrarily large number (integer), but in practise the site will not delete records determined to be more than 10 days (240 hours) old. This is because some organizations will have had prior sessions structured in such a way that they may have treated incomplete registrations as valid, and we want to be cautious about deleting older registrations made before a new grace period policy came into effect. |
| • | If for example, a grace period of 48 hours was indicated, and an incomplete registration was received (where payment was flagged as mandatory), the following events would occur: |
| 1. | In the registration summary screen, the registration would be flagged as "scheduled for deletion" to let the administrator know that this registration will be removed automatically in 48 hours if the registration record is not updated to indicate that payment has been provided. |
| 2. | An automated e-mail from the web-site will be sent to the person who registered similar to the one below, advising them of the amount of time they have to provide payment before their registration will be automatically deleted. (only one such message of this sort will be sent) |
| 3. | The administrator of the event or class (if notification is turned on) will also receive notification that an incomplete registration has been received within 10 minutes of the incomplete registration occurring. |
| 4. | After the grace period expires (2 days in our example), another e-mail notification will be sent to the registrant advising them that their registration has been automatically deleted since payment was not completed within the 48 hour grace period. |
| 5. | The administrator will receive a similar message advising them that the registration has been deleted |
| 6. | The registration will cease to appear on the list of incoming registrations |
| 7. | Any "slots" the registration was occupying in capacity constrained events like classes, camps or resource reservations will be freed up and will become available for the next registrant. |
Below is an example of what the advisory e-mail sent to customers looks like.
Additional Technical Detail on Grace Periods and Incomplete Registration Notification
| • | The background thread on the server that detects incomplete on-line registration runs every five minutes automatically. For this reason, it may take up to five minutes to receive a notification (in additional to whatever delays your own e-mail provider and e-mail client add to the process) |
| • | In cases of high-registration volumes, the notification of incomplete registration by e-mail is automatically "throttled" to no more than five notifications per web-site. As an example, if 30 incomplete registrations happened all at the same time, it would take up to 30 minutes for all users to be notified that their registrations were incomplete. This is done intentionally to avoid overwhelming e-mail servers to large numbers of messages since these types of activities are often interpreted by mail providers as SPAM. Throttling e-mail in this manner also helps ensure that preference is given to on-line activities like on-line registration when the web-server is under high levels of load. |
| • | If notification of incomplete registrations is enabled, notifications will be provided for incomplete registrations more than five minutes old, but less than seven days old. We impose a five minute delay to allow the asynchronous payment reconciliation process to "catch up" with the registration. It is technically possible that a payment could reconcile even after a non-payment notification is sent out, but this is unlikely. (In this case the administrator would receive a non-payment notification, and then some time later they would see a notification that the registration is confirmed) - because this can happen, we do not send these incomplete registration notifications to the registrant - these are for the even administrator only. |
| • | Incomplete notifications will be sent if, notification is enabled, we are within the period of 20 minutes to 7 days after the registration, if a warning has not been sent before, if the payment confirmed was $0, and if the payment expected was greater than $0. Warnings are not sent for "partial payments" since there are a variety of valid reasons that these may occur. |
| • | If a non-zero grace period is provided, if on-line notification is enabled in the event, a notification of the grace period policy will be sent both to the administrator starting 20 minutes after the registration was tentatively posted. Notifications will be sent of there is a grace period, if event notification is turned on, if we are in the 20 minute to 7 day window for the initial notification, if a notification has not been sent before, if the payment provided was zero, if payment was mandatory, and if the amount due was greater than zero. |
| • | One expiry of the grace period, notifications will be sent about the deletion to both the registrant and the administrator as long as the grace period has expired by the registration is still less than ten days old, the payment provided was zero, payment was mandatory, and the amount paid was "zero" (the astute reader will appreciate therefore that posting any payment against the registration in the grace period will prevent the record from being automatically deleted. |
Cautions About Grace Periods
One potential risk with turning on grace period notifications when they have not been used before, is that the system will scan the database looking for old unpaid registrations and depending on registration volume on the site, there could be quite a number of these.
To address this issue, we provide a function that will allow an administration to see in advance what e-mail messages would be sent if a grace period were set to a value other than the default of 0 (meaning hold onto registrations indefinitely). This "Grace Period Impacts" summary report is accessible to system Administrator's under "System Setup" / "Utilities".
