#xpass

1 messages Β· Page 1 of 1 (latest)

mystic falconBOT
drifting spade
#

Hi @rustic island thanks for waiting.

#

Can you share with me the subscription ID?

rustic island
#

Sure thing! I have deleted the prorations to this subscription manually but it was the most recent occurrence: sub_1MWo5tBsacHnliWQqzgWV647

drifting spade
#

I don't see any changes to this subscription

#

can you share with me the ID of subscription that you updated earlier?

rustic island
#

@drifting spade Hmm are you able to see this event? evt_1MwBSKBsacHnliWQoWMk1km4 this was the quantity change today @ 2:43p PST from 18 to 19

#

Sorry that was one from yesterday, this one was today – evt_1MwZq3BsacHnliWQUvLVRoK8

drifting spade
#

Or can you show me an example of it seems to sometimes just charge the entire amount for 6months immediately even if the quantity < 100

rustic island
#

Yup, here's a subscription that did that yesterday: sub_1MGohmBsacHnliWQOCFe9VmP

#

The event where the customer changed quantity from 4 to 5 for that subscription is here: evt_1MwCIOBsacHnliWQXLfpTmIl

drifting spade
#

Thanks, and is it about this invoice in_1MwCILBsacHnliWQEMKElcan ?

rustic island
#

^^ It is

drifting spade
rustic island
#

Yes I understand, however the customer had already been setup for their next payment to be invoiced Oct 12th, I'm just trying to figure out why changing the quantity from 4 to 5 with always_invoice would be charged if the customers subscription has already been paid.

According to the documentation of always_invoice: "Always invoice immediately for prorations." and prorations in that request should be == $0.00. So why did prorations == $498.85?

drifting spade
#

That $498.85 usd is the Remaining time of 5x standard plan after 12 Apr 2023, and that's the prorated amount

rustic island
#

Got it, and that would make sense if I could replicate it haha

However, when I change the quantity of that subscription in the subscription editor it doesn't show any prorations for adjusting the quantity, AND it keeps the next charge date the same price, this is expected behavior that I am trying to replicate. The prorations for any quantity change under 100 should be $0.00 (at least that's what this shows, even when I change to charge immediately which is what that req you sent was)

drifting spade
#

Are you using the editor to preview the same subscription?

rustic island
#

@drifting spade Yup! This is a video of sub_1MGohmBsacHnliWQOCFe9VmP

drifting spade
#

Ok, you are only changing the quantity right, not the price?

rustic island
drifting spade
#

Then the proration amount is 0 in this case as long as the qty is < 100. And that' why the invoice amount shows 0 if you choose to invoice immediately

rustic island
#

^^ Agreed, again that makes total sense. But when I made that POST req to change the subscription quantity from 4 to 5 it charged my customer $498.85...

#

According to your logic Then the proration amount is 0 in this case as long as the qty is < 100 that shouldn't happen right?

drifting spade
#

That's the because you have a discount earlier. When applying changes to existing subscriptions, discounts don’t affect the resulting proration line items (i.e., the 5x standard plan).
So basically the proration = $498.85 - $0 (the previous amount that your customer paid due to 100% disount)

rustic island
#

Cool, that makes more sense.

So hypothetically if I were to do another POST changing quantity from 5 to 6 with "always_invoice" it would charge my customer again another $498.85. Because the previous amount for the initial subscription was 100% off? or is that discount no longer relevant after 1 charge?

drifting spade
#

And the discount doesn't apply anymore.

rustic island
#

Okay I understand, so this is a big problem for us because all our customers started their subscriptions with a discount.

For example that very first subscription I sent sub_1MWo5tBsacHnliWQqzgWV647 this customers discount was just $100 off so they actually paid $399 on initial subscription setup and when they increased quantity from 18 to 19 today there were 2 proration adjustments that I had to delete before they were invoiced: One was $303.03 and the other -$242.30

How can I prevent this from happening for discounted customers?

#

(For the time being I have just set "proration_behavior" to be "none" so we don't get unwanted charges to our customers but this becomes a problem when quantity > 100)

drifting spade
rustic island
#

In the events

drifting spade
#

Ok, that's different from the 100% OFF discount subscription earlier. In this subscription the customer was paying $399 in the begining, not $0, and that's why there's will be an adjustment.

#

And yes you can set proration_behavior to none if you don't want to prorate.

rustic island
#

Per your note earlier would this still apply? your customer won't get charged in this case because they already paid the 5x standard plan earlier because this customer already was charged 399 for the standard plan earlier why would they need to have a proration adjustment if quantity < 100?

drifting spade
#

But you are changing the price here. From price_1MUh8WBsacHnliWQXBRFNyk4 to price_1Mtk2pBsacHnliWQKbEpbDz1

#

It's a different case.

rustic island
#

The price was changed yesterday 04/12, and as of yesterday everything was functioning properly with no prorations for the price change and next invoice date of Aug 1.

The proration was with the quantity subscription change event (same as the other subscription we looked at) that was triggered today 04/13 at 4:46

drifting spade
rustic island
#

Correct that was the event from yesterday, no prorations were triggered for that event. However this event from today did trigger prorations https://dashboard.stripe.com/logs/req_u3GTETnjzZTB6b even though the subscription editor when tested yesterday AFTER changing the price said changing quantity would not cause prorations.

#

I wish I could help you solve all these other peoples problems for you I feel bad bugging you with all the incoming requests haha

drifting spade
#

Thanks for waiting, discord is a bit busy. let me take a look

#

It's related the earlier update request, in which the proration_behaviour was set to none, So proration was not created at that time.

and because the new request has proration_behaviour:create_proration, it creates proration this time.

rustic island
#

Of course, take your time i'm not in a rush. And this is starting to make more sense!

As i'm going through customers it is definitely only a problem with customers who signed up with discounts. Take this subscription as an example: sub_1Mcb61BsacHnliWQ54RsE9C4

I'm now seeing the prorated charges for changing quantity on the subscription editor takes a deep breath this is good lol

So my question for you is if I went through every subscription that had a discount and just increased their quantity by 1, thus triggering the prorated invoices and then I manually deleted those newly generated invoices, would that get everyone back to where I need them to be? (aka not being charged for always_invoice as they increase quantities over the next 6months)

drifting spade
#

If you don't need proration (as far as I can understand), you can just uncheck the Prorate charges options when updating the subscription.

rustic island
#

Well I don't need prorated if quantity < 100

#

That's the problem here, is the specific times I need prorated. When building the structure of this I assumed I could just always_invoice and if quantity was < 100 it would be fine and just give me a $0.00 invoice, the discounts were just not documented as being included in prorated. Stripe needs to add a "prorated_discount_behavior" key πŸ˜…

#

That being said per your message earlier It's related the earlier update request, in which the proration_behaviour was set to none I need to create a new update request that resets this proration behavior and clears the discounts from being included in prorations.

drifting spade
#

Then you can do it conditionally, you can set proration if the quantity > 100 and set proration to non if it's < 100

rustic island
#

I had this thought as well ^^ but if the customer purchased with a discount and this is their 101th client then they will not just be charged ie $3 (if their 3 months into the 6months), they will be also be charged the subscription discount proration amount, as we see in my video above.

mystic falconBOT
void umbra
#

πŸ‘‹ Taking over this thread, catching up now

rustic island
#

Awesome thanks! let me know if you have any questions

void umbra
#

In your video, it only shows that the unit amount changes up to 70. I don't quite get what you meant by "if the customer purchased with a discount and this is their 101th client then they will not just be charged ie $3 (if their 3 months into the 6months), they will be also be charged the subscription discount proration amount"

rustic island
#

The video is meant to show that the customer will be charged for any quantity adjustments less than 100 (according to our graduated pricing this should not happen, but it does because the initial discount).

If the customer goes over 100 to say 101 they will for sure be charged the new prorated amount (we can call that $3 for the sake of simplicity from our graduated pricing) + any other prorations, that any other prorations is what i'm showing in the video.

The subscription from the video used a $100 off coupon on their first subscription and regardless of what you change that quantity to (5, or 7, or 70, or 101) it's going to tack on that extra amount from the coupon. This is not the behavior I want. See the attached screenshot, the invoice number should be (if we are saying it's $3 to go over 100) $502

#

Hopefully this makes sense, i'm sorta in the weeds of it a bit so if you need me to take a step back and give you a more top-down simplified outlook I can just let me know

void umbra
#

Can you share more about the expected behaviour $100 coupon in the first subscription?

  • If the customer makes changes to the quantity in the first month and the total amount is less $100, do you expect the customer to be charged?
  • If the customer makes changes to the quantity after the first month, does $100 coupon take into any consideration?
rustic island
#

Totally – so when a customer subscribes to our every 6month price some of them entered a $100 off coupon, this coupon only applies once to their initial order.

So for example I get the product for $399 instead of the typical $499. The subscription will however renew 6 months from now for $499

*Checkout the screenshot at the very top (in the initial post) customers are paying for a flat fee of 499 the $100 off is just a onetime discount, the total amount of their 6month subscription will never dip below 499

*The coupon has already been used and the customer has already paid $399 so changes to the quantity should have no affect whatsoever on the coupon or the total cost of the product UNLESS the quantity > 100 then the total cost should increase by $6/per

void umbra
#

The proration doesn't get prorated by the quantity, but the time used/left for the quantity set. If you upgrade the quantity during the mid of the subscription, it will prorate the newly added quantity for the remaining left.

#

Stripe proration doesn't work only by quantity as it will consider the time that is used for the newly added quantity as well

rustic island
#

And this is exactly how we want it to work! This structure works perfectly for our model because we need to charge customers instantly when they add a new quantity > 100 for the remaining time in their 6 month subscription. For example if a customer is 3 months in and they adjust to a 101th price we want to instantly charge them $3 and Stripe does that beautifully.

The problem is that prorations are taking the one time discount coupon into consideration when a customer updates their quantity in the middle of their subscription. @void umbra

void umbra
#

Hmm.. I don't think there is a straightforward way to do this! Let me think if there is any workaround

rustic island
#

I appreciate it! Definitely tricky indeed.

#

My initial solution quite a few messages up was to create a "temp" proration invoice and then immediately delete it, this would trick the system into not using the discount coupon in any future prorations because it would think it's already been prorated.

void umbra
#

As per discussion with my coworker, I don't think we have a good way to do this for updating in the first subscription cycle. One way I can think of is to set proration_behaviour to none and add invoice item with the prorated amount of newly added quantity on your own

rustic island
#

@void umbra Good ideas! Sorta surprised more people haven't run into this problem, it seems like adding a setting to coupon codes could be helpful to check a box that is like "Does not affect prorations"

void umbra