#aiua

1 messages · Page 1 of 1 (latest)

lone zenithBOT
barren palm
#

I'm afraid this is not possible with customer portal. It can only be implemented in your system, i.e. your own UI and logic for upgrading and downgrading the plan

marble badge
#

I got it.

If I were to implement this myself, I would use "always_invoice" for the first upgrade of the billing cycle and "none" for the other upgrades.

I am concerned that if a user makes a request just before the end of a billing cycle, it will be the next billing cycle.

The solution is to reject the request a few minutes before the next billing cycle.

Is there another solution?
For example, is it possible to specify the relevant billing cycle and have it validated when the request for a subscribe update is sent to Stripe?

Translated with www.DeepL.com/Translator (free version)

#

I would like to know if there are any best practices for this case.

barren palm
#

I am concerned that if a user makes a request just before the end of a billing cycle, it will be the next billing cycle.
What is the concern here? Can you share the use case?

marble badge
#

Let's say it is always_invoice at the 1st upgrade within the billing cycle.

After the second time, set it to none.

If a request comes in with none at the same time as the next billing cycle comes in and is processed as the next billing cycle, you will not be able to bill for the difference, even though you would normally want to bill for the difference the first time in that billing cycle.

For example
You have a $5.0 plan and a $10.0 plan, and within one billing cycle
You have a user who changes between the two plans multiple times.
You want to treat the second upgrade to the $10.0 plan as none, but if it is treated as the next billing cycle, the upgrade will not result in a payment in the next billing cycle.

Sorry for the poor explanation, but do you get the point?

barren palm
#

Sorry, I don't really follow. My understanding from our past discussion is that customer will be prorated for the first upgrade and no proration for the subsequent upgrade and downgrade.

In the first upgrade with proration_behavior: 'always_invoice', customer will be billed with the amount differences.

In the second upgrade/downgrade onwards with ``proration_behavior: 'none'`, customer won't be charged for the amount difference as long as the subscription is still in the existing billing cycle. When the next billing cycle comes, customer will be charged for the new upgraded plan

#

There shouldn't be a situation which the customer will be charged in the existing billing cycle if proration_behavior is set to none

marble badge
#

I'm sorry to bother you again

Suppose you are a subscriber who is billed on the 19th of each month.

If we receive a request for a second or later upgrade from June 19 to July 19, we will assume none, but we are concerned that if we send the request at the 7/19 changeover, we will receive that none request as the next billing cycle (for July 19 to August 19). .　Even though I want it to be always_invoie since it is the first one for July 19 to August 19.

barren palm
#

I see! In this case, your system should include the logic when the upgrade request is submitted. If the request is submitted on the billing day, then the proration_behavior should be set to always_invoice

marble badge
#

Understood. I understand that you should always use proration_date=always_invoice if you want to upgrade to the invoice date. I don't need to set proration_date in this case, right?

barren palm
#

Yes for your use case

marble badge
#

Thank you very much.
Sorry, may I ask two more questions?

(First)
I think the maximum session time for customer_portal was 2 hours.
I was wondering if what I want to do is also use subscription_update_confirm by customer_portal.

What if we use the API to provide the user with a customer_portal set as always_invoice for 24 hours before the billing time, so it cannot be abused?

(second)
Is there an easy way to determine if a user has made a plan downgrade during that billing cycle period (i.e. June 19 to July 19)?
At the moment, I am thinking of storing the downgrade records in our own server database.

barren palm
#

(First)

I think the maximum session time for customer_portal was 2 hours.
From https://stripe.com/docs/customer-management#customer-portal-features: Portal sessions are temporary. New portal sessions expire after a 5 minute period. If a customer uses it within that time period, the session expires within 1 hour of the most recent activity.

What if we use the API to provide the user with a customer_portal set as always_invoice for 24 hours before the billing time, so it cannot be abused?
Which API do you plan to set?

#

(Second)

Is there an easy way to determine if a user has made a plan downgrade during that billing cycle period (i.e. June 19 to July 19)?
If you're referring to the history, your system should keep track of the upgrading/downgrading history yourself

marble badge
barren palm