Flexible Payment Details


Learn about the similarities and differences between each type of flexible payment (one-time payments, installment payments, and recurring orders) as well as more detailed information about flexible payments as a whole.

The Three Types of Flexible Payments

There are three types of flexible payments, all meant to make paying easier. Constituents can use flexible payments throughout Community Hub, and staff can also use it in the Staff View order process.

We'll explain more about each flexible payment type throughout the page, but at a high level:

Flexible Payment TypeExplanationExamples
One-time Scheduled PaymentsInstead of paying now, schedule a single, future payment.
  • A constituent doesn't have the funds available yet and wants to automatically pay for their event registration two weeks from now instead of today.
Installment PaymentsInstead of making one large payment now, break the payment out over multiple, future payments that occur at a regular frequency.
  • To pay for their booth, an exhibitor wants to pay $400/month over the next six months instead of making a single $2400 payment today. 
Recurring OrdersInstead of generating a new cart or order for a repeat purchase, automatically generate an identical order at a regular frequency, and continue doing this until the recurrence is canceled. In general, recurring orders is also sometimes referred to auto-renewals, evergreen orders, or subscriptions (not to be confused with publication-based subscriptions).
  • Instead of sending out membership billing renewal notices every month, empower constituents to opt in to having their membership automatically renew each year.
  • Instead of only taking in one-time donations, give constituents the option to donate monthly.

In the event you are interested in restricting the number of days available for Scheduled or Installment Payments, please reach out to Nimble AMS Support for assistance.


Prerequisites & Dependencies Between the Flexible Payment Types

  • Stored Payment Methods must first be enabled in order to use any of the flexible payment types, since a stored payment method is needed to apply the charge.
  • Within flexible payments, One-time Scheduled Payments must first be enabled before enabling either Installment Payments or Recurring Orders.

Installment Payments and Recurring Orders are not dependent on each other; you can enable one or the other, or both. You can even use both features in a single order! For example, a constituent could have an annual membership that automatically renews each year (Recurring Orders) and within each year, it's paid in 12 monthly installments (Installment Payments).

Comparison Table of Flexible Payment Types

This table helps explain the main similarities and differences between each type of flexible payment. For more details about a specific type, navigate to the child help page for that flexible payment type.

Scenario/QuestionOne-time Scheduled PaymentsInstallment PaymentsRecurring Orders
Where can I view how many times a failed flexible payment has been attempted?Number of Retries on the schedule line record.Number of Retries on the schedule line record.Number of Retries on the schedule record.
What records are created to track the flexible payment?1 schedule and 1 schedule line1 schedule and n schedule lines (where n is the number of installments)1 schedule, plus a new schedule created after each recurrence (schedule lines are not used)
What is the Record Type of the resultant schedule record?

Payment

PaymentRecurring
What is the Type of the resultant schedule record?One TimeInstallmentRecurring
Is Order on the schedule used and what does it represent?(tick) The order being paid per this schedule. This is populated if the schedule finished. If the schedule is ongoing this will be populated if you selected Submit as An Order in the Staff View order processor or if 'Convert Cart to Payment' is enabled.  Learn More.(tick) The order being paid per this schedule. This is populated if there is at least one payment made so far. If there are no payments yet this will be populated if you selected Submit as An Order in the Staff View order process or if 'Convert Cart to Payment' is enabled. Learn More.(tick) The order being paid per this schedule. This is populated when the schedule is finished.
Is Cart on the schedule used and what does it represent??

(tick) The cart (that will eventually convert to an order) being paid per this schedule. This is populated if there is no payment(s) yet and you selected Save as Pro Forma in the Staff View order process. Learn More.

For Community Hub, this is populated if there is no payment(s) yet and 'Convert Cart to Order' is not enabled. (If 'Convert Cart to Order' is enabled, an order will be created, not a cart.)

(error) Recurring orders can only be associated with orders. However, Community Hub lets constituents opt in to recurring orders while purchasing eligible products.
Is Order Item on the schedule used?(error)(error)(tick)The order item that was paid per the previous schedule and is used as a reference when creating the subsequent order.

Is Payment Method on the schedule used? (not to be confused with Payment Method Description)

(error)(error)(tick)This determines how the next order that spawned from this schedule will be paid.
Is External Payment Profile on the schedule used?(tick)(tick)(tick) but only if Payment Method is set to Stored Payment Method.
Is Payment Method Description on the schedule used?(tick)(tick)(tick) but only if Payment Method is set to Stored Payment Method, in which case there is an External Payment Profile.

How Each Flexible Payment Type Works

One-time Scheduled Payments

When a one-time payment is scheduled, two records are immediately created to track information about the future payment:

  • Schedule: a single schedule record is created with the Record Type of Payment and Type of One Time. This schedule relates to the stored payment method that will be used to make the payment. Specifically:
    • External Payment Profile relates to the stored payment method record.
    • Payment Method Description is a convenient formulaic text field that presents the payment method summary (Ex: VISA ending in 1111)
  • Schedule Line (SL): a single schedule line record is created to track the amount and date of the future payment, and is a child record of the schedule record.

Installment Payments

Installment Payments are determined using payment frequency records and then by creating multiple scheduled payments.

Frequencies

First, staff or an administrator create one or more payment frequency records, which represent a standard installment plans you offer constituents. A payment frequency defines the occurrence, length, and number of scheduled payments to create.

Paying

When paying for a cart in installments, staff can select a payment frequency and customize the scheduled payments as needed. This creates a schedule record with multiple child schedule line records one for each installment. The schedule and schedule lines collectively represent the constituent's installment payment plan.

The schedule relates to other important records:

  • The constituent's Account.
  • The payment Frequency that was used to determine the occurrence, length, and number of scheduled payments.
  • The Stored Payment Method to be used when making each installment payment.

When the first scheduled payment is made, Nimble AMS converts the cart to an order and generates the corresponding transaction records.

Recurring Orders

What Happens at Time of Payment & Order Submission

Recurring can only be used on submitted orders, and not on carts representing a pro forma order.

When paying, staff and constituents can select how they want to pay for the products in their cart. They can use immediate payment with a stored payment method, a scheduled payment a given number of days out, or pay using installments. When staff or constituents have selected how they want to pay, they can choose if that payment should recur indefinitely for the eligible products in the order.

When they opt into a recurring order and submit the order, one or more recurring schedules are created, which tracks when each payment for the will occur:

  • If all recurring eligible products in the cart use the same frequency—like yearly—a single recurring schedule is created using that same frequency. When the order is submitted, a new recurring schedule is related to the order items with recurring eligible products.
  • If the recurring eligible products in the cart use differing frequencies—like some recurring yearly, but others monthly—when the order is submitted, multiple recurring schedules are created using the different frequencies. The schedules are related to each order item with a recurring eligible product.

Auto-Renew in Grace Period

Even if you are joining a membership whose grace period is same or equal to membership frequency, you will be able to auto renew the recurring membership in grace period.


How a Recurring Order is Stored

A recurring order is tracked using the Schedule object. While scheduled and installment payments also use the Schedule object, recurring orders use the object differently:

  • Instead of one schedule with one or more schedule lines representing each payment, recurring orders don't use schedule line records. Instead, multiple schedule records are created, one for each payment. For example, if a constituent has a monthly donation, then each monthly payment will be represented by a unique schedule record and a unique order record. 
  • As far as the schedule record fields:
    • Both the Record Type and Type are set to Recurring.
    • The Start Date indicates the payment processing date. The End Date is not used.
    • The External Payment Profileis only used if Payment Method is set to Stored Payment Method., in which case the schedule uses this External Payment Profile to make the payment.
    • The Order Item links to the order item of the previous schedule's order, not the order item that is/will be paid by this schedule. The schedule simply uses Order Item as a reference to know how to create the next Order in the sequence.
      • For example, if it's December, then a monthly recurring schedule record for the current month (December) links to an Order Item that was paid in the previous month (November).
    • The Order links to the order that was generated and paid on this schedule's Start Date. This means the order record doesn't exist prior to the Start Date.
      • For example, let's say it's December 1st, and there is a monthly recurring order. If there is a schedule for the previous month with a Start Date of November 16th, then it will be linked to an Order that was created and paid on November 16th. The December 16th schedule was also created on November 16th, but the December 16th order is not created until December 16th, so if you view the December 16th schedule prior to December 16th, Order will be blank.

How Recurring Orders are Processed

Since a recurring order is a future payment, a scheduled job runs automatically—typically nightly—to process them. When payment recurs—based on the recurring schedule's Start Date, Nimble AMS creates a new order for all the schedules having current or past date and ongoing status for order items containing the recurring eligible products from the original order. Dates are adjusted for time sensitive products, products are repriced if configured, and a new payment(s) is made, depending on the selected payment method when recurring was enabled. Learn more about Payment Processing.

How Recurring Order Repricing Works

In case of recurring orders, recurring orders can be configured to be repriced by the administrator. As an example, if any recurring memberships, donation, etc. are repriced, Nimble AMS gives the association the choice of repricing a recurring product or keeping the product price as original. See setup repricing for a recurring product to learn how to do this.

A Diagram of the Recurring Order Records and Relationships

There's quite a cast of records and automation involved here, so let's use an example scenario and a diagram. Let's say Maria Gomez, part of the membership team at ISEN, creates a monthly Professional Membership on December 14th for a constituent named Michael Hartzler. A couple weeks later, Michael tells Maria he loves the membership perks and asks her to set it to automatically recur. She sets that up for him on December 30th. At the beginning of the new year, ISEN increases their membership rates, so the price changes from $15 to $20, and ISEN has configured their org to reprice orders for recurring products.

This diagram shows a timeline of this scenario from December 14th through February 14th. The boxes represent records, and they lie directly below the date they are created:

Some additional notes about this diagram:

  • Schedule 0000000 calculates to have a Start Date of January 14th by taking the Order Item Transaction Date and adding the product's Recurring Frequency to it (which in this case is Monthly). So December 14th + one month = January 14th.
  • Maria could technically set Order Item 0000000 to recur after the December 14th to January 14th window, but the nightly job runs in the early morning of January 14th. So if she sets it to recur on, say, January 17th, the schedule does get created but with a start date in the past, namely January 14th. But, she doesn’t need to manually reschedule it to January 18th. When the job runs on January 17th, it will pick up the pending schedule with start date of 14th Jan and process it that day.
  • Repricing doesn't always necessarily happen this way. It depends on the association's configuration of flexible payment repricing. 
  • This example assumes no grace period for the monthly membership. In general, staff should not recur an order item for a membership that has lapsed, since that is now beyond the grace period and should be treated as a Join again. Instead, a new order should be processed. This is because a recurrence of a lapsed membership may have unexpected results, such as starting the day after the lapsed membership's end date.
  • With the exception of the membership Join/Renew process, constituents don't have a large window in which to commit an order to auto-renewal, like staff do. They can opt in to auto-renew (i.e., recur) only while they are paying for an order with an eligible product(s).
  • Constituents cannot auto-renew a past donation. Instead, they should submit a new donation and set that to auto-renew.

More Details on Flexible Payments

Learn more information that pertains to all flexible payment types such as default email communications and where flexible payments are used in Community Hub.

Default Email Notifications for Flexible Payments

Nimble AMS includes default email templates that are deployed on request by Nimble AMS Support that provide information to constituents about their scheduled, installment, or recurring payments. Nimble AMS also provides default (Process Builder) processes that are available that automatically send these emails once activated.

Community Hub Pages Supporting Flexible Payments

Assuming permission has been granted, constituents can create and manage flexible payments on several pages in Community Hub.

What about the Classing Recurring Membership Functionality?

We recommend using Flexible Payments because it is much more robust, but if you're using the classic recurring membership functionality in Nimble AMS, learn more in the Creating a Payment Schedule for a Recurring Membership Success Guide.