Monthly to Yearly: The Billing Period Change

I have managed to solve this by using the ending_balance field of the Invoice. Also, I have noticed a separate issue using amount_due when downgrading from a plan to another having the same duration. amount_due works fine when there is an upgrade, but not when there is a downgrade.

Here is my code (apologies for the ugly nested else condition AND please note that I am using different logic in the condition that compare the plan durations)

$total = $invoice->total;

// contains the pro-rations
// *plus* - if the duration matches - next cycle's amount
if ($userPlan->getDuration() === $newPlan->getDuration()) {
    $total -= $newPlan->getPrice() * 100;
} else {
    if ($invoice->ending_balance < 0) {
        $total = $invoice->ending_balance;
    }

Hey Martin,

Thanks for sharing your solution with others! Though, proration is a bit more complex than just price difference between 2 plans. It also takes into account how many "unused" time left from the old subscription, so the actual logic should be more complex, otherwise it will show the correct proration only in the beginning of your old subscription.

I hope this helps!

Cheers!

I've further improved the code removing my ugly nested else / if conditions. The previous solution I posted was also working - this one is just cleaner. I can confirm that this has been tested using 16 different scenarios including 6 days after initial subscription and the total always comes out calculated correctly and matching what Stripe actually charges.

// contains the pro-rations *plus* the next cycle's amount *plus* any negative ending balance
$total = $invoice->amount_due + $invoice->ending_balance;

// contains the pro-rations
// *plus* - if the duration matches - next cycle's amount
if ($plan->getDuration() == $currentUserPlan->getDuration()) {
    // subtract plan price to *remove* next the next cycle's total
    $total -= $plan->getPrice() * 100;
}

Plan upgrade with same duration
Plan downgrade with same duration
Plan changed to lower duration
Plan changed to higher duration
Plan upgrade + higher duration
Plan upgrade + lower duration
Plan downgrade + higher duration
Plan downgrade + lower duration
(everything tested moments after the initial subscription + 6 days after initial subscription)

Hey Martin,

Thank you for sharing this with others! This sounds cool

Cheers!

Hey Kiuega!

Hmm. This could be due to another change in newer versions of the API. In the version of the API used in this tutorial, the total property that's returned from Stripe would be a negative number when going from yearly to monthly. After completing the change, that negative balance would be added to the "Customer" so that future invoices would automatically be lower. If you're seeing 0 for total, I bet that data is stored in another place or there is some other little tweak that needs to be made to get things working correctly.

Let me know what you find out :). We use this exact feature here on SymfonyCasts.com but using an older API version.

Cheers!

Okay! I will also come back to this in a while to see if there is anything to do for the new version and I will tell you here

Same problem, is there a solution ?

Hey Kiuega !

Ah, we missed replying to the original comment! A fail for us! As I just replied above - https://symfonycasts.com/sc... - I'm guessing that on a newer API version, the data must be available somewhere else. As Chris mentioned, after you complete the change from yearly to monthly, the account balance *is* correctly applied to the user. So the question is: where is Stripe exposing that data before the change? It's *possible* that they're not exposing it now, but that would surprise me.

Do you see any other data in the upcoming invoice that's useful?

Cheers!

Hey alexchromets

Nice question, and actually it look's like it is but we have a note about it on our code blocks. The thing here is that the currentPerdiodStart may change after saving the new plan, and it has an special meaning for Stripe:

        // if the duration did not change, Stripe will not charge them immediately
        // but we *do* want them to be charged immediately
        // if the duration changed, an invoice was already created and paid
        if ($stripeSubscription->current_period_start == $currentPeriodStart) {

Cheers!