Set up and manage auto-renewing memberships

#Before you begin

Write down the complete offer before changing the Sales Item:

what one renewal cycle provides;
whether the offer belongs to the family account or one student;
the cycle length and the date on which renewal should be attempted;
the number of renewals, excluding the original purchase;
the price for every renewal;
the saved payment method or charge-to-account policy;
what happens after a decline;
how a hold, cancellation, or termination affects billing and access;
the Member Category, classes, videos, discounts, reports, and messages that use the membership; and
the contract language and notice required for renewal and price changes.

Prepare a fictional account, student, Sales Item, Member Category, and processor test method. Keep Sell Online set to No until the entire lifecycle has been verified.

Warning: Auto renewal can initiate an off-session payment and create a new charge and purchase. Do not test a due renewal with a real payment method or a live client account.

Important: The current Auto Renew control is finite. Auto Renew Times must be greater than zero, and the software uses scheduled-payment rows to enforce the limit. It is not the same feature as an until-cancel subscription.

Important: A renewal purchase, account payment, processor transaction, scheduled-payment row, Member Category, class entitlement, and message are separate records. A successful change to one does not prove the others are correct.

#Choose the correct recurring model

Several controls can look like recurring membership billing. They are not interchangeable.

Model	Where it begins	What it is designed to do	Relationship to this article
Auto Renew	Sales Item Activation and Expiration > After Expiration	Schedule a renewal at purchase expiration; a successful attempt creates another purchase and the next scheduled row	This article
Sales Item Payment Plans	Sales Item Payment Plans	Offer installments for one purchase obligation	The editor prevents these plans from being combined with Auto Renew
Staff checkout payment plan	Staff Shopping Cart checkout	Split the whole checkout into staff-entered future amounts	A separate control that can still be applied to an Auto Renew item; do not combine them
Subscription or recurring settings	Sales Item Additional and the Online Client Subscribe flow	Present a recurring schedule, remaining-payment count, or until-cancel offer through the separate recurring-payment model	Manage separately; it does not use the Auto Renew lifecycle described here
Manually created scheduled payment	Account or finance tools	Create one future collection instruction	Does not become an Auto Renew chain merely because it has a repeating-looking date

The Sales Item editor locks Payment Plans while Auto Renew is selected and refuses to enable Auto Renew while item-level plans exist. That protection does not cover the separate plan offered in the staff Shopping Cart.

Warning: Do not select a staff checkout payment plan for an Auto Renew Sales Item. In the reviewed flow, the checkout plan rows can later be linked to the same purchase and Sales Item. The scheduled-payment processor can then classify those installment rows as Auto Renew rows and create unintended renewal purchases.

See Offer and create payment plans for the distinction between the plan controls.

#Understand the current lifecycle

The ordinary path is:

A client or staff member completes the original sale.
The software creates the purchase and calculates its activation and expiration dates.
If After Expiration is Auto Renew, Auto Renew Times is greater than zero, and the purchase has an expiration date, the software creates one active scheduled-payment row dated for that expiration.
On the due date, scheduled-payment processing claims the row before attempting collection.
A successful processor result creates a local payment, a renewal purchase, an Auto renewal charge, and—when more renewals remain—the next scheduled-payment row.
A processor decline marks the current row as an error and does not create the renewal purchase or next row.

The next renewal is not prebuilt as a complete series. The successful processing of one row creates the next row.

Record	Initial sale	Successful renewal	Failed renewal
Purchase	Original entitlement	New purchase with new units and dates	No new purchase
Scheduled payment	One row dated at the original purchase expiration	Current row completes; next row is created when the limit allows	Current row becomes an error; no next row
Processor transaction	Depends on checkout	Off-session attempt when a usable saved method is assigned	Decline or uncertain result must be checked at the processor
Local payment	Depends on checkout	Created after processor approval, except a fully credit-covered or charge-to-account path	Not created for an ordinary decline
Charge	Original checkout charge	New charge labeled as an Auto renewal	Not created for an ordinary decline
Member Category	Separate assignment	Not extended or recreated	Not changed
Access	Determined by purchase, category, class, and content rules	Must be verified from the new purchase and separate category	Does not automatically enter or leave a grace period
Message	Depends on other configuration	No dedicated renewal-success message was found in the reviewed path	A configured card or ACH decline trigger may notify the client after a gateway decline

#Scheduled timing

The reviewed application schedule runs the Auto Renew materializer daily at 5:15 a.m. and scheduled-payment processing daily at 5:30 a.m. in the application scheduler's time zone. Both jobs use non-overlap locks for their own command.

The materializer looks for Auto Renew purchases whose expiration is on or before the selected date and creates a missing row when it can resolve a positive amount and saved token. The ordinary 5:30 payment run processes rows dated exactly that day; it does not include earlier overdue rows by default.

This creates important operational boundaries:

a row created late with a past payment date can remain unprocessed;
a row moved to today after the daily payment run can be missed;
the ordinary run processes at most 100 rows per studio per day in the reviewed schedule;
the materializer examines at most 500 due purchases per studio per day in the reviewed schedule; and
an interrupted or disabled scheduler can leave a purchase, schedule, and access out of step.

Before launch, the system administrator should confirm the application time zone, scheduler heartbeat, scheduled-payment safety setting, queue health, daily volume, and an approved overdue-recovery procedure. Studio staff should not run command-line catch-up or processor retries unless that responsibility has been assigned to them.

#Design a safe one-cycle Sales Item

For the first controlled implementation, use a self-contained Item whose units, class assignments, price, and period describe one cycle.

Do not assume that an Auto Renew Package or Bundle rebuilds its included contents. The reviewed renewal routine creates one new purchase and automatically assigns compatible unpaid lessons only when the renewed purchase is an Item. It does not recreate package-component purchases. Treat package or bundle renewal as unverified until a controlled test proves every included entitlement.

Choose a period-based expiration such as one month from purchase. Avoid these configurations until their renewal results have been explicitly approved:

Never Expire, because it schedules renewal at the software's distant never-expire date;
a fixed Expiration Date, because each renewal can reuse that same fixed date instead of advancing the term;
First Visit activation when a predictable billing anchor is required, because the original purchase can remain undated until a qualifying schedule assignment exists; and
a zero or blank expiration quantity, because it can be normalized to the never-expire date.

Important: On renewal, the new purchase activates from the scheduled row's recurring date, then its payment date, then today as a fallback. It does not repeat every original activation choice. Test the date boundary rather than assuming First Visit or a selected activation date will carry forward.

#Set up the membership

#1. Create the supporting category and agreement

Open Settings > Categories.
Create the Member Category that identifies the membership, if it does not already exist.
Create or review the required contract under Settings > Pages.
Document the renewal count, renewal date, price sequence, failed-payment result, cancellation process, and access result in the approved agreement.

The category is an identity and eligibility record. It does not itself create a purchase or collect money.

See Create and maintain categories and Manage pages, agreements, waivers, and contracts.

#2. Create the base Sales Item privately

Open Settings > Sales Items.
Select Add New.
Choose Item for the first controlled workflow.
Enter a client-ready name and description.
Enter the one-cycle price and choose the correct units.
Assign the intended classes and purchase and charge categories.
Add the approved contract.
Under Purchase Restrictions, set Sell Online to No.
Save the Sales Item, then reopen it.

The base record must exist before pricing tiers and other child records can be added.

#3. Set activation, expiration, and renewal

Open Activation and Expiration.
Under Activation, choose the approved start rule. Use Sale Date for the most predictable first implementation.
Under Expiration, choose On Purchase, enter the quantity for one cycle, and select Days, Months, or Years.
Under After Expiration, select Auto Renew.
Enter Auto Renew Times.
Select Auto renew when units are 0 only when exhausting the entitlement should move the pending renewal attempt to the current date.
Choose Auto Renew Price.
Select Save Sales Item.

If Auto Renew Times is 12, the implementation can create up to 12 scheduled renewal rows after the original sale. The limit is enforced by counting rows linked to the original purchase, not by counting only successful processor settlements.

Warning: A paused, failed, manually added, or otherwise unusual linked row can affect the count. Deleting a row can reduce the count and allow a missing row to be materialized again. Reconcile the complete chain before changing any row.

#4. Choose and verify the renewal price

Selection	Current calculation	What to verify
Use item price	Uses the Sales Item's configured price	Discounts, cart overrides, taxes, and fees are not folded into this value
Use first purchase price	Uses the earliest positive linked charge found for that account and Sales Item; otherwise falls back to item price	The earliest purchase may not be the test sale or the intended student's purchase
Use dynamic pricing	Expands active Pricing rows by quantity and uses the next position in that sequence; after the sequence ends, repeats the last tier	Tier order, quantities, total renewal count, and current saved row amount

The first scheduled amount is stored when the initial schedule is created. Later amounts are calculated when the preceding renewal creates the next row. Changing the Sales Item price or pricing tiers therefore does not rewrite an already existing scheduled row, but it can change a later row that has not yet been created.

For dynamic pricing:

Select Use dynamic pricing and save the main Sales Item form.
Open Pricing.
Enter Quantity and Price for the first renewal tier, then select Add.
Add each later tier.
Set the intended order and save the pricing order.
Confirm that the sum of tier quantities covers Auto Renew Times, or document that the last tier will repeat for the remainder.

For example, a first row of quantity 2 at $80 followed by quantity 3 at $85 produces two scheduled renewals at $80, then three at $85. If more renewals are allowed, the reviewed calculation continues using $85 after the defined rows are exhausted.

Warning: The renewal routine does not rerun ordinary checkout pricing. It does not recalculate coupons, member-category rates, cart discounts, tax, registration fees, additional items, or contract acceptance. The reviewed renewal charge records tax as zero, while an optional scheduled-payment convenience fee can be processed and recorded separately. Confirm the studio's accounting and legal requirements before launch.

#5. Keep conflicting billing controls empty

Open Payment Plans and confirm that the tab is locked while Auto Renew is active.
Confirm that no earlier item-level plan remains.
Review Scheduled Payments on the Sales Item and remove any unapproved extra schedule definitions.
Review the separate recurring fields under Additional. Do not configure them as a second renewal mechanism for the same offer.
In the staff Shopping Cart, do not apply a checkout payment plan when selling this item.

Auto Renew should have one intended future row after the original sale. Extra rows can change the renewal count, dynamic-price position, and number of purchases created.

#6. Test the original sale with a controlled account

Use a fictional account and student.
Confirm that the account has the intended active test payment method. Show only the method type and masked last four digits in review notes.
Add the private Sales Item through an authorized staff workflow or a restricted Online Client test.
Do not apply a checkout payment plan.
Complete only an approved sandbox or no-charge test.
Open the new purchase and record its ID, Date Active, Date Expire, units, Sales Item, and student.
Open Finance > Scheduled Payments.
Find the one row for the purchase and confirm its amount, payment date, status, purchase, Sales Item, and masked method.

The initial lifecycle can use a token passed from checkout, a token stored on the purchase, or an active saved method selected from the account. In the reviewed fallback, selection prefers a default method but does not require its separate Auto Pay flag. Verify the assigned method explicitly; do not infer it from the method used for the original checkout.

If no token is assigned, the linked Auto Renew row can follow the charge-to-account branch instead of collecting money. That branch can create a renewal purchase and unpaid charge, mark the scheduled row complete, and create the next row without a token.

Warning: A completed schedule with no local payment is not proof of collection. It may represent account credit or a charge-to-account renewal.

#7. Align category and access separately

Open the intended person's Main > Additional > Member Categories area.
Confirm the category, activation, expiration, termination, and status.
Add or correct the assignment only according to the approved membership policy.
Test restricted registration, video access, discounts, and sales visibility with the fictional account.

The Sales Item editor saves Set Member Categories and Unset Member Categories, but the current checkout and renewal paths reviewed for this article do not apply those fields to the account's category assignments. A successful renewal also does not extend the category expiration.

Important: Category Termination is not a universal access cutoff. Current eligibility consumers can use status, activation, and expiration without considering termination. Set the approved category expiration and verify the actual client result.

#What happens when the renewal becomes due

#If the saved method succeeds

The reviewed processor:

changes the row from active to processing so the same row is less likely to run concurrently;
applies available account credit before calculating the processor amount;
adds a configured scheduled-payment convenience fee to the processor amount when applicable;
attempts the saved method off-session;
can try an eligible alternative saved method when Try alternative payment method if recurring payment failed is enabled;
creates a local payment with source recurring_purchase after approval;
creates a new purchase with fresh units and dates;
creates and links an Auto renewal charge;
assigns the new purchase to compatible unpaid lessons for an Item when possible;
creates the next scheduled row when the row-count limit allows; and
marks the processed row complete.

The next row retains the original chain ID. Its due date is the new purchase expiration date, and its amount is calculated from the current price rule.

The new purchase uses the renewal routine's default purchase status value rather than copying a simple “active” state from the source purchase. Current lists and reports interpret purchase status and dates differently, so verify the dates, units, access, and ledger instead of relying on one status label.

#If account credit covers the renewal

The processor can apply available account credit before charging a saved method. When account credit covers the full amount, the routine can:

skip the gateway;
create the renewal purchase and charge;
apply credit to the charge;
create the next row; and
complete the scheduled row with no new local payment record.

Reconcile the credit allocation and remaining account credit. A zero payment ID can be expected in this branch, but the renewal charge and purchase must still be present and correct.

#If no token is assigned

A purchase-, Sales Item-, or charge-linked row with no token is treated as eligible to add to the account. For Auto Renew, this can create the renewal purchase and charge without collecting funds, complete the row, and continue the chain with another tokenless row.

Use this result only when the studio has explicitly approved charge-to-account renewal. Otherwise, pause the next row and correct the source before another cycle becomes due.

#If the processor declines

The current row becomes an error. The routine does not create the new purchase, renewal charge, or next scheduled row. It also does not change Member Category access.

A configured CREDIT_CARD_DECLINE or ACH_DECLINE trigger may send a message after an actual gateway decline. Notification still depends on the trigger, template, provider, recipient data, and delivery runtime.

See Respond to a failed scheduled payment before retrying or changing the row.

#If local work fails after processor approval

The gateway call occurs before the local payment, charge, purchase, allocation, and completion writes finish. A later local error can leave the scheduled row marked as failed even though the processor approved the charge.

Warning: Do not reactivate or recreate that row until the processor, payment history, ledger, renewal purchase, and charge have been reconciled. Retrying can create a second external charge.

#If units reach zero early

When Auto renew when units are 0 is selected, a purchase-usage recalculation can move an active future Auto Renew row's payment date and recurring date to today after all configured lessons, hours, or credits are used.

This does not immediately process the row. If the date is moved after the daily run, the ordinary next-day run will not select it because that run uses an exact date. Use this option only with an approved same-day monitoring and recovery process.

#Change or end an individual Auto Renew chain safely

There is no single current action that simultaneously stops billing, ends the purchase, expires the category, removes access, changes enrollment, refunds money, and confirms the client message.

#Stop future billing for one account

Record the client's request, authorization, effective date, and policy.
Capture the current purchase ID, original-chain ID when available, next scheduled row, amount, due date, status, masked method, category dates, access, balance, and latest processor result.
In Finance > Scheduled Payments, locate every row associated with the account, purchase chain, and Sales Item.
Pause the one active future Auto Renew row.
Reload the list and confirm that it appears as Paused.
Confirm that no second active, failed-to-be-retried, or manually added row can continue the chain.
Apply the approved purchase, category-expiration, enrollment, access, balance, refund, and communication actions separately.
Recheck the account after the next materializer and scheduled-payment window.

Keeping the intended stop row paused preserves an audit record and causes the current missing-row check to see that a row already exists for the purchase. Deleting it can allow a replacement row to be created when the purchase is due.

Warning: Do not rely only on Cancel Purchase. The reviewed Auto Renew materializer does not filter the purchase's current status when finding due rows.

Warning: Do not rely only on category termination. A narrow materializer check can skip a due purchase when a matching configured category has a qualifying termination date, but checkout may never have created that category assignment, and other access consumers do not use termination consistently.

#Retire the offer for everyone

Set Sell Online to No to stop new Online Client sales.
Inventory every existing purchase chain and future row before changing the Sales Item.
Pause or otherwise end each future row according to policy.
Reconcile balances, purchases, categories, access, and client notices.
Only then change After Expiration, archive the item, or replace it with a new offer.

Changing After Expiration to Do Nothing does not remove an already created scheduled row. That row can still be processed as an ordinary scheduled payment even though it no longer creates a renewal purchase. Archiving or hiding the Sales Item also is not an individual billing cancellation in the reviewed processor.

#Resume a paused chain

Before resuming:

confirm the authorization and new effective date;
check whether the row's payment date is in the past;
compare Payment Date with the separate recurring anchor date;
confirm the amount and saved method;
confirm that no replacement row or manual payment already exists;
confirm access and category dates; and
use an approved processor and overdue-recovery procedure.

Editing Payment Date does not update the separate recurring date in the current mutation service. The renewal purchase can therefore remain anchored to the earlier recurring date. Do not improvise a date move for a live chain.

#Messages and client communication

Auto Renew does not provide a complete client-communication lifecycle by itself.

The reviewed renewal processor does not send a dedicated success email or receipt.
No current checkout or renewal consumer of the Sales Item Email Template field was found in the reviewed source.
A gateway decline can call a configured card or ACH decline trigger.
An unavailable token fails before the gateway-decline notification branch.
A tokenless charge-to-account renewal is not a decline and does not send a decline notice.
A local failure after gateway approval is logged and marks the row failed, but does not call the decline notification branch.
Member Category messaging can use different date and status rules from access and billing.

Design separate, approved messages for original purchase confirmation, upcoming renewal notice, price change, successful renewal, decline, charge-to-account balance, cancellation, and access end. Preview recipients and reconcile the financial result before sending a manual success or failure message.

See Configure scheduled triggers and Messaging overview.

#Confirm it worked

After the original sale, confirm:

one original purchase with the intended student, units, activation, and expiration;
one intended future Auto Renew row;
the correct amount, due date, status, and masked saved method;
no staff checkout-plan rows and no duplicate schedule;
the correct contract record from the original checkout;
the intended Member Category assignment and dates; and
the correct Online Client access for an eligible and ineligible fictional account.

After a controlled successful renewal, confirm:

one processor approval with a non-sensitive reference;
one local payment when a gateway payment was expected;
one renewal charge and payment allocation;
one new purchase with reset units and correct dates;
assignment to only the intended unpaid lessons;
one next scheduled row when renewals remain;
the expected price tier and recurring anchor;
no unexpected tax, fee, extra item, package component, discount, or second renewal;
the separately maintained category and client access; and
the intended message or documented absence of one.

After a controlled decline, confirm:

the processor result;
one failed row and no duplicate attempt;
no renewal purchase, charge, payment, or next row from that attempt;
the intended category and access policy; and
delivery or documented absence of the decline message.

#Reconcile every renewal

Use this order when the result is unclear:

Check	Expected evidence	Stop and escalate when
Processor	One approved, declined, or absent attempt for the expected amount	Approval exists but local state says failed, or more than one attempt exists
Scheduled row	Correct date, amount, method, status, and payment link	Row is processing indefinitely, complete with unexplained state, or duplicated
Payment history	One local payment for a gateway success; none for a decline	Processor and local payment disagree
Ledger allocation	Payment or credit applied to the intended renewal charge	Payment is unapplied, overapplied, or linked to another charge
Renewal charge	Correct amount and Auto renewal note; separate convenience fee only when approved	Tax, fee, amount, or payment link is unexpected
Renewal purchase	One new purchase with the intended student, units, dates, and Sales Item	Package contents are absent, dates overlap incorrectly, or multiple purchases exist
Next row	One row at the new expiration when more renewals remain	Wrong amount, wrong anchor, no method, or count ended early
Category and access	Approved category dates and expected registration/content result	Payment succeeded but access did not, or access continues after the approved end
Message	Intended notice only, with correct recipient	Client was told success before reconciliation or sensitive data was exposed

Do not correct an uncertain processor result by adding a local payment, deleting the row, or running it again until the external transaction has been identified.

#Troubleshooting

#Auto Renew is selected, but no scheduled row appears

Check Auto Renew Times first. A value of zero produces no initial schedule. Then confirm that the purchase has a valid expiration date, the scheduled-payments table is available, and no row already exists for the purchase.

For First Visit activation or expiration, confirm that a qualifying schedule has been assigned. The lifecycle can leave both dates empty until that relationship exists.

Review application logs for sales_item_lifecycle_sync_failed or sales_item_auto_renew_schedule_failed. Do not create a live replacement row until its amount, token, purchase link, and original-chain link are understood.

#The row is due but was not processed

Confirm:

the row is active and unpaid;
its payment date equals the date processed by the ordinary job;
the account is not in a qualifying hold interval;
the amount is greater than zero;
scheduled-payment processing is enabled for the studio;
the daily limit was not exhausted;
the scheduler completed; and
no earlier run claimed the row into a processing state.

An overdue row is not automatically included by the ordinary daily run. Escalate for an approved dry run and catch-up procedure.

#The row says complete, but there is no payment

Check for a fully account-credit-covered renewal or a tokenless charge-to-account renewal. Confirm the renewal charge, credit allocations, balance, new purchase, and next row. Do not describe the renewal as paid unless the ledger proves it.

#The renewal amount is wrong

Confirm the amount already stored on the current row. Then review Auto Renew Price, the current Sales Item price, the account's earliest qualifying purchase charge, dynamic-tier order and quantities, and the number of rows already linked to the original chain.

A cart override, discount, coupon, tax, or manually edited scheduled amount is not automatically the price of the following renewal.

#The next renewal date did not move after an edit

The renewal uses the separate recurring date before the visible payment date. Editing Payment Date alone does not change that anchor. Pause the row and use an approved recovery procedure.

#The category did not renew

That matches the current separation. Successful renewal creates purchase and finance records but does not extend the Member Category. Update the category only under the approved membership procedure, then test every access consumer.

#A cancelled purchase was materialized again

Pause the resulting row before it can process, reconcile whether any attempt occurred, and escalate. The reviewed materializer selects due purchases by Sales Item and expiration without filtering purchase status.

#Deleting the future row did not cancel renewal

A missing due row can be created again. Use a paused audit row for the individual chain and complete the separate purchase, category, access, and communication ending steps.

#A staff checkout plan created extra rows

Do not let the rows process. Pause the affected rows, identify which belong to installments and which is the intended renewal row, and reconcile their purchase, Sales Item, charge, and original-chain links with finance support. Do not delete or relink rows to make the list look correct.

#The processor shows success, but the scheduled row shows failure

Treat this as a possible post-processor local-write failure. Stop. Check the processor, local payment, allocation, renewal charge, renewal purchase, convenience-fee charge, and next row. Do not reactivate the failed row.