#dominikganic_best-practices

1 messages · Page 1 of 1 (latest)

strange plumeBOT
#

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

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

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.

terse trail
#

What I have expected:

  1. The backend has updated the subscription to a higher price and creates a new invoice and sets the subscription to "past_due" or "incomplete"

  2. The customer receives a new invoice item

  3. The customer pays the invoice with his freshly delivered payment intent

  4. The invoice is paid

  5. The subscription is "active" now (change completed)

fossil parrot
#

Hi, no you should not need to create a new subscription. You'd want to update the existing subscription.

What does 'As I haven't received after ->update() to a higher subscription ANY invoice with the remaining amount to pay (19,99€ from prorations)' mean?

terse trail
#

Well the thing is, I perform the ->update() method in my backend to receive a payment intent client secret which I can set up to my payment elements so the customer can pay the remaining value.

But that is not the case because ->update() already updated the subscription which is now active (the new higher plan).

#

I've expected it will be set to incomplete (the updated subscription)

fossil parrot
#

If the subscription already has an existing default payment method, you would not need to collect another paymemt method.

#

What are you really trying to do here?

#

What is your business use case?

terse trail
#

This modal shows the user the proration results.
You can see on the bottom "You should pay 29,96€ for this upgrade"

image.png
fossil parrot
#

In gerenal, the subscription will already be active in the 'old' price. You update the subscription with the new price, if proration is applicable it will be applied and the payment method on the subscription would be charge for the difference on the next invoice

terse trail
#

Now when the user clicks on "Abonnement wechseln" it will perform in my backend the ->update() method

#

But I haven't charged him yet 29,96€
You might be right with the payment method, I will take a look now if it has been billed

#

Yes you are right. The "next" invoice has been set up with new positions for the new subscriptions.

#

But I'd like to instantly charge the user if that's possible

#

Otherwise he can upgrade to a higher plan, consume our pro features and switch back to the basic plan.

terse trail
fossil parrot
#

So you're all set?

#

If not, can you ask your latest question here?

#

Jumping between threads so when you rubber duck, I can't clearly see where you need help

terse trail
#

I think so, I'm just testing it out now and will let you know in a second

fossil parrot
#

Sounds good!

terse trail
#

Alright the charges are perfect, the invoices are created. Looks promising.

I have another question now.

This is currently the following case:
The customer upgrades from Plan A to Plan B (next greater plan). He consumes our pro-features. He has paid the proration amount of 30€ for example.

Now within the next 20 minutes the user switches back to Plan A from Plan B and will receive a proration credit of 30€.

That means basically: He hasn't paid actually anything to consume our pro features. I guess that's a vulnerability in my subscriptionsystem.

Is there any chance that I can disable downgrades back within the cycle?

What I expect is: Once he has upgraded the plan he can't downgrade until the subscription cycle is reached.

So he must stay with the Plan B until it's cycle has ran out to automatically switch back to Plan A.

I guess there is something like Subscription Schedules that I can consume for this right? 🙂

fossil parrot
#

Wow, that is a long text. Catching up

#

That amount should be prorated for that 20 minutes no? Are you saying something else?

#

Also, who is updating a subscription after 20 mins? 😄

terse trail
fossil parrot
#

This is a bit more complex API

terse trail
fossil parrot
#

Yeah, I understood.. but to me if I update a subscription I do not want to spend the time to change it again. Maybe that is just me

#

That sounds good

#

This tools allows you to travel through time in the API

terse trail
#

Another question:

Subscription is in past_due with 49€ (Flayvor Plus)
User downgrades to a plan for 29€ (Flayvor Starter)

Now the always_invoice proration_behavior of my upcoming invoice did "ignore" the recent open invoice. That's not good.

strange plumeBOT
terse trail
#

Is there any way to see the entire protocol for a proration?

#

So I can follow up each step how stripe has calculated a proration price? That would help me a lot.

misty citrus
#

Hi there. Stepping in for my colleague

#

You can preview prorations on an upcoming Invoice, but no, we don't expose something like a proration calculation or explanation

terse trail
#

Is there any chance I can setup change / proration limits?

For example my customer can only change his subscription "ONCE" a month not multiple times?

misty citrus
#

Not directly; you would have to manage that state on your end. If you were using the Billing Customer Portal to allow your customers to manage their Subscriptions, you could do something like reacting to Subscription update webhook events and turning off the ability to update the Subscription in the Billing Portal Configuration until the Subscription cycles again