#tofutiger

1 messages · Page 1 of 1 (latest)

carmine pikeBOT
wise breach
#

Can you share the request id for the update?

frozen stirrup
#

here's the event id evt_1OCmI8DLh2JRoEHWKUUCKRQV

#

I also see another subscription.updated event that did not make sense to me evt_1OCmIyDLh2JRoEHW3dpcOosu

wise breach
#

Ok one at a time

#

Let me look at the first

frozen stirrup
#

sure

wise breach
#

Ok let me get a colleague to look at this. This is a bit strange

frozen stirrup
#

thanks

carmine pikeBOT
lilac hearth
#

Okay so looks like the Subscription was updated via the Customer Portal (which is what evt_1OCmI8DLh2JRoEHWKUUCKRQV shows) where the Customer changed from price_1IHZHTDLh2JRoEHWr1sNdnzI to price_1KWqeWDLh2JRoEHWS2rrDHhl. When that happened the customer had already paid for 5 quantity of price_1IHZHTDLh2JRoEHWr1sNdnzI which was equal to $30 so that generated the first proration for Unused time on HiHello Business after 15 Nov 2023. Then, almost immediately afterward, your backend updated the quantity of price_1KWqeWDLh2JRoEHWS2rrDHhl from 1 --> 5 (see: https://dashboard.stripe.com/logs/req_tpUiNaS9FQi6EE) and that generated the upcoming $30 charge that will take place a the beginning of the next billing cycle.

#

So there were two updates that happened within a minute of each other

#

Which is why you see 2 proration items

frozen stirrup
#

something seems a bit off there, let me quickly take a closer look

#

The unit price for price_1IHZHTDLh2JRoEHWr1sNdnzI is $8 and they had paid for 1 unit. I don't see an event where they paid $30.

#

price_1IHZHTDLh2JRoEHWr1sNdnzI is the professional plan, not the business plan

#

evt_1OCmI8DLh2JRoEHWKUUCKRQV seems to have changed the plans but the quantity remained 1 in both?

lilac hearth
#

Ah sorry yeah let me clarify.

#

The way proration works is that it actuall isn't dependent on the previous payment taking place

#

I mispoke above -- basically if you look at the upcoming Invoice:

  • the $30 line item for HiHello Business (per user) is for the current Price that the customer is suscribed to and the charge for the upcoming billing period
  • the -$30 is due to the fact that the customer was on price_1KWqeWDLh2JRoEHWS2rrDHhl briefly due to the Billing Portal update (this is where it feels "off" but it just isn't how proration works -- it doesn't actually look for whether there is an associated paid Invoice or not)
  • the $30 for Remaining time on 5 × HiHello Business after 15 Nov 2023 is the remaining time for the current billing period while being on the current upgraded Price.
frozen stirrup
#

so to summarize the timeline of events: 1. customer changes plan from price_1IHZHTDLh2JRoEHWr1sNdnzI to price_1KWqeWDLh2JRoEHWS2rrDHhl. (from 8 to 30$ which I think should have resulted in a $22 charge due to the $8 proration?) 2. Our backend (I need to double check why we did this) asked for the quantity to be changed from 1 to 5 (and this triggered the +-30 because it is essentially the same price so they are asked for 30 but given 30 credit as well)

#

sorry I'm bad at formatting on discord

#

re-sending:

#
  1. customer changes plan from price_1IHZHTDLh2JRoEHWr1sNdnzI to price_1KWqeWDLh2JRoEHWS2rrDHhl. (from 8 to 30$ which I think should have resulted in a $22 charge due to the $8 proration?)
#
  1. Our backend (I need to double check why we did this) asked for the quantity to be changed from 1 to 5 (and this triggered the +-30 because it is essentially the same price so they are asked for 30 but given 30 credit as well)
lilac hearth
#

Hmmm one second

#

(Yes the above is correct but I'm seeing something I didn't expect so give me a sec to investigate that)

frozen stirrup
#

sure, thanks

lilac hearth
#

So yeah for 1/ that you described above, if you want the Customer to be charged immediately, then you want to set that to always_invoice, otherwise you want to set it to create_prorations (which is also the default) which would have caused proration to happen when the Customer Portal update occurred.

#

So yeah that actually seems to be the major missing piece here

#

And caused them to basically get some "free" time after their initial update since you didn't have proration enabled on that first update (that occurred via Customer Portal) but then proration was enabled when your backend performed the update.

#

bpc_1O0pVNDLh2JRoEHWeJe08tNp was the Portal Configuration used if you want to retrieve it and inspect it.

frozen stirrup
#

I see. So for event 1 up there, the customer updated their plan in the customer portal which changes their plan and if event 2 (from our backend) didn't happen, then they would've been invoiced for 30 soon after? But because event 2 happened, stripe gave them credit for the plan despite the invoice not being paid?

lilac hearth
#

then they would've been invoiced for 30 soon after?
No, since proration was off for the Billing Portal Update there would have been no Invoice and nothing would have happened until the next billing cycle at which point they would get charged for the updated Price/quantity

frozen stirrup
#

oh, that is good to know, so disabling proration allows customers to change plans without getting charged until the next billing cycle

lilac hearth
#

Yes

#

Which gives an overview of this as well

frozen stirrup
#

Thank you, that is useful to know. And basically the backend quantity change and proration really didn't do much because it was just +30-30=0

lilac hearth
#

Yep pretty much

frozen stirrup
#

ok, thank you both so much!