#zaddler_unexpected

1 messages · Page 1 of 1 (latest)

frank cedarBOT
#

👋 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/1215608850401460225

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

worthy waspBOT
#

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.

fair stone
#

👋 happy to help

#

would you mind sharing the invoice ID where you think there's something wrong?

subtle nimbus
#

Hi

subtle nimbus
#

If you had already charged 1 usd in_1Os0g8GGleJkx5qoyiQkJYwB

for the change of plan, then it changes back to premium, and then in the same month it changes to premium plus, because it charges again for 1 usd in_1Os0hfGGleJkx5qouavjO6Eh

If already on this invoice did it in_1Os0g8GGleJkx5qoyiQkJYwB in the same month?

fair stone
#

taking a look give me a minute

subtle nimbus
#

Alright

fair stone
#

I think this happened because you were on a test clock and you haven't advance it before creating the next subscription update

#

which means that for our system the actual state of the subscription was still the same

#

meaning it was still an update from Premium to Premium Plus

subtle nimbus
#

So how is it solved?

fair stone
#

just advance your test clock before applying the change

#

the second time

subtle nimbus
#

But that is in test mode, how is it solved in production mode? Why can this case happen in production mode?

fair stone
#

it won't happen because the clock won't be frozen

#

when using test clocks you're freezing the time at a certain timestamp

subtle nimbus
fair stone
#

to the second

worthy waspBOT
subtle nimbus
#

So if I'm testing, should I always move forward in time to simulate as if it were in production?

stark nymph
#

yes

subtle nimbus
#

I just did the test and it still has the same behavior

#

Does it have to do with this parameter?

subscription_proration_behavior: subscriptionItems[0].plan.amount < newPrice.amount ? 'always_invoice' : 'none',

#

Because it is always valid if the plan to change is cheaper or more expensive than the previous one.

stark nymph
#

can you show me an example of the Subscription ID you're looking at and what you expect to see and what you saw instead?

subtle nimbus
#

sub_1Os140GGleJkx5qo7p3Siqsm

#

In this subscription, I generated a last invoice, you should not generate another invoice because you had previously paid it in the same month

stark nymph
#

which invoice is it specifically that you think should not have been generated?

subtle nimbus
#

This was the behavior:

  1. Free to Premium. (2.99 the invoice came out);
  2. Premium to Premium Plus (0.99 bill came out):
  3. Premium Plus to Premium (2.99 in the next month):
  4. Premium to Premium Plus (0.99 the invoice came out) (I already paid this)
subtle nimbus
subtle nimbus
stark nymph
subtle nimbus
#

Or what parameters should I use for this particular case?

stark nymph
#

hmm I don't really understand.

let's go back to
Free to Premium. (2.99 the invoice came out);
Premium to Premium Plus (0.99 bill came out):
Premium Plus to Premium (2.99 in the next month):
Premium to Premium Plus (0.99 the invoice came out) (I already paid this)

what do you want to happen instead?

subtle nimbus
stark nymph
#

I'm not really understanding where you get these .99 figures from(that's not what the actual figures are in the Subscription you posted).

Proration is time based, not amount based. When you do "Premium to Premium Plus" as an API call at time X what happens is

  • the percentage of the billing period remaining from X to the end of the period is taken( pretend it's 80% in this example like X is June 5th and the period ends June 31)
  • 80% of the price of Premium Plus is added as a positive invoice item to be charged
  • 80% of the price of Premium is added as a negative invoice item to be deducted (this is time the customer already paid for on Premium that they are now not getting)
  • if you use always_invoice those two invoice items are charged immediately.
  • if the overall invoice is negative (like if Premium costs much more than Premium Plus or so on), the invoice is paid and the negative amount is added to the Customer object balance and will offset the balance on future invoices
  • if you use create_prorations those two items will be included in the next invoice on June 31(which also charges for the upcoming month of July on the Premium Plus plan)
#

I know that doesn't directly answer your question but I think we need to get on the same page about how upgrades/downgrades/proration actually works in Stripe(and often it is not what people want but it works the way it does and the only other option is disabling it and calculating the amounts yourself)

subtle nimbus
#

Yes I understand what you are saying, but I want it to be something automatic, if you change from a cheap plan to an expensive plan, an invoice will always be generated, to be able to take advantage of the plan that the user wants to change, but it may happen that the user regrets it and downgrades. cheap plan, that the invoice will be generated in the following month, but if I change again to a more expensive plan, it will generate an invoice, which is wrong, but I don't know how to handle this case, I don't know if I could do something automatic

stark nymph
#

maybe mark in your database or on metadata on the Customer object the last time they did an upgrade to the expensive plan and if that date is within the current billing period when you're processing a request to do a change, refuse to do the upgrade(or call the Stripe API using proration_behavior:none, whatever makes sense in this use case).

subtle nimbus
#

You mean creating metadata in the customer every time there is a change of plans, right? It could be useful

stark nymph
#

yes, something like that.