v5.53.0 7 June 2026 Improvement Fix

Cancellation Scheduling Modernised & Verified Live in Both Directions

Why This Matters

Our payment provider has deprecated the parameter SpeyBooks used to schedule end-of-period subscription cancellations. Deprecated means working today and removed someday, and someday is not allowed to arrive after the first real charge. This release migrates every write to the modern mechanism, eleven weeks before any customer money rides on it, and then proves the result the only way that counts: live, in both directions, with the billing page watched through every transition.

What Changed

  • Cancellation scheduling uses the modern mechanism Every place the platform schedules a cancellation at the end of a billing period now uses the provider’s current interface. Behaviour is unchanged for customers: cancel keeps full access until the period ends, reactivate any time before then, resubscribe any time after.

  • One honest subtlety, recorded The old mechanism floated: if a billing period moved, the cancellation moved with it. The new mechanism locks the cancellation to the exact date shown at the moment you cancel. For monthly billing these are the same thing in practice, and the date the page shows you is now the date that is locked in, to the second.

  • Reference documentation corrected The admin API reference described the old mechanism and an internal update step that was removed some releases ago. Both descriptions now match the code. Public documentation that describes absent code is treated as a defect here, not a cosmetic issue.

The Verification

The migration was tested against the live payment provider in all four combinations before this entry was written: cancellation scheduled from the billing portal and cleared by the platform; cancellation scheduled by the platform and cleared from the billing portal. At every step the billing page tracked the truth: the cancellation banner and the “Cancels on” date appeared the moment a cancellation existed, and the “First charge” line returned the moment it did not.

One finding from the verification is worth stating plainly: on writes through the modern mechanism, the provider leaves the old deprecated field reading “not cancelling” even while a cancellation is armed. Any system still reading only that field would be blind to its own cancellations. SpeyBooks is not, because release 5.49.0 already moved the platform to a derived reading that considers the full cancellation state. That change was made to handle the provider’s API evolution; this week it turned out to be required for our own writes as well. Found by verification, before any customer was affected.

Operational Impact

  • No customer-visible behaviour change: cancel, keep access until period end, reactivate, resubscribe all work exactly as before
  • The cancellation date shown when you cancel is the date locked in
  • The platform no longer depends on a parameter scheduled for removal
  • Admin API reference matches the running code again

Files Changed

Backend:

  • Payment provider library: cancellation and reactivation writes migrated to the modern mechanism
  • Admin subscription route: same migration
  • Admin API reference: outdated mechanism description and an obsolete internal step corrected

Plumbing releases earn their changelog entries when the verification is the story. Four live round trips, a billing page that told the truth at every step, and a deprecated parameter retired with eleven weeks to spare.