Forms Manager supports payments recurring on the following schedules:
Recurring Payment options are configured in the "Payment" tab of Forms Manager. Any currency form (that is, any form that processes monetary transactions; see Enabling Payments on a Form) can include a recurring payment component.
To setup a recurring payment capability for end users:
- Use the Recurring Payment Option dropdown menu to select either "Optional" or "Required."
This will present users with the recurring payment fields during the payment process at the end of the form.
- Enter the Recurring Admin contact information for a site admin, school office or school staff member who will manage recurring payments for this particular form.
Note: It may be a good idea to fill these fields with information that refers to an office or other general point of contact rather than a specific person. Some recurring payments, such as alumni donations, may span a long enough time frame that one specific person may no longer be filling the same role at the school if and when a user needs to update their payment plan.
- Use the Recurrence Frequency and Recurrence Duration controls to set how long the end users' payment plans will run.
In these sections, "cycle" refers to the number of times the payment is (or will be) processed. Selecting "Indefinite" means that payment plans created with this form will run continuously until cancelled by the user or by a school staff member. Payment plans that are not meant to run perpetually will instead have a minimum and maximum number of cycles. These represent only the limits that users can sign up to pay during the checkout process; the actual user payments will fall between the min and the max and are set by the end user when the form is submitted.
- (Optional) Use the Recurrence Instruction checkbox & field to provide additional information or instructions to end users.
- (Optional) The Recurring Notification Email instructions allow form admins to setup reminder emails to end users, informing them in advance when a recurring transaction is coming up.
In addition to simply sending a reminder email, the inset checkboxes allow form admins to modify the content of that email. The basic email simply informs the user that a payment will be applied to their credit card in on week's time. The email can also be set to include a link that allows users to cancel the recurring payment plan, as well as a custom message from the form admin. (Clicking the "include custom message" checkbox will pop open a new text area where admins can create a custom message.)
When users fill out a recurring payment form, they will be able to review their payment options before submitting. Form elements allow users to select the recurrence, frequency and payment date options they want.
Using the dropdown menus in the first line, this user has the option of establishing a recurring payment, or selecting a "one-time" payment (because this form has the "recurring payment option" field set to "Optional" - see step 1, above.) They can also set the frequency of the recurring payment ("monthly" vs. "annually"), as well as the duration (in this case, 4 months). The initial charge ($20 in this example) is set according to the options selected on the form itself.
The system automatically tallies the total payment on the next line. The dollar amounts outlined in blue are calculated by Forms Manager. If the user were to alter the frequency or duration of the recurring payment, these tallies would update to display the new total. Note that these fields cannot be edited directly; they change based on the currency fields set in the form.
The user can then choose when the payment will be applied. By default, payments are applied based on the date the form is submitted; if a monthly payment is first made on the 19th of the month, then the next payment will be applied on the 19th of the next month, and for all subsequent months for the duration of the payment plan. The user can override this default and have payments applied on either the 1st or the 15th of the month instead. Again, the projected dates of the user's transactions (highlighted in the example above) will update based on their selections.