Place membership payments on hold and resume safely

Current implementation boundary: Finance > On Hold Payments can list, edit, and remove an existing dated hold, but the reviewed current page has no Add Hold control. Do not substitute a one-row Pause, move a payment date, or change membership dates unless that is the separately approved outcome. A new dated hold needs an authorized product or support path until a current creation control is restored or documented.

#Choose the correct control

The word hold can refer to several different actions. Confirm the requested outcome before changing anything.

Warning: A one-row pause is not a membership hold. A dated hold is not a cancellation. Removing either control does not collect a missed payment.

#Before you begin

1. Confirm the exact family account or member ID that owns the scheduled rows. The hold matches that ID; it does not automatically cascade to another family member whose schedule uses a different ID.
2. Obtain the client's request, authorization, requested start date, and intended return date under the studio's policy.
3. Decide each layer separately:
   • Will billing stop?
   • Will access continue?
   • Will category or purchase expiration be extended?
   • Will unused units remain available?
   • Will classes or appointments remain assigned?
   • Will any amount be waived, prorated, moved, or collected later?
   • What confirmation will the client receive?
4. Open the account's Scheduled Payments tab and record every relevant row's ID, date, amount, status, payment method, purchase, charge, and later cadence.
5. Open the purchase, Member Category assignment, ledger, and Payment History. Check the processor when a due date or uncertain attempt has already occurred.
6. Identify which rows have a positive purchase link and which are charge-linked or otherwise have no purchase link. This distinction changes whether the current processor applies the dated hold.
7. Confirm the application timezone and the scheduled-processing window with the system owner. The ordinary hosted task currently selects exact-date rows rather than automatically catching up overdue rows.
8. Record a before-state snapshot in the studio's approved case record. Do not rely on the hold row as a durable audit trail.

Use a fictional account and processor test mode when validating a new membership design. Do not test hold behavior by allowing a real payment to become due.

Privacy warning: A hold note can expose health, family, or financial information. Enter only the minimum operational wording, such as Client-requested billing pause; approved through 2026-08-09. Do not record a diagnosis, card data, bank data, processor token, password, or unnecessary personal explanation.

#Understand the dated hold record

The current record is account-scoped, not membership-item-scoped.

The normal processor interval is:

Start Date <= original Payment Date < Resume Date

A blank Resume Date means every original payment date on or after Start Date remains inside the hold while the record exists.

Important: The current form validates that both entered values are dates, but it does not require Resume Date to be after Start Date. Enforce that order operationally. A reversed or same-day interval can save yet fail to hold the intended rows.

#Example date window

Assume a fictional account has Start Date July 10 and Resume Date August 10.

The stored hold remains on On Hold Payments after August 10 until someone removes it. Its existence alone does not mean it is active today.

#Know which scheduled rows the hold suppresses

In the current scheduled-payment processor, a hold is applied differently according to the row's purchase link.

If an older tenant's scheduled-payment table does not have a Purchase ID column, the compatibility branch can apply the hold to every otherwise qualifying row. Verify the studio's actual data shape before promising coverage.

High-risk mismatch: The Online Client scheduled-payment display can label any nonprocessed future row whose date falls in the account's hold window On Hold, including a charge-linked row that the processor does not suppress. Conversely, the admin scheduled-payment lists can continue to show a suppressed purchase-linked row as Scheduled because those lists primarily map the row's stored status. Do not use either label alone to promise that money will or will not be collected.

The focused current tests confirm both sides of this distinction: a purchase-linked fixture was skipped, while a charge-linked fixture for the same held account processed successfully.

#Create a new dated hold

There is no verified customer-facing creation procedure in the current DSM Next page.

1. Open Finance > On Hold Payments.
2. Check whether the exact account already has a stored hold.
3. If no row exists, stop. The reviewed page has no account search or Add Hold control.
4. Do not use the browser address bar, a developer tool, or an undocumented API call to create the record.
5. Do not pause one row and describe the account as held.
6. Do not move the next payment date merely to imitate older hold guidance; a date edit can break an auto-renewal anchor or cadence.
7. Escalate with the account ID, requested dates, affected schedule IDs, purchase IDs, policy decision, and required access outcome. Do not include payment credentials or sensitive reason details.

The current backend contains a save path that can insert an account hold, but it is not exposed as a supported creation control on the reviewed page. A product-approved interface or an authorized support procedure is required before staff should create new records.

#Edit an existing dated hold

Editing changes the one stored account window. It does not recalculate membership value or build replacement payments.

1. Open Finance > On Hold Payments.
2. Find the exact account and record the displayed Start Date, Resume Date, and Notes before opening the form.
3. Select the pause-shaped action whose tooltip is Edit hold.
4. Re-enter Start date. In the reviewed current React form, the date input is not prefilled from the row.
5. Re-enter Resume date, or leave it blank only when the approved hold is intentionally open-ended. The reviewed current date input is also not prefilled.
6. Enter only the minimum approved Notes. The existing note is prefilled, but verify it rather than assuming it is current.
7. Confirm Resume Date is later than Start Date.
8. Review every scheduled row whose original date will enter or leave the revised interval.
9. Select Save once.
10. Reload the page and confirm the displayed dates and note.
11. Reopen the account's Scheduled Payments tab and verify the dates, raw statuses, purchase links, and charge links. No schedule row should have moved merely because the hold changed.
12. Verify the purchase, category, access outcome, and client communication separately.

Warning: Editing overwrites the existing dates and note. The hold row has no reviewed created-by, updated-by, or revision history. Preserve the before and after states in the studio's approved audit record.

Warning: The older interface described hold calculations, proration, a resume payment, a renewal date, and a payment-method choice. Those calculations and controls are not present in the current edit modal. Do not calculate a credit or replacement charge from an older screenshot.

#Remove the dated hold

The X-shaped action is labeled Remove hold. The backend calls the result Resumed, but it does not reactivate or reschedule each missed payment.

#Prepare the recovery decision first

Before removing the hold:

1. List every scheduled row whose original date is inside the hold interval.
2. Separate purchase-linked rows from rows with no purchase link.
3. Check Payment History, the ledger, and the processor for each date. A charge-linked row may already have processed even though the client display called it On Hold.
4. Identify each missed purchase-linked row's current raw status, amount, payment source, purchase, and recurring anchor.
5. Decide under policy whether each missed obligation is waived, collected separately, rescheduled to a future processing date, or left as an account balance.
6. Decide whether the category, purchase expiration, units, enrollment, or access needs a separate approved correction.
7. Confirm the next ordinary future payment date and amount.

#Remove the record

1. Return to Finance > On Hold Payments.
2. Select the X-shaped Remove hold action for the exact account.
3. Review Remove this hold record?
4. Confirm once.
5. Reload the list and confirm the account's hold row is gone.
6. Open the account's Scheduled Payments tab and review both Upcoming and History.

During removal, the current backend finds scheduled rows for the account whose original dates fall inside the stored window. Qualifying past rows whose raw status is not 2 can be changed to status 4, displayed as On Hold. It then deletes the hold record. Future rows are not shifted, and missed rows are not changed back to active.

Important: Status 4 is a property of an individual scheduled row. It remains after the account hold record is deleted. Removing the account hold therefore can leave historical rows labeled On Hold.

#Pause or resume one scheduled row

Use the row control only when the approved outcome concerns that one instruction.

#Pause one row

1. Open the exact account.
2. Open its Scheduled Payments tab.
3. Match the row by date, amount, purchase, charge, and method.
4. Record its before state and check the processor if the payment date has arrived.
5. Select Pause.
6. Reload and confirm the admin status is Paused.
7. Check every later row; they are unchanged.
8. Check Finance > On Hold Payments and confirm that no dated account hold was created.

The global Finance > Scheduled Payments page also exposes Pause, but it does not expose a matching Resume action. Prefer the account view when a controlled pause/resume cycle is intended.

#Resume one row

1. Reconcile the processor and ledger before reactivating any row whose due date has arrived.
2. In the account's Scheduled Payments tab, find the row that says Paused.
3. Confirm the date is an approved future date whose processing window has not passed.
4. Confirm the amount, saved method, purchase, charge, and later cadence.
5. Select Resume.
6. Reload and confirm the row says Scheduled.
7. Do not submit a separate payment while waiting for the scheduled result.

Pause sets the stored row status to 0; Resume sets it to 1. Neither action changes the payment date. The Online Client currently labels raw status 0 Pending, while admin views label it Paused. Explain the intended outcome to the client rather than relying on that label.

Warning: Resuming a row with a past date does not make the next daily task catch it up. The ordinary scheduled task selects the target date exactly. An operator has an include-overdue option, but that is not a customer-facing recovery button and must not be run casually.

#Understand the effect on membership and access

Treat every layer as a separate decision.

#Do not assume the term is extended

A hold does not move purchase expiration, category expiration, or class dates. If the studio promises that held time will be restored, authorized staff need a separate, documented entitlement correction. Verify access before and after it.

#Do not assume proration

The current hold controller stores dates and notes only. It does not calculate:

• the unused part of the current period;
• a partial return-period amount;
• a credit;
• a replacement charge;
• a combined resume payment; or
• the next normal renewal date.

Calculate any approved adjustment outside the hold control, review it with finance, and post it through the correct ledger workflow. Do not edit a scheduled amount merely to make the total look right.

#Review auto renewal separately

When a held purchase-linked row is the renewal instruction, skipping it means the successful renewal service does not run. The current success path would otherwise create the payment or account result, renewal charge, new purchase, supported lesson assignments, and possibly the next scheduled row.

After a hold, verify:

1. whether the original purchase expired;
2. whether the client retained access through a separate category;
3. whether a renewal charge or payment exists;
4. whether a new purchase was created;
5. whether usage or lessons were assigned;
6. whether a next renewal row exists; and
7. whether the category dates still match the intended term.

Editing Payment Date does not update a separate recurring date when that column exists. A late renewal can therefore remain anchored to an older date. Escalate before changing an auto-renewal row.

#Understand notifications, reporting, and audit

#Notifications

The reviewed hold save and remove paths do not call a message, email, SMS, push, or scheduled-trigger service. No automatic client confirmation was found.

Use a separate approved communication after the finance and access decisions are complete. Include the effective dates, what service or billing changes, what does not change, the expected next payment, and how to ask questions. Do not include a payment-method summary or sensitive hold reason unless policy requires it and the channel is approved.

#Reporting

Do not treat one report as the source of truth.

• Finance > On Hold Payments lists stored hold records for active accounts without restricting the rows to an active date window. A future or expired hold can remain visible.
• Finance > Memberships omits accounts that its current-time hold check considers active.
• The separate Membership Report omits accounts held on the selected as-of date. Its reviewed comparison includes the Resume Date, even though processor selection resumes on that date.
• Admin scheduled-payment views can say Scheduled while a purchase-linked row is being suppressed by the account hold.
• Online Client scheduled payments can say On Hold for a charge-linked row that the processor does not suppress.
• A one-row Pause can appear as Paused to staff and Pending to the client.

Use the hold dates, exact account ID, row links, raw schedule status, processor result, ledger, purchase, and category as the reconciliation evidence.

#Audit history

The reviewed hold table contains the account, dates, notes, and a legacy scheduled-payment reference. It has no reviewed status, created-at, updated-at, created-by, or updated-by fields. Editing overwrites the record, and removing it deletes the record.

Before every change, preserve:

• request and authorization;
• account and affected schedule IDs;
• old and new dates;
• intended billing and access outcome;
• approved proration, waiver, or collection decision;
• processor and ledger reconciliation;
• staff member and timestamp in the studio's audit system; and
• client notification evidence.

Do not store this history only in the free-text hold note.

#Recover safely after a hold

Removing the hold record is only the beginning of recovery.

1. Confirm the hold is gone from Finance > On Hold Payments.
2. Reopen the account's Upcoming and History scheduled-payment lists.
3. For every original date inside the hold, classify the row:
   • skipped purchase-linked row;
   • no-purchase or charge-linked row that may have processed;
   • paused row;
   • failed or uncertain processor attempt;
   • completed row; or
   • row now labeled On Hold after removal.
4. Check the processor, Payment History, payment-to-charge allocation, and ledger before deciding that money is missing.
5. Do not recreate a row merely because the original still says Scheduled, Paused, Processing Error, or On Hold.
6. Decide each missed obligation under policy. A waiver, account charge, separate approved payment, or future schedule is an accounting decision—not an automatic hold result.
7. If a future scheduled attempt is approved, use a date whose processing window has not passed and verify the saved method and purchase link. Do not rely on an old past date.
8. Recalculate the remaining finite payment-plan obligation or renewal count. Later rows were not shifted by the hold.
9. Confirm the next normal row is active, outside the old hold interval, and has the intended amount and method.
10. Confirm purchase activation, expiration, units, and assignments.
11. Confirm Member Category status and dates.
12. Test restricted registration, video, discounts, offers, and the applicable client view with fictional data.
13. Compare Finance > Memberships and the Membership Report after the reporting date boundary, but reconcile from the underlying records.
14. Send the approved confirmation and preserve delivery evidence.

If any processor attempt is uncertain, stop and follow Respond to a failed scheduled payment. A duplicate schedule or payment can create a duplicate charge or entitlement.

#Verification matrix

Use this matrix with a fictional test account before adopting a hold policy.

Record the tenant, release/build, application timezone, fixture account, schedule IDs, purchase and charge links, dates, raw statuses, and result. Use only masked test payment methods.

#Troubleshooting

#There is no Add Hold button

That matches the reviewed current page. Do not use a one-row Pause or date edit as an undocumented replacement. Escalate for an authorized creation path and include the non-sensitive reconciliation details.

#The edit window opened with blank dates

Record the dates from the list, then re-enter both approved values. Do not save a guessed date. Resume Date must be later than Start Date even though the current request validation does not enforce that relationship.

#The membership still has access during the hold

That is expected unless staff separately changed the category, purchase, enrollment, or access configuration. A payment hold does not revoke access. Follow the approved service policy and verify every affected access consumer.

#A payment processed during the hold

First check whether the row had a positive Purchase ID. A no-purchase or charge-linked row is not suppressed by the current purchase-aware hold selector. Also check whether the payment date was outside the interval, the exact account ID differed, the hold did not exist at selection time, or the row had already been claimed for processing. Reconcile processor and ledger records before making any correction.

#Admin says Scheduled even though the payment is held

The account hold can suppress a purchase-linked row without changing its stored status. Use the hold dates and purchase link rather than the admin label alone.

#The client says On Hold, but the row still processed

The client status query overlays the account date window without applying the processor's purchase-link exception. A charge-linked row can therefore display On Hold and still process. Escalate this mismatch and explain the reconciled result to the client.

#A paused row says Pending in the Online Client

The current client label for raw status 0 is Pending, while staff views call it Paused. Confirm the exact row and explain the intended status in the client communication.

#The membership is missing from a report on Resume Date

The Membership Report's current as-of-date hold test includes the Resume Date. The processor uses Resume Date as the first date outside the hold. Check the following as-of date and use the account, schedule, and ledger as the operational evidence.

#The missed payment did not catch up

The dated hold leaves the original payment date unchanged, and the ordinary scheduled task selects exact-date rows. Removing the hold can mark past rows On Hold rather than rescheduling them. Use the approved recovery decision; do not create a duplicate row while the processor result is uncertain.

#Removing the hold left rows labeled On Hold

That matches the current removal logic for qualifying past in-window rows. The account hold record and row status are separate. Review each row's obligation, processor state, and ledger before changing or replacing it.

#The hold ended, but it remains on On Hold Payments

The page lists stored records, not only currently effective holds. Remove the record only after the missed-row recovery decision is documented. Removal can change past row statuses.

#Another family member's payment still processed

The hold matches the scheduled row's exact member/account ID. Check whether the related student's or parent's row uses a different ID. Do not duplicate holds across family members without identifying which account owns each obligation.

#The hold did not extend expiration or restore units

That is expected. Update a purchase or category only through its approved correction workflow, and verify the client-visible result. Do not backdate or extend records solely to make a report appear correct.

#Known current boundaries

Do not promise the following until the product gaps are resolved and a controlled fixture confirms the studio's release:

1. Staff can create a new dated hold from the current On Hold Payments page.
2. A dated hold suppresses every type of scheduled payment. The current purchase-aware branch allows no-purchase rows, including charge-linked rows, to proceed.
3. Admin and client status labels accurately describe processor eligibility. They use different hold and raw-status mappings.
4. Resume Date has identical meaning in payment selection and membership reports.
5. Saving a hold validates that Resume Date follows Start Date.
6. Editing a hold preserves or preloads both dates in the current modal.
7. A hold shifts future dates, catches up missed rows, extends a term, restores units, prorates charges, creates credits, or builds a resume payment.
8. Removing a hold reactivates past rows. It can instead mark qualifying past rows On Hold.
9. A hold sends a notification or creates a durable audit history.
10. A held renewal creates a new purchase, charge, assignment, or next schedule. Those are success-path outcomes, not hold outcomes.
11. A hold changes Member Category dates, access, discounts, enrollment, videos, messaging eligibility, or processor-side agreements.
12. An expired hold disappears automatically from On Hold Payments.

#Related articles

• Understand membership concepts and lifecycle
• Scheduled payments and scheduled charges
• Respond to a failed scheduled payment
• Offer and create payment plans
• Memberships, vouchers, and gift cards
• Review and manage cards and ACH
• Review an account ledger
• Review payment history and make corrections
• Review purchases
• Edit or cancel a purchase
• Create and maintain categories
• Reports overview
• Buy packages, memberships, and subscriptions
• View your account and make payments
• Why features and menus can differ