Downgrading behavior is confusing

Issue Summary

If a user signs up for a higher priced plan and then downgrades to the lower one, the behavior is unexpected.

What happens:

• The member is immediately moved to the lower plan.
• Stripe records a credit, based on time left on the higher plan (prorated) and time on the new plan (prorated, no reset on the billing date).
• There is no indication in Portal that the user has a credit in Stripe.
• There's no indication before downgrading that the current plan will immediately switch. (Lots of platforms run out the current paid period first.)

In the extreme case, a member who signs up for an annual plan at $300 per year and then downgrades shortly after billing (or renewal) to a $30/year plan will end up with a ~$270 credit at Stripe. It'll take 9 years to work through that credit.

Mitigation

• Minimally, downgrading or upgrading should clearly say what's going to happen, rather than just doing it.
• Better: Match the behavior of most platforms, where your plan change goes in after the end of the current paid period.

Steps to Reproduce

Create two paid plans.
Sign up as a member, choosing the higher paid plan.
In Portal, change to the lower paid plan.
Inspect the results in Stripe (I was using test mode)

Ghost Version

6.56

Node.js Version

Ghost Pro

How did you install Ghost?

Ghost Pro

Database type

MySQL 8

Browser & OS version

No response

Relevant log / error output

Code of Conduct

• I agree to be friendly and polite to people in this repository

Reproduce the downgrade through Portal using two paid plans, then inspect the resulting credit and plan timing in Stripe test mode. Start from the Portal plan-change flow and compare the immediate switch with the proposed end-of-period behavior. Done means the chosen behavior is clear before confirmation and the resulting plan and Stripe credit match that behavior.