#hasan
1 messages ยท Page 1 of 1 (latest)
I have created them as 4 DIFFERENT plans and not monthly and yearly being variations of the same plan
Any particular reason for that?
Can you share some examples of what you're describing? API requests, or sub_xxx object IDs?
yes sure, 1 minute
yes, creating them as 2 variations of 2 plans hindered other features in the website
question on the side, I understood the ProrationBehavior = "none" in the SubscriptionUpdate option as change the subscription immediately, am I right or is there something I'm missing?
In my back-end code when configuring stripe I set the SubscriptionCancel mode to "at_period_end" and SubscriptionUpdate ProrationBehavior to "none". I intended by doing so, to cancel a plan when its period ends, and to update/switch a plan immediately.
I don't really understand this part. You can't configure an update to happen a specific timestamp โ it's always at the time of request
The proration_behavior parameter doesn't affect when the update happens, but if/how we calculate prorations for the update: https://stripe.com/docs/billing/subscriptions/prorations
oh okay, so when updating a subscription stripe always makes the change immediately?
I'm trying to understand the limitations of stripe when updating plans. The main problem is, that when I change plans, the change always happens immediately (just how I need it to happen) but I'm not always being charged immediately. When changing between pro plans or basic plans (the case mentioned above) the charging doesn't happen until the subscription period ends
Yes, if you want to perform an update at specific time you could use a trial, or a schedule: https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#upgrading-subscriptions
If you can share an example I can likely tell you the issue
so this is the page in my website where subscription/ update plan happens. currently i'm subscribed to basic monthly plan as you can see in the portal
Can you just share the sub_xxx ID? It's difficult for me to understand any issues from a screenshot
sub_1N807fE2PVITNBan6FBpYfOO
You're currently subscribed to basic monthly, sure. In your update what are you trying to upgrade/downgrade to? What happens when you do it? What is unexpected?
this is the subscription id of the new plan
Ok, what do you want me to check?
I can see some updates via the portal: https://dashboard.stripe.com/test/logs/req_SNl9pBqxIn8hDy
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
When we upgrade from basic monthly, to basic yearly for example the customer is no charged instantly but instead is charged at the end of the billing cycle
We need any change to the plan to cancel the old plan and force a new payment
could be cause by the fact that we subscribed to a plan and changed it within the same day?
I suspect the issue is that you're changing between plans that have the same billing interval (1 day) and the same cost ($99.99)
Checking something
ok thank you
Appreciate your patience. The reason we didn't immediately invoice for this upgrade/downgrade is because the billing interval is the same: https://stripe.com/docs/billing/subscriptions/upgrade-downgrade#immediate-payment
By default, the portal does not invoice for prorated changes, but you can change that in your portal config: https://stripe.com/docs/api/customer_portal/configurations/create#create_portal_configuration-features-subscription_update-proration_behavior
You'd pass always_invoice in this scenario
by changing proration behavior to always invoice, I can keep the same intervals and get invoice immediately?
Yes we'd immediately invoice and bill the customer for the price difference
okay great, will try it, thanks
Hi! I'm taking over from my colleague. Please, let me know if you have any other questions.
sub_1N93qrBwiuQ4yN6woyqNFTgV
this is a subscription from a different stripe account.
we have the same setup with 4 products:
2 daily: 1 basic and 1 pro
2 every 2 days: 1 basic and 1 pro
the difference being that each plan has a different price.
We implemented the suggestion made by your colleague, and changed the proration behavior to always_invoice
The problem persisted, the subscrition was changed succesfully, but the customer was not invoiced immediately and instead the next invoice is at the end of the billing cycle
I don't see the request where you updated the Subscription. Could you please share the Request ID req_xxx? https://support.stripe.com/questions/finding-the-id-for-an-api-request
thank you
will share the re_id
req_fE0ooxZxemJme8
this is the most recent request made, not if it belongs to the transaction i made
if not i can recreate the scenario of switching plans
not sure*
This is a request to create a Billing Portal session.
I need a request where you set the Subscription proration_behaviour to always_invoice
i changed it from my back-end code, does it have a req_xxx if it was changed in code?
Yes
req_W2AVranREcHsYm
But I am looking at this Subscription and I don't see any related Update request: sub_1N93qrBwiuQ4yN6woyqNFTgV
No, this is a request to create billing portal cofigs.
How are you sending that request?
Could you share the code please?
sure
here is where I create the portal session cnfiguration and under subscriptionupdate is the proration behavior mode set
I see. And do you actually go to the Portal and update it?
But creating a configuration for the Billing Portal doesn't update the Subscription
Do you want you customers to update the subscription in the portal? Or update it yourself via API?
in the portal
Hi there ๐ jumping in as my teammate needs to step away soon. My grasp on your concern currently is that you have a Subscription that you expected to generate an Invoice to charge for prorations when it was updated, but that you aren't seeing that behavior. Am I understanding that correctly?
yes, I need that when customers update plans, that they are charged immediately. What has been happening is that in plans of the same duration(subscription period) the plan is updated but customers aren't billed until current billing cycle is done
Gotcha, I see quite a few IDs in the thread, I hate to ask but would you mind sharing the ID of a Subscription where you saw this behavior again so I can be sure I'm taking a closer look at the right one?
on it
sub_1N93qrBwiuQ4yN6woyqNFTgV
i just switched from pro monthly to pro yearly(both 2 day duration for testing purposes)
Thank you, taking a look.
thanks
Alright, so I believe this is the update that you're referring to (the most recent one):
https://dashboard.stripe.com/test/logs/req_sgyHT5P1cMw0GB
Looking at the response for that, it looks like a new Invoice was generated (the ID is included in the response body) and that the Invoice was immediately paid. Is that different from what you're seeing?
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
Ah, didn't realize those weren't exposed. If you look at the Subscription's page in the dashboard, you now see 4 invoices, correct?
https://dashboard.stripe.com/test/subscriptions/sub_1N93qrBwiuQ4yN6woyqNFTgV
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
The customer had an existing credit balance, and that balance is automatically applied to their next finalized Invoice.
but how does the customer have a credit balance? Is it from the subscription he was already subscribed to?
Looks like they had an Invoice with a negative balance, which applied a credit to them:
https://dashboard.stripe.com/test/invoices/in_1N95EqBwiuQ4yN6wrGWquaW5
Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.
I think there is a misunderstanding from our part then, the main issue is that we want the customer to be invoiced the full amount immediately when he changes his plan; initially we had the proration behavior set to none which wasn't achieving this, your colleague earlier suggested we change it to invoice_immediately. How can we achieve the desired behavior?
That is what invoice_immediately does, unless I'm misunderstanding your goal. The Invoice that was 0 euro, was the initial amount for the prorations the subtotal the amount you were expecting it to be? (Ignoring that the Invoice was paid for by a credit balance for now)
Im sorry, I don't seem to follow:
given a product A of price 10$/month
and a product B of price 20$/month
if a user ifirst subscribes t product A and pays 10$, then instantly switched to product B, we need him to pay the full amount of 20$ additional dollar, so he payed 30$ in total that day.
we don't want any proration this is why we were setting it to none initially
Oh, so you don't want any prorations from the previous billing cycle, and you want to immediately move the Subscription to the next billing period and charge the full amount for that new billing period?
yes this is exactly what I want
Checking if that is possible via the Customer Portal.\
I don't think you can accomplish that via the Customer Portal. It doesn't look like it supports changing the billing_cycle_anchor which is needed to get the behavior you're describing.
Instead you'll need to update the Subscriptions directly, setting proration_behavior to none and billing_cycle_anchor to now. This will avoid calculating prorations, immediately move the Subscription to the next billing cycle by changing the billing cycle anchor, and processing an Invoice for the new billing period.
https://stripe.com/docs/api/subscriptions/update#update_subscription-billing_cycle_anchor
Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.
so one last question
what does the proration behavior parameter do exactly when it is set to none?
because we just migrated our payment from calling stripe APIs to customer portal and checkout as advised...
The proration_behavior parameter controls what behavior is used for calculating prorations for the request that includes it (it is not a "sticky" property that gets set on the Subscription, it has to be passed with each request where you want to use non-default behavior).
ok but what does it do when set to none?
Nothing, no prorations are calculated.
Any time!
would stripe need any developers, because the whole team just wasted 2 month of development and we might need new jobs ๐ฅฒ