Topics
About subscriptions and regular payments
For some types of registrations, you will want to capture a user’s acknowledgement that they will pay you on a recurring basis and have those payments charged to a payment source automatically.
Some examples scenarios are:
| • | Monthly competitive fees |
| • | Regular Membership fees |
| • | Payment by installment |
NeatClubs.COM supports the ability to handle these sorts of recurring payments automatically. A recurring payment event (subscription) is identical to any other registration event except that rather than making a one time payment, the person registering is providing authorization for charges to be made against their payment source on a periodic basis.
Subscription scenarios supported
NeatClubs has its own event type for subscriptions. For events of type "subscription" a recurring or deferred payment screen becomes visible in the event setup.
Subscription payment scenarios supported include:
| • | Optionally bill a subscriber up front on registration |
| • | Define a fixed "trial" period following registration until the first of a series of monthly billings |
| • | Define a specific date on which to start regular payments |
| • | Start regular monthly payments on a specific day of the following month |
How regular payments are collected
NeatClubs.COM leverages the facilities of PayPal or other merchant providers to collect regular subscription payments. When a user authorizes a subscription, and provides a payment source in the course of a NeatClubs.COM registration, this authorization will be visible to the merchant via their PayPal merchant account. The PayPal merchant account holder will receive notifications automatically from PayPal whenever an automated payment is made to their merchant account. NeatClubs will also track incoming recurring payments as shown below. These will not show up as "new" registrations since they are actually payments associated with prior registrations.
The merchant account should be used as the system of record to manage the accounting and track who has paid and who has not. Sometimes payments can fail for reasons outside of the control of the registration system. For example, a credit card might expire or a backing bank account could have insufficient funds. For these reasons it is important to monitor payments to make sure they are received. In most cases however, payments will simply be automatic.
Setting up a subscription or deferred payment scheme
The screen below is used to define the subscription of deferred payment behaviour.
The recurring payment facility allows a merchant to accept an optional one-time payment "up-front" and optionally provide a trial period. For example, you might structure your service in such a way that you allow a one month free trial period and begin regular automated deductions after that. In this case we would bill the subscriber for $0.00 up front and offer a 1 month trial period. Another option would be to charge a $200.00 fee up front, and then charge $50.00 / month for each month thereafter for participating in your organization.
There are three options in terms of deciding when regular payments will start:
| • | Fixed Trial Period or Delay - this is useful if you want to have regular payments become after a fix delay period. For example, I might start payments after 2 months, 8 weeks or 60 days (all having subtly different of course depending on the number of days in each month!) As an example, if a registration was taking place on January 15th, and you wanted the first payment to commence exactly two months following the registration, you would select a "Fixed Trial Period" and specify a delay of two months from registration. |
| • | Start Recurring Payments on a Fixed Date - This is useful for programs that have a fixed start date where you need to synchronize all registrants so that regular payments will start on a specific date. For example, I may want recurring payments for everyone who registers to commence on January 1st of the following year. In this case whether I register on October 10th or November 5th my first recurring payment will still start on January 1st. If you are synchronizing recurring payments to a fixed date you should also provide a registration deadline. For example, it would be a good idea to set a deadline of December 31st as an example so that people do not try to register after the initial payment is due. (Please note - if you are targeting recurring payments to start on a fixed date at some point in the future, PayPal has some limitations in this area. PayPal can only defer registrations by 90 days. It can however defer registrations by a larger number of weeks or months. In order to achieve the desired effect and work around the limitations of PayPal, NeatClubs.COM will automatically adjust the delay period in weeks or months depending on what is appropriate. This means that for registrations made more than 90 days prior to a synchronized start date the regular billing dates will still occur but they may be off by a few days owing to this limitation. |
| • | Start Regular Billings on a Fixed Day each Month - This is useful in member based scenarios where you have people constantly joining and leaving a club, but still want to synchronize regular payments so that they are received on the same day each month. The behaviour is to always start billing on the month following. For example, if my billings always occur on the 10th of the month, and if I register on December 5th, by first automated payment would be made January 10th of the following calendar year. |
The options above determine when the first regular billing / payment will take place. The regular billing cycle determines the time between the first payment and subsequent payments. It is recommended that you always set "Retry Failed Billings to Yes". If a payment fails, this allows the system to retry periodically until it is able to collect the payment from the payee. This is intended to work around transient problems or cases where a registrant was temporarily without a valid funding source.
The registration user experience
The user registering for a subscription style event would follow the same path as they would with any other registration. The subscription would have descriptive text, they would be invited to login or create and account and there might be optional forms to be filled in as a part of the registration.
The difference would be apparent on the payment screen. Below is the payment screen that would correspond to a scenario where we had a $220.00 sign up fee and always started collecting payment on the 15th of the month. In this example we register on December 20th for a 10 month subscription and authorize regular deductions to start 25 days from today.
This subscription authorization is then reflected in PayPal as below. PayPal has no notion of start dates. It is simply asking the user to authorization a payment of $220.00 up front and to pre-authorize a stream of 10 x $50.00 payments starting 25 days from today (my target start date of January 15th in this example)
