WooCommerce Subscriptions

We are building a subscription-based enrolment system for a ballet academy. Students enrol in programmes billed monthly, quarterly, or per semester — all tied to a fixed academic year (e.g. September 1 to June 30). This is an extremely common real-world scenario for educational institutions, sports clubs, and similar organisations.

Three fundamental capabilities are missing from WooCommerce Subscriptions, forcing us into painful workarounds:

**1. Subscriptions that start on a future date**

We need the first payment to be charged on the academic year start date, not at the moment of checkout. There is no native way to do this. The only available mechanism is the free trial period — we calculate the number of days between today and the start date and inject that as a trial length. This is semantically wrong (it is not a trial), creates confusing customer-facing messaging that we have to intercept and rewrite through multiple filter hooks, and breaks down in edge cases. A simple “first billing date” field on the subscription product would solve this entirely.

**2. Subscriptions that end on a fixed date**

Academic programmes end on a known date. We need subscriptions to automatically stop renewing at the end of the academic year regardless of when the student enrolled. WooCommerce Subscriptions supports a fixed number of payments as a “length”, but not a fixed end date. Since students can enrol at any point in the year, the number of remaining payments varies per student and cannot be set statically on the product. We calculate the remaining months dynamically and override the subscription length at checkout — a fragile, non-standard approach that requires custom code throughout.

**3. Pay-in-full as a first-class billing option**

Many students or parents prefer to pay the full academic year tuition in a single payment. This is not a subscription in the traditional sense, but it belongs in the same product alongside the monthly and quarterly options. WooCommerce Subscriptions has no concept of a “one-time payment variant” within a variable subscription product. We worked around this by creating a variation with a CHF 0 recurring price and a sign-up fee equal to the full tuition — which causes the plugin to render “CHF 0.00 / year” in the cart, checkout order review, and order summary through multiple separate output channels. We have had to hook into at least six different filters and template outputs just to suppress or replace this string everywhere it appears.

**What we are asking for**

– A **”First billing date”** field on subscription products (absolute date or relative to purchase)
– A **”Billing end date”** field on subscription products (in addition to the existing payment count)
– A **”One-time payment”** billing option as a native variation type within variable subscriptions, displayed cleanly without recurring price strings

These three features would cover a wide range of real-world use cases — academic institutions, sports clubs, music schools, therapy practices — where programmes have a defined calendar and customers need flexibility in how they pay for them.