ptti_subscription-prorations-portal

[open valley]

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

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

[cerulean sedge]

More about "What are you working on?":
So my problem could also be solved if i could limit the redemtion of the coupon code to a specific price_id, not a product.

I would appreciate any help or thoughts on this, thanks in advance! ☺️ 🙏

[misty garnet]

Hi there 👋 can you share the ID of the Promotion Code object (promo_ prefix) and the ID of the Checkout Session (cs_test_ prefix) that you used when testing this flow?

[cerulean sedge]

Hi! Thanks for the timely response 🙂
Sure!

Here they are:
promo_1Q56hiJG4Z4Ybt20pzlSxYU1
and
cs_test_b1MWKfogG8LwW7MKRMrEQMFj3TpGhP5NnVhsRBpJAiywsers2V59IujcvD

[misty garnet]

Thank you! I'm taking a closer look at those

Hm, I'm not spotting anything that you did wrong here offhand. This might be something wrong on our end, or perhaps a limitation I'm forgetting about. I'm going to keep digging and let you know what I find, but it may be a bit.

[cerulean sedge]

Alright, thanks for your notice 🙏

[misty garnet]

Hm, I'm still not too sure what's going on here. Does the error persist if you remove the subscription_data.billing_cycle_anchor value from your Checkout Session creation request?

[cerulean sedge]

I tried not setting the subscription_data.proration_behavior and subscription_data.billing_cycle_anchor in the creation of the checkout_session and the promocode was applied successfully!

But I need to set those two parameters because I do not want proration.
And when I do this by setting subscription_data.proration_behavior to "none", I also have to pass a subscription_data.billing_cycle_anchor.
Otherwise, I get this error:
Stripe Error: Request req_CmjzwMZSKSAddN: The proration_behavior parameter can only be passed if a billing_cycle_anchor exists.

[misty garnet]

What you're running into, is that setting a billing_cycle_anchor date and proration_behavior as none means there is no first payment for the Subscription. No payment will be made until the billing_cycle_anchor timestamp, which trips this promotion code behavior restriction:
https://docs.stripe.com/billing/subscriptions/coupons#set-a-minimum-amount:~:text=Because promotion code restrictions are checked at redemption time%2C the minimum transaction amount only applies to the initial payment for a subscription

[cerulean sedge]

Okay, so how do I make sure that prorations are disabled then?
Is the only way to do this by updating the Subscription object with proration_behavior="none" after the subscription has been created?
Are there other options?

[misty garnet]

What prorations are you wanting to disable?

proration_behavior isn't a "sticky" setting. Setting it to none doesn't disable all prorations for the lifetime of the Subscription. It's a per-request setting instead, so setting it on Checkout Session creation only indicates the initial Subscription creation shouldn't create prorations.

[cerulean sedge]

I am confused - I think I want to disable all prorations..?

Side note:
I've been always looking for a neat solution to allow instant-prorations on an upgrade, while not allowing instant-prorations for downgrades.
Maybe I got the concept of prorations wrong then...

[simple hamlet]

Hi 👋

I'm stepping in as my colleague needs to go

To be absolutely clear, you cannot "disable all prorations" unless you pass proration_behavior="none" on every update request.

[cerulean sedge]

Okay, hi @simple hamlet and thank you so far @misty garnet !

[simple hamlet]

Every time you make a change, you need to tell the API whether or not that change should trigger prorations.

[cerulean sedge]

Okay, now I understand it is not a sticky setting.

Thing is: I wanted to set it to "none" in order to disable prorations when changes to the subscription are being made via the customer portal. How do I disable prorations within the customer portal then?

[simple hamlet]

You would specify that in the customer portal configuration through the features.subscription_update.proration_behavior parameter
https://docs.stripe.com/api/customer_portal/configurations/create#create_portal_configuration-features-subscription_update-proration_behavior

[cerulean sedge]

Is there a way to make this configuration "sticky" in the customer portal?
So I'd like to have a static link that can be shared with my customers (instead of creating a new billing_portal.session every time)...

[simple hamlet]

I think you are confusing how these two apis work

For the Customer Portal, you create a Configuration object (that is the link I sent). It defines how you want your Customer Portals to operate. You then specify the ID of this Configuration when you create your Customer Portal sessions. That will make this setting "sticky"

[cerulean sedge]

Ah I suppose I can set "is_default" in my customer portal configuration object so it will be loaded for any (default) customer portal session.

[simple hamlet]

When you create the Portal Session you specify the config ID like so

portal_session = stripe.billing_portal.Session.create(
  customer="cust_123",
  return_url="https://my.nifty.website.io"
  configuration="bpc_123"
)

You would need to add the configuration parameter to your code, that would make it "default"

[cerulean sedge]

Yes, I think I got that. But I do not want to create a new Portal Session via API every time.
Instead, I just want to share the "static" link that i got from the dashboard.
In my test environment, this is https://billing.stripe.com/p/login/test_eVa4hKa7wghkaLS7ss for example.

[simple hamlet]

We focus on developers coding integrations with the APIs here so that is where our advice will mostly be about

I don't know if there is a way to confiture this in your Dashboard

[cerulean sedge]

So this would work if I create a new customer portal configuration with prorations disabled and set it as the default configuration. I suggest, opening the link above will create a customer portal session with the deafault configuration then...

[cerulean sedge]

I see. I'll just try it out then 🙂

[cerulean sedge]

Regarding my side note:
Do you know a way to distinguish the proration behavior between up- and downgrades via the customer portal?

[simple hamlet]

Do you mean you would want to create prorations for one but not the other?

[cerulean sedge]

yes

[simple hamlet]

I don't think that is something you can configure directly in the Customer portal. If you wanted that kind of logic you would need to build the UI for managing Customer Subscriptions yourself.

That way your code could examine the change the customer is requesting and determine if it was an upgrade or a downgrade.

Looking at the Customer Portal Configuration object, it only has a proration_behavior parameter for all types of updates, not specific to upgrades or downgrades.

[cerulean sedge]

Okay, imma try out the default config for the customer portal and let you know if it worked or not.

Btw: There is no way to restrict a promo_code to a specific price_id, right?
It can only be limited to the product...

[simple hamlet]

Coupons can be restricted to a product but not to individual prices, correct. It's a common request.

Promotion Codes are created on top of Coupons so they inherit those restrictions from the Coupon