cancel and pause subscriptions with a different order cycle

[maartenb17]

We have subscriptions that are billed monthly and shipped (ordered) every 3 months. When canceling the subscription half way an order cycle, it is canceled immediately including all remaining billing cycles. That makes no sense. When canceling or pausing such a subscription it should cancel or pause at the end of the current order cycle, so all remaining invoices in this cycle will still be created.

Maybe I am overlooking something but is there a way to correctly cancel and pause subscription with different billing and order cycles?

[ericingram]

Do you mean, the order schedule should still ship the last cycle?

Maybe we can add a more specific test case and we'll look into it

[maartenb17]

no, what I mean is that when the order cycle is longer than the billing cycle and you cancel it also all remaining billing cycles are cancelled. Example: order cycle is 3 months, billing cycle is monthly. A new order cycle has started and the customer has already received a new shipment. Also at the same time an invoice is created. Canceling the sub should mean the two remaining billing cycles/invoices should still be created till the end of the order cycle. If canceled immediately I would have shipped a product that isn’t yet fully paid. Met vriendelijke groet,MaartenVerstuurd vanaf mijn iPhoneOp 10 dec 2025 om 17:25 heeft Eric ***@***.***> het volgende geschreven: Do you mean, the order schedule should still ship the last cycle? Maybe we can add a more specific test case and we'll look into it —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: ***@***.***>

[maartenb17]

To be even more concrete: We sell a supplement for a one time price of €120. The supplement lasts about 90 days so we created a subscription that renews every 3 months (order cycle) and is billed monthly à €35. So every time a new order cycle starts we ship a new bottle which is paid in three billing cycles. This means that if half way an order cycle the sub is canceled it should still run the remaining billing cycles till the end of the current order cycle. If not - which is the current situation when canceled, we loose money. I guess our use case is atypical. It seems the implemented business logic in Swell regarding subscriptions is that a billing cycle is leading which makes sense when the order cycle is equal to or shorter than the billing cycle. When it is the way around, the order cycle should be leading. In fact I think when the subscription contains a physical product the order cycle should always be leading not the billing cycle.

…

Op 10 dec 2025, om 17:25 heeft Eric ***@***.***> het volgende geschreven: Do you mean, the order schedule should still ship the last cycle? Maybe we can add a more specific test case and we'll look into it — Reply to this email directly, view it on GitHub <#631 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMILI7F3CKILCH6WHDBL4BBCPXAVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMRSGE4TIMY>. You are receiving this because you authored the thread.

[ericingram]

Ok thanks for the details. We're discussing this case internally now and I'll get back to you with our conclusion

[ericingram]

@maartenb17 was the subscription in question, canceled with the cancel_at_end=true parameter?

[maartenb17]

Yes!Met vriendelijke groet,MaartenVerstuurd vanaf mijn iPhoneOp 13 dec 2025 om 01:00 heeft Eric ***@***.***> het volgende geschreven: @maartenb17 was the subscription in question, canceled with the cancel_at_end=true parameter? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[ericingram]

@maartenb17 we're thinking the behavior of the cancel_at_end=true flag should set the cancellation date to the last billing or order schedule by default. And there may be another field to customize it one way or the other.

Would that solve your problem?

[maartenb17]

I think so. Meaning there would be a separate setting that determines whether to end at the last billing or order schedule. Correct?Met vriendelijke groet,MaartenVerstuurd vanaf mijn iPhoneOp 16 dec 2025 om 00:08 heeft Eric ***@***.***> het volgende geschreven: @maartenb17 we're thinking the behavior of the cancel_at_end=true flag should set the cancellation date to the last billing or order schedule by default. And there may be another field to customize it one way or the other. Would that solve your problem? —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: ***@***.***>

[ericingram]

That's correct. By default, it would end on the last date of either schedule which is later, but you could designate which schedule to end on otherwise. Currently it ends on the billing schedule by default.

[maartenb17]

Do you have a timeline for this to be implemented? Also I suggest to implement the same behaviour for pausing the subscription. So pausing by default would result in pausing at the end of the billing or order schedule depending on which is later unless specifically set to one or the other.

[ericingram]

Yeah, I think it makes sense. We're working on it.

[maartenb17]

Eric, any idea when this will be implemented? Thx.

[ericingram]

@maartenb17 this was put on the backlog but it looks like we're about to pick it up. I'd give it another 1-2 weeks to go through QA etc.

[maartenb17]

Great!

…

Op 13 jan 2026, om 21:10 heeft Eric ***@***.***> het volgende geschreven: @maartenb17 <https://github.com/maartenb17> this was put on the backlog but it looks like we're about to pick it up. I'd give it another 1-2 weeks to go through QA etc. — Reply to this email directly, view it on GitHub <#631 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMIJ3KXJCTBGXTALFZED4GVGLFAVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNBYHEZDKNI>. You are receiving this because you were mentioned.

[ericingram]

The feature is deployed but we are still working on documentation

[maartenb17]

Great! I can see the new data fields in developer -> models. So in order to end a subscription at the end of the current order cycle I need to set ‘cancel_at_schedule’ to ‘order’. Correct? And do I need to set ‘cancel at end’ to ’true’?

…

Op 25 jan 2026, om 18:31 heeft Eric ***@***.***> het volgende geschreven: The feature is deployed but we are still working on documentation — Reply to this email directly, view it on GitHub <#631 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMILDMZL5YLJNDM2ED5T4IT4Y7AVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNJZHEYTSMI>. You are receiving this because you were mentioned.

[ericingram]

Yes that's correct. You do not need to set cancel_at_end, since it's overridden by the cancel_at_schedule field.

[maartenb17]

How can I verify that subscription is canceled at the end of the current order cycle?

…

Op 26 jan 2026, om 20:27 heeft Eric ***@***.***> het volgende geschreven: Yes that's correct. You do not need to set cancel_at_end, since it's overridden by the cancel_at_schedule field. — Reply to this email directly, view it on GitHub <#631 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMILMITF5ESLI7FVLZPT4IZTCTAVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRRGAYDKOI>. You are receiving this because you were mentioned.

[ericingram]

You can look at the date_cancel_at field to see what is calculated. Note you can also set this field manually.

[maartenb17]

In the admin dashboard -> subscriptions a canceled subscription with cancel_at_schedule set to ‘order’ should show no data under ’next order’ (is working correctly) and only data under ’next invoice’ if applicable. In my testing it should show data under ’next invoice’ where it doesn’t. And what is the function of ‘first’ and ‘last’ in ‘cancel_at_schedule’?

…

Op 26 jan 2026, om 20:27 heeft Eric ***@***.***> het volgende geschreven: Yes that's correct. You do not need to set cancel_at_end, since it's overridden by the cancel_at_schedule field. — Reply to this email directly, view it on GitHub <#631 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMILMITF5ESLI7FVLZPT4IZTCTAVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRRGAYDKOI>. You are receiving this because you were mentioned.

[maartenb17]

I did some testing and I think it works, however in de admin dashboard -> subscriptions future cancelation is not reflected under “First/next order” and “First/next invoice”. When setting “cancel_at_schedule” to “order” and cancel the subscription in the middle of the current order cycle “Next order” should result in containing no data. Likewise when canceling the subscription in the last billing cycle it should result in an empty “Next invoice” as well as an empty “Next order”. Also when setting “cancel_at_schedule” in the console and then executing in admin dashboard -> subscriptions -> actions the cancel command, the subscription is canceled immediately and ignoring the “cancel_at_schedule” setting. It would make sense if the cancelation action would first present a choice similar to “cancel_at_schedule”. All the above also apply to the pause commands and settings. Furthermore in the admin dashboard the pause action command first displays a choice: pauze immediately and skip next cycle. That should be extended with the other “pause_at_schedule” settings (skip next, first or last billing cycle or skip next order cycle including all billing cycles till then). Basically I can see three scenarios: Billing and order cycles are equal Billing cycle is greater than order cycle (e.g. pay yearly and ship monthly) Billing cycle is smaller than order cycle (e.g. pay monthly and ship quarterly) For scenario 1 cancelation and pausing works just fine as it always has. For scenario 2 the billing cycle should be leading in case of cancelation and pausing (e.g. after pausing or cancelation all remaining orders will still be fulfilled). For scenario 3 the order cycle should be leading (e.g. all remaining invoices should be created otherwise money is lost). The questions then is why would you need to set the cancel or pause schedule manually when it could be set automatically depending on the chosen scenario which can be derived from products -> subscription pricing settings? In case of scenario 2 I can see one other possibility and that is explicitly overriding the default settings to the order cycle as leading so skipping/pausing the order cycle also results in postponing the next invoice date (e.g. skipping one monthly shipment results in postponing next yearly invoice with one month). That could be a simple option field which also be displayed in the admin dashboard when executing the pause command. In short I think the implementation can be much simpler than it is now. What do you think?

…

Op 26 jan 2026, om 20:27 heeft Eric ***@***.***> het volgende geschreven: Yes that's correct. You do not need to set cancel_at_end, since it's overridden by the cancel_at_schedule field. — Reply to this email directly, view it on GitHub <#631 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMILMITF5ESLI7FVLZPT4IZTCTAVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRRGAYDKOI>. You are receiving this because you were mentioned.

[ericingram]

We're now working on improvements in the dashboard to reflect the new API fields. I'll ask someone to review your comments shortly.

Thanks!

[sstakhovski]

@maartenb17
Thank you for your feedback.

1. Do not show "Next order" and "Next invoice" if the subscription is cancelled.
   It makes sense, We'll implement this.

2. New options for cancelation and pausing on the dashboard.
   We'll add them.

3. you asked "The questions then is why would you need to set the cancel or pause schedule manually when it could be set automatically depending on the chosen scenario which can be derived from products -> subscription pricing settings"

You can use cancel_at_schedule: 'last' to cover all 3 scenarios. We calculate the last from the next order and billing dates and cancel the subscription at that moment.

4. you want an option on the dashboard to postpone the next billing date if we pause the subscription.
   We already have the ability to manually reassign the next invoice date. Or it can be reassigned using the backend API.

5. In short I think the implementation can be much simpler than it is now. What do you think?
   We have some legacy options that we should support. But we are open to new ideas.

6. We are going to update scheduled cancellation and pausing once again: for scheduled cancellations, we'll mark the subscription as "cancelled: true" and "active: true." On the scheduled cancellation date, we'll mark it as "active: false." This will help make subscription statuses more clear. The same for pausing: mark the subscription as paused: true, active: true at the moment we pause it. Mark it as paused: false on the scheduled pausing date.

[maartenb17]

Wonderfull! And thx for the explanation/comments.

…

Op 30 jan 2026, om 00:45 heeft sstakhovski ***@***.***> het volgende geschreven: @maartenb17 <https://github.com/maartenb17> Thank you for your feedback. Do not show "Next order" and "Next invoice" if the subscription is cancelled. It makes sense, We'll implement this. New options for cancelation and pausing on the dashboard. We'll add them. you asked "The questions then is why would you need to set the cancel or pause schedule manually when it could be set automatically depending on the chosen scenario which can be derived from products -> subscription pricing settings" You can use cancel_at_schedule: 'last' to cover all 3 scenarios. We calculate the last from the next order and billing dates and cancel the subscription at that moment. you want an option on the dashboard to postpone the next billing date if we pause the subscription. We already have the ability to manually reassign the next invoice date. Or it can be reassigned using the backend API. In short I think the implementation can be much simpler than it is now. What do you think? We have some legacy options that we should support. But we are open to new ideas. We are going to update scheduled cancellation and pausing once again: for scheduled cancellations, we'll mark the subscription as "cancelled: true" and "active: true." On the scheduled cancellation date, we'll mark it as "active: false." This will help make subscription statuses more clear. The same for pausing: mark the subscription as paused: true, active: true at the moment we pause it. Mark it as paused: false on the scheduled pausing date. — Reply to this email directly, view it on GitHub <#631 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMILQ3TD2YHTC2VHASJ34JKLQ3AVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRUGUZDKOI>. You are receiving this because you were mentioned.

[maartenb17]

Thanks so much!

…

Op 29 jan 2026, om 21:11 heeft Eric ***@***.***> het volgende geschreven: We're now working on improvements in the dashboard to reflect the new API fields. I'll ask someone to review your comments shortly. Thanks! — Reply to this email directly, view it on GitHub <#631 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BRJSMINLHH5US3NFXXWQMJT4JJSQDAVCNFSM6AAAAACOT7RV2OVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRUGM4TOOA>. You are receiving this because you were mentioned.

[maartenb17]

I have been playing with the new implementation and it works great! Just a little remark: when pausing a subscription one is now presented with three options: pause now, pause and skip cycles and pause at the end of the order cycle. When choosing the skip cycle option it will only skip billing cycles not order cycles. In our case where order cycle > billing cycle it should skip order cycles not billing cycles. At least you should add a fourth option: pause and skip order cycles.

Likewise when setting "pause_at_schedule" to "last" and "pause_skip_cycles" to 1, and setting "paused "to true, the result will be that one billing cycle is skipped, not the order cycle.

In short "pause_skip_cycles" doesn't take into account the "pause_at_schedule" setting.

[maartenb17]

excellent!

[sstakhovski]

The changes have been deployed and you can try them.

[maartenb17]

You are the best!

[maartenb17]

Billing cycles and order cycles if defined are always bond together meaning when skipping a billing cycle the order cycle should skip with one billing cycle too. Currently it doesn't seem to work like that. However skipping the order cycle does automatically skip the billing cycles accordingly. Is this by design or am I missing something?

[sstakhovski]

In our logic, if a subscription is completely paused and then resumed, we restart the billing and order cycles.
The resume moment is configured using the date_pause_end field. The pause_skip_cycles parameter only helps automatically calculate the date_pause_end according to the current schedules.

But in any case, we start new schedules at the specified date.

Example: billing each month, order each 3 month

Jan 01. subscription started, next invoice Feb 01, next order Apr 01

Jan 15. subscription is configured to pause at the end of the billing cycle and skip 1 cycle:

• date_pause_at: Feb 01
• date_pause_end: Mar 01
• paused: true
• active: true

Feb 01. subscription is paused:

• paused: true
• active: false
• date_pause_end: Mar 01

Mar 01. subscription is resumed, we start a new billing cycle and a new order cycle from this moment

• active: true,
• paused: false
• next invoice date is Apr 01
• next order date is Jun 01, we start a new 3 month cycle from this moment (Mar 01).