#sergx_api

1 messages · Page 1 of 1 (latest)

glacial fiberBOT
west kelpBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

glacial fiberBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1235539146467184642

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

surreal spindle
# 
$data = [
                'items' => (new StripeService)->getSubscriptionsItemsForUpdatingBusinessBulk($user, $businessPriceId, $employeePriceId, $businessQuantity, $employeeQuantity),
                'proration_behavior' => 'always_invoice',
            ];
            if ($coupon) {
                $data['discounts'] = [['coupon' => $coupon]];
            }
            $this->stripe->subscriptions->update($subscriptionId, $data);
#

Now let's update its subscription to
base plan x 2 (1 more) | addon x 5 (2 more)*

west kelpBOT
alpine urchin
#

hi!

Then, the payment should be:
I'm a bit confused, your proposed calculation doesn't take into account when the update happens, which is the core feature of how proration works.

surreal spindle
#

In the test I performed, the time difference between subscribing the user and upgrading the subscription by increasing the amount of the base plan and the addon was only a few minutes.

alpine urchin
#

ok. So we're on the same page, you are looking at in_1PBwsbKYINwhn6n40NX2gNvP too?

surreal spindle
#

yes!

#

The problem I see is that the 50% discount is being applied to all quantities (addon x 5) instead of (addon x 2) that was what the user updated, same with base plan, for that reason is generating the invoice with negative value

alpine urchin
#

This is how I understand it.

  • the first line is the proration for the new state, 2 quantity of that plan, for the rest of the month. It's $40 (20 * 2) and then has 50% off.
  • the second line is the proration for the new state, 5 quantity of that plan, for the rest of the month. It's $25(5 * 5), and then has 50% off.
  • the third line is the refunded proration for the old state, returning the $20 the customer paid.
  • the fourth line is the refunded proration for the old state, returning the $15 the customer paid.
image.png
#

this is just how it works. We calculate how much is to be charged(e.g. 2 * priceAmount * timeRemainingPercent(100% here) = $40), and then we apply the coupon(50% off $40).
The discount is not just for "the difference" between the quantities, it could work that way but it's just not how our proration+discount logic is built.

surreal spindle
#

I understand, I could set proration_behaviour as always invoice if the user didnt write a coupon

#

But in the case the user did write a coupon, how could I charge and get a payment of those 18,15€?

#

because if I set proration_behaviour as 'none' I won't get that 18,15€ too until next invoice I believe

alpine urchin
#

I don't see a way of doing it except calculating the amount of 18.15 in your own logic and then creating an InvoiceItem directly for that amount and creating an Invoice for that item

surreal spindle
#

Perfect thank you very much in that case for simplify I think the best solution is set proration_behaviour as always_invoice. I have tested in stripe dashboard to update the quantities once the discount were applied, and amounts are correct

#

Only that is a little bit weird that the customer sees in the checkout that is going to pay 18,15€ but then is not charging anything

#

For best practices, do you recommend to build the checkout with own logic based in quantities of inputs? Or it would be better to use API and get upcoming invoice, so data would be more reliable I guess

alpine urchin
#

I think using UpcomingInvoice is probably slightly better

surreal spindle
#

Perfect thank you very much @alpine urchin