Offer and create payment plans

#Know which payment-plan path you are using

Warning: Do not assume that choosing any control labeled Payment Plan creates a complete installment agreement. Confirm the charge, immediate payment, purchase, scheduled-payment rows, payment source, agreement, and processor result as separate records.

Current safe operating guidance: Use the Sales Item path only after a fictional Online Client checkout proves the complete result for the studio's processor. Treat both staff-cart payment-plan controls as controlled-test features until the amount and schedule they create have been reconciled against the intended agreement.

#Before you begin

• Write down the item full price, first payment, fee, number of future payments, recurring amount, first future date, and cadence.
• Decide whether the fee is added to the item price or included within the advertised total.
• Confirm which Sales Item, student, class or service, purchase category, and charge category apply.
• Use a fictional family and a non-live processor account while testing.
• Add an eligible saved card or ACH source when the future rows must have an automatic payment method.
• Prepare approved agreement language separately; do not rely on the Payment Plan Contract field until its checkout behavior has been verified.
• Coordinate with finance so nobody processes the same obligation through tuition, auto payments, a membership, or another schedule.

Important: A scheduled payment is a future instruction. It is not a completed charge, a processor approval, a payment, or a settlement.

#Calculate an offered Sales Item plan

For the current Online Client Sales Item path, use this formula:

total obligation = first payment + payment-plan fee + (repeats × recurring amount)

In this path, Repeats is the number of later scheduled-payment rows. It does not include the first payment shown in the cart and collected or recorded at checkout.

For example, suppose an item has a full price of $300 and the studio intends to add a $10 plan fee:

The first checkout line is $70: the $60 first payment plus the $10 fee. The current Online Client confirmation describes the remaining obligation as three later payments of $80.

The software displays the item full price while you define the plan, but it does not currently require the formula to equal that price or that price plus the fee. Calculate it independently before adding the plan.

Warning: The current save validation accepts numeric monetary values without enforcing a nonnegative minimum. Never use a negative first payment, recurring amount, or fee. Blank monetary fields are saved as zero.

#Define a plan on a Sales Item

#Prepare the Sales Item

1. Open Settings > Sales Items.
2. Open the intended item, package, or other supported Sales Item.
3. Confirm its Item full price, sale restrictions, assigned classes, Online Client availability, activation, expiration, tax, fees, and included uses.
4. Open Activation and Expiration and confirm After Expiration is not set to auto renew.
5. Save the Sales Item before opening Payment Plans.

Payment plans and Sales Item auto renewal are mutually exclusive in the current editor. Adding a plan is blocked while auto renewal is active, and enabling auto renewal is blocked while payment-plan rows exist.

#Enter the plan

1. Open Payment Plans.
2. Compare Item full price with your written calculation.
3. Enter the one-time Payment Plan Fee.
4. Enter First Payment. This amount and the fee form the line price due at Online Client checkout.
5. Enter Repeats, meaning the number of later scheduled payments.
6. Enter a future Start Date for the later schedule.
7. Enter Recurring Amount for each later payment.
8. Select Schedule.
9. If applicable, select Payment Plan Contract only after reading the contract limitation below.
10. Recalculate the full obligation.
11. Select Add Payment Plan once.
12. Confirm that the plan appears under Assigned Payment Plans with the expected fee, first payment, repeats, start, recurring amount, and schedule.

Available schedule choices can include a day of the month, the last day of the month, every 14 or 30 days, two dates each month, a weekday, or a quarterly boundary. The exact choices can vary by release and studio schema.

Important: Use an explicit future Start Date. In the current Online Client purchase path, a valid future date is used as the schedule anchor. A blank, invalid, current, or past date falls forward according to the schedule, often to the following week or month. The schedule engine can then align that anchor to its configured weekday or day of month.

#Contract limitation

The editor saves the selected Payment Plan Contract page ID. The inspected Online Client plan payload, cart details, checkout-agreement loader, confirmation, and staff-cart plan loader do not currently carry or enforce that plan-specific contract.

The assigned-plan table also does not show the saved contract after the plan is added. Therefore, the visible plan row is not proof that a client will be asked to acknowledge or sign that page.

Warning: Do not advertise a plan as contract-backed merely because a page was selected in this field. Verify agreement display, required signature or acknowledgement, signed-record storage, and later retrieval with a fictional client. Until that is proven, use a separately tested agreement process approved by the studio's policy owner.

#Offer the plan in Online Client

An offered plan appears when the Sales Item participates in a supported class-purchase or package-purchase choice and the client is eligible for it.

1. Assign or expose the Sales Item through the intended Online Client purchase path.
2. Confirm the item's sale window, visibility, Sell Online, Sell Individually, member-category rules, and class or package assignment.
3. Sign in as a fictional eligible client.
4. Select the intended student and class, package, or item.
5. In the purchase options, compare Pay in full with each available Payment Plan choice.
6. Select the plan and continue to the cart.
7. Confirm the cart shows First Payment, the plan fee, repeats, recurring amount, and schedule.
8. Continue to checkout and review the same plan summary on the item line.
9. Select the intended saved payment source when the future schedule must collect automatically.
10. Do not also turn on the checkout-level Set up a payment plan control. That would create a second schedule for the remaining checkout balance rather than select the Sales Item plan.
11. Complete the controlled checkout once.

Pay-in-full availability is schema-dependent. Current purchase-option code honors an existing Sales Item pay-in-full flag, but the inspected current Sales Item editor does not expose that flag. If the choice differs from the intended offer, stop and have the Sales Item configuration reviewed rather than guessing from the client screen.

#What the Online Client path creates

When the selected plan completes successfully, the current path is designed to produce these layers:

Important: The current line-plan scheduler catches a schedule-creation error and logs it instead of necessarily failing the checkout. A successful order confirmation therefore does not prove that all future rows exist.

#Confirm the Online Client result

1. Read the order confirmation and record the order number, first-payment amount, fee, repeats, recurring amount, and schedule.
2. Open the client's ledger and confirm the order charge and immediate payment allocation.
3. Check the processor for the immediate attempt and non-sensitive transaction reference.
4. Open Finance > Scheduled Payments.
5. Filter for the fictional family and a date range that includes every expected installment.
6. Count the rows and compare every date and amount with the plan worksheet.
7. Confirm each row links to the expected purchase or Sales Item.
8. Confirm the displayed payment method is the intended masked card or bank account. Not assigned. Add to Account means the future row does not currently have a usable saved-source summary.
9. Sign in as the fictional client and open the Online Client Scheduled Payments finance tab. Confirm the client can see each upcoming date, purchase, amount, method, and status.
10. Confirm the agreement or signed record separately when one is required.

Do not make the offer generally available until all ten checks agree.

#Understand the two staff Shopping Cart controls

#The item-level Payment Plan selector

Some staff-cart item cards and expanded rows show Payment Plan with Pay in full and one or more plan choices. The current loader uses only:

• plan ID and optional name;
• first-payment amount; and
• payment-plan fee.

Selecting a plan changes the cart line price to first payment + fee. It does not load that plan's repeats, recurring amount, start date, schedule, or contract into staff checkout. The current staff checkout normalization also does not turn that selected plan ID into future scheduled rows.

Warning: Selecting a Sales Item plan in the staff cart is not currently a complete replacement for the Online Client plan workflow. It can create an ordinary charge and purchase at the first-payment total without creating the defined later payments.

Availability is also schema-dependent. The current staff loader requests a plan Name, while the standard plan editor neither asks for a name nor shows one in its assigned table. On a schema without that column, the staff cart can return no item-level plans even though the Sales Item editor lists them.

#Apply payment plan at staff checkout

The checkout page can show Apply payment plan in a card-oriented payment flow. It creates a new schedule for the whole checkout and does not read the selected Sales Item plan.

When enabled, staff can enter:

• a repeat count;
• a schedule;
• a start date; and
• a payment source through the checkout payment controls.

The displayed installment amount is calculated as:

checkout grand total ÷ repeats

The current submit path then treats the Amount payment field as the immediate payment and, when repeats is greater than one, creates repeats future scheduled rows at the displayed installment amount. Changing Amount does not recalculate the displayed scheduled amount, which remains based on the grand total.

For a $300 checkout with three repeats, the screen displays $100 per scheduled payment. The current code can still submit an immediate Amount of $300 and create three later $100 rows. If staff reduce the immediate Amount to $100, the path can create that $100 payment plus three later $100 rows. Neither result automatically reconciles to a three-installment $300 agreement.

Warning: This amount/count boundary can overstate the intended collection. Do not submit a production staff-checkout plan until product review and a controlled processor test establish the intended meaning of Amount and Repeats for the installed release.

Other current staff-path limits include:

• Apply payment plan is hidden outside the card-oriented checkout view, even though stored sources can include other tender types elsewhere;
• one repeat does not create future scheduled rows;
• a newly entered source may not provide a numeric stored token to the schedule, so use a controlled saved test source when verifying;
• the plan has no fee or contract field;
• multi-item checkout creates one whole-order schedule, and purchase linkage can be ambiguous; and
• the staff success result can complete even when no usable scheduled-payment IDs are returned, so reconciliation is mandatory.

#Controlled staff-path verification

Use this sequence to document behavior, not to establish a live client obligation:

1. Use a fictional family, one student, one Sales Item, and a non-live processor account.
2. Remove discounts, tax, convenience fees, registration fees, split tenders, account credit, gift cards, and unrelated cart lines.
3. Write down the cart grand total and the intended immediate and future totals.
4. Add the item at full price. Do not combine the item-level plan selector with checkout-level Apply payment plan in the same test.
5. Proceed to checkout and select a saved fictional payment source.
6. Record the Amount field before changing anything.
7. Turn on Apply payment plan and enter repeats, schedule, and start date.
8. Record the displayed payment amount and calculate immediate Amount + (repeats × displayed plan amount).
9. Stop before Checkout if that total differs from the intended obligation.
10. If an authorized product owner approves a non-live commit test, submit once and immediately reconcile the order, charges, payment, purchase, scheduled rows, source, and processor test result.

Do not infer production safety from the checkout success message alone.

#Edit or stop a plan

#Change an offered Sales Item plan

The current Sales Item screen can add and delete plans; it does not provide an edit action.

1. Record the existing plan's full worksheet and any clients who have already purchased it.
2. Create and test the replacement plan before changing availability.
3. Remove the old plan only after confirming that no new client should select it.

The trash action removes the definition used for future choices. It does not edit or delete existing purchases, charges, payments, scheduled-payment rows, enrollments, entitlements, processor transactions, or signed records.

Warning: The current delete control does not present a separate confirmation step in the inspected interface. Select it only when you intend to remove that offer.

#Change an existing client's future rows

Open Finance > Scheduled Payments and review the exact family, purchase, date, amount, method, and status. An authorized user can edit, pause, or delete supported rows, subject to the installed schema and permissions.

Changing one future row does not rewrite the original Sales Item definition. Deleting a scheduled row does not refund the first payment, cancel the purchase, remove an enrollment, restore inventory, end a membership, or remove the underlying account obligation.

The Online Client Scheduled Payments page is currently read-only. Clients can review upcoming rows but cannot use that page to revise the plan.

#Recover from a failed or uncertain payment

1. Stop all retries.
2. Record the family, order, purchase, schedule ID, date, amount, masked method, status, visible message, and time.
3. Check the processor before deciding whether the attempt failed or remains uncertain.
4. Check Finance > Payment History and the account ledger for a local payment and allocation.
5. Check Finance > Scheduled Payments for Processing Error, Failed, Paused, On Hold, Complete, or other relevant state.
6. Confirm later schedule rows and the original purchase remain correct.
7. Follow the processor- and product-specific recovery procedure approved by finance.

The current global Scheduled Payments page does not expose a general retry action. Do not duplicate a row or record a manual payment merely to make the balance look correct.

#Troubleshooting

#Payment Plans says to save the item first

Save the base Sales Item, then reopen Payment Plans. Plan rows need the saved Sales Item ID.

#Payment Plans is locked

Open Activation and Expiration and turn off auto renewal. Current configuration does not allow both features on the same Sales Item.

#The plan total does not match the offer

Recalculate first payment plus fee plus repeats times recurring amount. The editor does not enforce a match. Delete and recreate the plan rather than asking staff or clients to interpret an unexplained difference.

#The plan does not appear in Online Client purchase options

Confirm the Sales Item assignment, type, sale dates, Sell Online, Sell Individually, visibility, client/student eligibility, season state, and pay-in-full setting. Also confirm the plan row still exists and the client is using a supported purchase-options path.

#The plan appears online but not in the staff Shopping Cart

The staff catalog currently filters for active, visible, Online Client-sellable items, and its plan loader expects fields that can differ by schema. This is a known path difference, not proof that the Online Client plan was deleted.

#Checkout shows two payment-plan controls

The item summary describes the Sales Item plan. Set up a payment plan or Apply payment plan creates a separate checkout-level schedule. Do not turn on the second control unless a specifically tested workflow requires it.

#Checkout succeeded but future rows are missing

Do not repeat checkout. Confirm the order, immediate payment, processor result, purchase, and Scheduled Payments date range. Escalate with non-sensitive IDs; the line-plan path can complete even when schedule creation fails.

#Future rows show Not assigned

The schedule was created without a resolvable saved source. Confirm client authorization and the intended processor account before assigning or recreating anything. A stored method on the family does not automatically prove that each existing scheduled row uses it.

#A scheduled payment failed

Use the failed-payment recovery steps above and the Scheduled Payments guide. A decline is not a payment, and an uncertain attempt must not be retried until the processor result is known.

#Related articles

• Set up and manage auto-renewing memberships
• Respond to a failed scheduled payment
• Create a Sales Item
• Assign Sales Items and pricing options to a class
• Sell an item with the staff Shopping Cart
• Scheduled payments and scheduled charges
• Cards and ACH
• Review payment history and make corrections
• Pages, agreements, waivers, and contracts
• Register for classes
• Complete checkout
• Understand your order result