Customer-chosen subscription duration lets a buyer select a finite term—such as 3, 6, or 12 billing cycles—before checkout, within merchant-set limits. Use it when customer needs genuinely vary and unit costs are predictable. Prefer approved choices to unrestricted numbers, disclose the payment count and scheduled total, and separate it from prepaid or installment promises.
Important current status: ArraySubs Customer-Chosen Subscription Duration is a planned Pro workflow marked coming soon. It is not present in current core or Pro code. ArraySubs today supports merchant-defined finite length, including per-variation lengths.
Key takeaways
- Duration and cadence are separate: six payments every two months cover twelve billing months.
- Use a small allowlist such as 3, 6, and 12 cycles instead of a free-form number.
- Show amount today, total payments, later renewals, scheduled total, and end behavior together.
- Validate selection and price on the server through cart, order, subscription, and renewal.
- A finite term is not automatically prepaid or a non-cancellable installment obligation.
Define the control precisely
| Control | Question | Example | Not the same as |
|---|---|---|---|
| Cadence | How often is payment due? | Every 2 months | Number of payments |
| Finite length | How many total cycles? | 6 payments | Shared date |
| Customer-chosen duration | Which approved length does this buyer select? | 3, 6, or 12 | Editing price or dates |
| Fixed date | When does everyone end? | August 31 | Rolling cycles |
| Prepaid | Is the term funded upfront? | $300 now | Six periodic charges |
| Installment | Is a fixed balance owed over time? | 6 × $100 | Cancel-anytime subscription |
| Lifetime | Is access sold once? | One payment | Finite recurring plan |
Decide the end journey first. Will the subscription expire, invite repurchase, permit extension, or convert only after new express consent? Do not silently turn a finite choice into indefinite renewal.
When customer choice fits
| Use case | Fit | Guardrail |
|---|---|---|
| Limited box run | Strong | Cap choices by inventory and shipping cost |
| Rolling coaching | Conditional | Define cancellation and missed sessions |
| Temporary software/content | Strong | Define access at final paid-through date |
| Corporate license | Conditional | Capacity, seats, support, procurement |
| Gift subscription | Usually prepaid instead | Avoid recipient renewal obligation |
| Cohort or season | Poor | Use fixed date |
| Lifetime access | Poor | Use lifetime model |
| Fixed-balance purchase | Poor | Use installment/credit workflow |
| Unknown-cost new offer | Poor initially | Learn with one bounded term |
Use the model only when buyers have a real need for different finite terms, the core value is consistent, every allowed term is safely priced, the engine can enforce it, and failure/cancellation/refund/end behavior is explainable.
Design bounded, accessible choices
Prefer labeled radio cards for 3, 6, and 12 total payments. Each value should map to a merchant-approved server-side term and price rule. A slider or free-form field creates more invalid, inaccessible, and unpriced states.
If free-form entry is genuinely necessary, disclose minimum, maximum, step, unit, price effect, and whether the number means total payments or later renewals. Identify errors in text and suggest a valid correction; WCAG guidance does not support relying on a red outline or silently clamping an invalid number (Labels, Error Identification).
There is no universal default. Test explicit choice, shortest-term default, and evidence-backed recommendation separately. Never label “most popular” without current first-party data.
Show the complete term summary
For a six-payment plan at $40/month:
6 monthly payments of $40. $40 due today, then 5 scheduled monthly renewals. Scheduled subtotal: $240 before tax and shipping. The subscription expires after the sixth successful payment under this plan's stated lifecycle rules.
Keep the selected term visible on product, live summary, cart, checkout, confirmation, email, subscription, My Account, admin, renewal reminders, and final-cycle communication.
For six payments every two months, say six total payments, five later renewals, and twelve billing months. “Six renewals” or “six months” would be wrong under the documented total-payment model.
Model scheduled economics
Let N be total payment count, I the billing interval, P price per payment, S sign-up fee, V variable cost per paid cycle, F transaction cost, and A acquisition/onboarding allocation:
Later scheduled renewals = N − 1
Covered billing periods = N × I
Scheduled gross = S + N × P
Scheduled contribution = S + N × (P − V − F) − A
Assume $40 per monthly payment, $15 variable cost, $60 acquisition/onboarding, and no other fees:
| Duration | Due today | Later renewals | Scheduled gross | Scheduled contribution |
|---|---|---|---|---|
| 3 payments | $40 | 2 | $120 | $15 |
| 6 payments | $40 | 5 | $240 | $90 |
| 12 payments | $40 | 11 | $480 | $240 |
Scheduled arithmetic, not guaranteed revenue or observed customer performance.
Longer terms increase both scheduled revenue and service exposure. Model term discounts separately, and include units, packing, and expected shipping for physical offers.
Build four control layers
Catalog
Allowlist terms, store every price rule server-side, cap choices by capacity and gateway, and control how duration combines with variations, trial, fee, shipping, and entitlement.
Request and checkout
Treat posted duration as untrusted. Validate product eligibility, integer, allowlist, minimum/maximum/step, and resolve price on the server. Revalidate at add to cart, restore, checkout, order creation, and subscription creation.
Lifecycle
Define how free trials, zero-total orders, failures, late manual payments, pauses, skips, cancellation, refunds, plan switches, quantity changes, and extensions affect payment count and end. If remaining payments are legally owed after cancellation, this is an installment/credit question requiring qualified review.
Operations
Show remaining payments to support, log selections and changes, send final-cycle communications, monitor outcomes by duration, test manual and every supported automatic gateway, and preserve original agreed terms when products change.
Measure cohorts, not popularity alone
Store selected duration, cadence, price/fee, planned payments and total, trial/coupon/shipping, gateway, acquisition source, experiment assignment, and a product-configuration snapshot.
Track selection mix, selector errors, purchase/checkout completion, scheduled gross, realized cash by cycle, net contribution, cancellation before end, refunds, fulfillment, support, and expiry-to-resubscribe. The longest or most selected term is not necessarily the best customer or business outcome.
Current ArraySubs status and workaround
As verified July 13, 2026, Customer-Chosen Subscription Duration is planned for Pro and coming soon. There is no current feature directory, boot registration, checkout field, or controller in ArraySubs 1.8.9 or Pro 1.1.0. Do not treat planned marketing copy as an API contract.
What ships today is merchant-defined Subscription Length on a simple product or each subscription variation, from 0 through 365 billing cycles; zero means never expires. The product/variation term is copied into the subscription at checkout.
An interim pattern is separate products or a variable subscription with merchant-configured Length variations such as 3/6/12. This approximates a bounded selector but is not the planned dynamic workflow. Watch variation combinations and test the complete price display.
Current source has two expiration-counting paths with different possible treatment of zero-total orders. Do not promise how trials, coupons, or credit-zeroed cycles count until the behavior is reconciled and tested.
The fixed-cycle recipe provides adjacent configuration concepts, but its recurring charges are not true full prepayment. For shared dates, read Fixed-Date WooCommerce Subscriptions.
Final recommendation
Offer a small, approved choice set only when every term is safe to sell and support. Make the scheduled total and end state explicit, validate everything server-side, and publish lifecycle rules before checkout. For ArraySubs, use current merchant-defined variations only as a transparent interim pattern and label the dedicated Pro workflow coming soon.
View ArraySubs Pro pricing for current and planned feature boundaries; Customer-Chosen Subscription Duration is not yet shipped.
Frequently asked questions
What does customer-chosen subscription duration mean?
The buyer selects one merchant-approved finite term before checkout. The merchant still controls allowed values, cadence, price, and lifecycle.
Is it available in ArraySubs now?
No. It is planned for Pro and marked coming soon. Merchant-defined lengths and per-variation lengths ship today.
Should customers type any number of months?
Usually no. Start with approved choices such as 3, 6, and 12 cycles. Free-form input requires safe rules for every value and accessible validation.
How do I calculate the scheduled total?
For N total payments at price P plus sign-up fee S, scheduled gross is S + N × P. When checkout is payment one, later renewals equal N − 1.
Can a customer cancel before the selected duration ends?
That depends on the contract, settings, and law. Duration alone does not create an owed fixed balance. State future-charge, paid-through access, and expiration effects clearly.
Disclosure, verification, and update log
ArraySubs is the product discussed by this site. Official WooCommerce/WCAG guidance and ArraySubs 1.8.9/Pro 1.1.0 source were reviewed July 13, 2026. The planned feature has no final implementation to test, and current zero-total counting semantics remain a stated limitation.
- July 2026: Initial publication; coming-soon status and current merchant-defined length behavior verified.
Continue from strategy to setup
Use a recipe when the model is settled
These articles own the decision and operating model. The ArraySubs feature map and recipes cover the exact product, billing, and customer-workflow configuration.
Written by
Emran // ArrayHash
Research and practical guidance for WooCommerce subscription operators and implementation teams.
Technical review
ArraySubs Engineering Team
Reviewed against current ArraySubs code, product documentation, and the linked primary platform sources.
