Until now, charging a subscription in WooCommerce meant accepting one very simple rule: you pick a period —every month, every three months, every year— and the plugin keeps adding that period over and over until the subscription ends. It works perfectly when your business fits that shape. The problem is that plenty of businesses don’t.

With version 2.0 of Payment Schedule for WooCommerce Subscriptions you no longer have to squeeze your billing calendar into a fixed period. You can now write the payment dates one by one, in the order and with the spacing you want, and the plugin makes sure the subscription charges on exactly those dates and on no others.

Why the fixed period falls short

Think of a school that charges a course in nine monthly instalments, from September to May, but charges nothing over the summer. With a monthly period you would have to remember to pause every subscription in June and reactivate it in September, student by student. Think of a sports club that collects its fee in three instalments on specific board-meeting dates: 1 October, 15 January and 1 April. With a four-monthly period those dates would drift depending on the day each member signed up.

The same pattern shows up in training courses paid in uneven instalments, in membership fees tied to fixed calendar dates, in seasonal services, and in any instalment plan that answers to a real calendar rather than to a formula. In all of those cases the fixed period forces you to compensate by hand for what the plugin cannot do.

What we used to support, and what we support now

Our plugins already let you move both ends of the calendar: with First payment date for WooCommerce Subscriptions you could decide the day of the first charge, and with Payment Schedule you could set an expiration date instead of counting periods. That solved a lot of cases, but the underlying model was still the same: between the first payment and the last one, WooCommerce Subscriptions decided on its own by adding the period again and again.

The custom payment schedule breaks that limitation. You no longer define the two ends and leave the middle to the automation: you define every single date. The first payment, the last one and everything in between are yours.

How to set it up

The setting lives in the product screen, inside the subscription data tab. You will find a dropdown called Custom payment schedule with three options.

Fixed dates, the same for every customer

You write specific calendar dates, and every customer who buys that product pays on those same dates, no matter which day they bought. This is the option for courses, seasons, membership fees and any charge tied to a shared calendar.

• 1 October 2026
• 15 January 2027
• 1 April 2027

Days after each purchase

Instead of dates you write numbers of days, and every customer gets their own calendar counted from the moment they bought. Splitting a payment into three instalments at 0, 30 and 60 days gives every buyer the same experience, whenever they start. This is the natural option for deferred payments and instalment plans.

Not used

The product keeps working as it always has and WooCommerce Subscriptions decides the billing schedule. This is the default value, so no product changes its behaviour when you update.

Rows are added and removed with a button, they renumber themselves, and every variation of a variable subscription gets its own independent schedule. The same course can have a one-off payment variation, a three-instalment one and a nine-instalment one, each with its own dates.

What happens when someone buys late

This is the question that comes up the moment you work with fixed dates, and it is where the plugin gets genuinely interesting. If the course schedule starts on 1 October and someone enrols on 20 November, what should happen?

There is no universally correct answer, so you get to decide it yourself — and separately for two different situations.

Purchase after the first date

• Charge only the dates that are still ahead. The customer joins the schedule where it currently stands and pays the remaining instalments. Bear in mind they will pay fewer instalments than someone who bought on time.
• Notify me and use the default billing schedule. The purchase goes through, the subscription keeps the standard behaviour, and you get an email plus a note on the subscription so you can review it and adjust the amount by hand.
• Do not allow the purchase. The product stops being purchasable as soon as the first date has passed. It is the equivalent of closing enrolment without having to remember to unpublish anything.

Purchase after the last date

Once every date has passed, the options are do not allow the purchase, notify me and use the default billing schedule, or use the default billing schedule silently. That last one fits products that have a season with fixed dates and, outside of it, ordinary recurring billing.

The product screen warns you if you pick a rule that falls back to the default billing schedule on a product with no subscription length, because that customer would end up paying indefinitely. It also warns you about empty, invalid or duplicated rows, and about schedules whose dates have all already passed.

Customers see the schedule before they buy

An exact billing calendar is not much use if the customer has no idea when they will be charged. The dates show up on the product page, in the cart, at checkout, and in the subscription details inside My account. On variable subscriptions the list updates itself as the customer picks a different variation.

In My account the table goes one step further and marks each instalment as paid or scheduled, so customers always know where they stand in the plan and how much is left. Those are support tickets that never get opened.

And you can edit the schedule of each subscription

The product schedule is the template, but every subscription keeps its own copy taken at the moment of purchase. That means you can edit it without touching the product and without affecting anyone else.

The subscription edit screen has a panel with all of its instalments. The ones already charged are locked —you cannot rewrite the past— and the pending ones are editable: change a date to postpone an instalment, or clear it to drop that instalment from the plan. On save, the plugin moves the next payment and the end date so that all three stay in agreement.

A customer asks you to push the January instalment to 5 February. You open their subscription, change that date, save. No pausing, no cancelling, no manual orders.

The detail that changes everything: no charge at sign-up

When a product uses a custom payment schedule, the WooCommerce Subscriptions sign-up charge disappears. The customer pays exactly the instalments you wrote, on the dates you wrote, and nothing else. No extra upfront payment to refund or discount later.

And at the other end, once the last instalment of the schedule has been collected the subscription stops billing for good: no further renewal order is created. A three-instalment plan charges three instalments. Not two, not four.

On top of that, while a payment schedule is in use the product screen hides the settings it overrides —the free trial, the expiration date, the first payment date— so you only see the options that actually do something. Less confusion, and fewer contradictory configurations.

In short

• You define the payment dates one by one, with no billing period involved
• Fixed dates shared by every customer, or days counted from each purchase
• An independent schedule for every variation of a variable subscription
• Explicit rules for late purchases, with an email notification when a review is needed
• Customers see the whole schedule before buying, and their progress afterwards
• Every subscription can be rescheduled individually from the dashboard
• No charge at sign-up, and no renewals after the final instalment

If your business bills by calendar and you have spent a long time compensating by hand for what a fixed period cannot do, this version was built for exactly that.