Upgrade: Processing the Upcoming Invoice

Hey! In case we have a plan that has price ranges (depending on the units). Imagine a user who has a subscription with 150 units. He wants to modify his subscription and take only 100 units but for the same plan (or else for another plan with units, or just change plan for another plan with a fixed price, without quantity), in this case we must specify the quantity in our function, what that it happens.

So, should I have something that looks like this:

public function getUpcomingInvoiceForChangedSubscription(User $user, SubscriptionPlan $newPlan, $quantity = 1)
    {
        
        $stripeCustomer = $user->getStripeCustomer();
        $data = 
        [
            'customer' => $stripeCustomer->getStripeCustomerId(),
            'subscription' => $stripeCustomer->getSubscription()->getStripeSubscriptionId(),
            "subscription_proration_behavior" => "always_invoice",
        ];
            
        $stripeSubscription = $this->findSubscription($user->getStripeCustomer()->getSubscription()->getStripeSubscriptionId());
        
        if($newPlan->getPlanId() == $stripeCustomer->getSubscription()->getPlan()->getPlanId())
        {
            
            $subscriptionItems = [
                [
                    "id" => $stripeSubscription->items->data[0]->id,
                    'quantity' => intval($quantity),
                ]
            ];
        }
        else
        {
            $subscriptionItems = [
                [
                    "id" => $stripeSubscription->items->data[0]->id,
                    "deleted" => true,
                ],
                [
                    "plan" => $newPlan->getPlanId(),
                    "quantity" => intval($quantity),
                ]
            ];
        }

        $data["subscription_items"] = $subscriptionItems;

        dump(\Stripe\Invoice::upcoming($data));
        return \Stripe\Invoice::upcoming($data);
    }

Now, in my controller, on the <b>previewPlanChange function</b>

            $stripeInvoice = $stripeClient->getUpcomingInvoiceForChangedSubscription($this->getUser(), $plan, $quantity);
    
            $currentUserPlan = $this->getUser()->getStripeCustomer()->getSubscription()->getPlan();
    
            /* contains the pro-rations *plus* - if the duration matches - the next cycle's amount */
            $total = $stripeInvoice->amount_due;
    
            if($plan->getDuration() == $currentUserPlan->getDuration())
            {
                $total -= $plan->getPrice() * 100;
                dump($total);
            }
    
            return new JsonResponse([
                "trial" => false,
                "total" => $total/100
            ]);

It works if I increase the quantity. On the other hand, if I decide to decrease the quantity, then, systematically, the "amount_due" will be equal to 0 while the "total" will have the good value taking into account the prorations.

The point is if I change :<b>$total = $stripeInvoice->amount_due;</b> by<b>$total = $stripeInvoice->total;</b>
I'm not sure if it's "correct".

Note that I only have this problem in the preview of the invoice. If I confirm, Stripe will do the prorations, the calculations according to what I have to pay, what I have left in my balance, etc. The problem really lies in the preview of the invoice when changing plans

Hey Kiuega!

We do some pretty advanced stuff like this in our site too with the number of "seats" on your team (you can increase/decrease them). To be honest, this stuff is VERY complex, and we have learned how to do it through trial and error - much like what you're doing. In other words, make a change, look at the API response, and reverse-engineer which "properties" appear to be the ones that you want. Stripe's docs are good... but sometimes things are so advanced, that it's not perfectly clear what to use. While it's very strange for there to be 2 different properties depending on an increase vs decrease, it doesn't surprise me too much. The BEST thing about Stripe is how stable their API is. If you find that this situation works for you today, it will continue to work for you tomorrow. We add a lot of logging to our codebase in these types of situations: if we find that an assumption "looks" wrong, we log an error that goes to our Slack channel so that we can look into it and, if necessary, tweak the codebase. That doesn't happen often - you get to a pretty stable situation pretty fast. Also, we're on a different API version that you're using - so I can't compare the exact fields you're using with the one's we're using - there could definitely be differences across API versions.

Sorry I can't give you a better answer... but I *do* think what you're doing is the right direction.

Cheers!

Hello weaverryan

I think I have found the right solution that can work in any case!

From now on, instead of recovering the "amount_due" value which can sometimes be problematic, I recover the "total" which corresponds to the price to be paid (without counting the balance of the user).

In StripeClient.php I created a function which returns the amount of a customer's balance. And another function which will calculate the real price from a total price taking into account the balance of the user.

And it works !

I also take into account the trial periods. This means that a trial user who wants to test with more seats can. But when previewing the next invoice, I tell him "You have X trial days left. After that, you will be debited with X €".

Now, I don't know if the "total" attribute also takes into account a reduction coupon that would have been applied. Otherwise, this fact must still be taken into account.

EDIT : The reduction coupon is taken into account! No need to code more, everything seems operational!