#deathnfudge_api
trail stratusBOT
👋 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/1408456195844345978
📝 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.
- deathnfudge_api, 3 days ago, 13 messages
- deathnfudge_billing-portal-config, 3 days ago, 19 messages
static delta
Hi, can you share the configuration id with me, https://docs.stripe.com/api/customer_portal/configurations/object?api-version=2025-07-30.basil ? It should start with bpc_
Unless you set https://docs.stripe.com/api/customer_portal/configurations/create?api-version=2025-07-30.basil#create_portal_configuration-features-subscription_update-schedule_at_period_end, it should be billed immediately. Did you confirm that you set this?
hidden ingot
Here's the session. I'm looking at the portal configuration to make sure that hasn't been set. "bps_1RyvaiG6SOg4bQjghFnDDbsm"
Actually, here's the configuration ID. "bpc_1RyvahG6SOg4bQjgpzpRMxyk"
The first one is the session.created id
I don't see where we've set the schedule_at_period_end for subscription updates but I just confirmed that the invoice generated is scheduled to be paid on August 28 instead of charging immediately.
It's on this customer "cus_Su8dOinClWWj8V"
And here's the subscription. "sub_1RygF8G6SOg4bQjgYOuFWVyH"
The only period_end I see set though the API call is for subscription_cancel
static delta
Taking a look
static delta
That does not look like you used the Customer Portal. Instead, it looks like you created the subscription https://dashboard.stripe.com/test/logs/req_WhyoJZuoXLaYsR
Did you share the correct subscription id?
hidden ingot
I created it manually so I could backdate it in order to test what happens when a customer is near their subscription billing cycle end date. Then I updated the subscription in the billing portal and it created the invoice for August 28 rather than invoicing immediately. We don't create subscriptions ever using the billing portal. We use Stripe Checkout for subscription creation.
static delta
You can't create a subscription using the Billing Portal so that is expected. Can you share the invoice from that updat via the Portal?
hidden ingot
static delta
That is the upcoming invoice as you passed a backdate_start_date:
"1724821200" and billing_cycle_anchor: "1756357200"
Can you create a simple subscription and use the test clocks, https://docs.stripe.com/billing/testing/test-clocks to advance time. And use the Customer Portal to update the subscription via the Portal?
hidden ingot
Ok. Let me give that a shot.
static delta
Sure
hidden ingot
If it's helpful. Here's one that was not backdated with the same behavior. cus_Su8e2xvSBxibkl
Here was the event where the billing portal was used to update the subscription. https://dashboard.stripe.com/test/events/evt_1Ryx1vG6SOg4bQjg1MGbPe46
The generated upcoming invoice is set to charge at the end of the billing period.
https://dashboard.stripe.com/test/subscriptions/sub_1RyKMvG6SOg4bQjgALRMNbHi
I'll mess with the test clocks here in a bit.
trail stratusBOT
hidden ingot
Here's a subscription where I advanced time to August 12, 2026 and then went and upgraded through the billing portal. sub_1RyKMmG6SOg4bQjgHt6JoU5H
I'm seeing the same behavior.
steady escarp
👋 I'll be jumping in, just getting caught up.
steady escarp
Looks like you passed in an invalid parameter in the example you provided
req_DAwoi7EnVNSjqs
hidden ingot
Ok. Let me try it again.
Here's one I just did. I advanced time to August 10, 2026 and then went through the billing portal to update. It's giving the same behavior. sub_1RyKNJG6SOg4bQjgwtW5cEJL
steady escarp
Looking 🙂
steady escarp
did you change from "Charge or credit the full difference" to "Prorate charges and credits"
hidden ingot
I didn't but I'm double checking someone else did.
I still see "Charge or credit the full difference" set here. https://dashboard.stripe.com/test/settings/billing/portal
Is there a setting in the billing portal configuration that might be overruling that?
I don't see anything that should overrule it but I'm wondering if there's maybe a default setting coming from the API call to create the billing portal session that we need to adjust?
steady escarp
I was seeing "Prorate charges and credits" when I reviewed the account but now it's reflecting "Charge or credit the full difference" was just wondering if these settings were being adjusted while I looked at it
hidden ingot
I don't think anyone else is adjusting things but let me check with the team.
So far it doesn't look like anyone else is working with things under the hood.
trail stratusBOT
hidden ingot
Our production settings are still using the proration in case you're seeing that as well.
vestal lintel
👋 Taking over this thread, catching up now
vestal lintel
sub_1RyKNJG6SOg4bQjgwtW5cEJL used the Billing Portal session bps_1RyxmEG6SOg4bQjgq4HEVIBv (https://dashboard.stripe.com/test/logs/req_G0TV5kR20QBa2R) to update the subscription.
This session used configuration bpc_1RyxmEG6SOg4bQjgpeYALB6T created in https://dashboard.stripe.com/test/logs/req_1ahzPwsxKNRLBY, which set proration_behavior: "none". When ``proration_behavior: "none"`, it's expected that won't be any proration and no invoice will be issued for the proration.
Am I right to understand you would like to set "charge or credit the full difference" in the billing portal configuration using API?
hidden ingot
Yes. We currently want to not use prorations and charge for the full amount at the time of the upgrade.
For added context, we've have had quite a few instances of folks purchasing an upgrade a few days before the end of their subscription ends, paying a few dollars for the upgrade, and then having access to download the upgraded assets and canceling their subscription. We wanted originally to have them pay for a full year minus their time left on the subscription and move the billing cycle anchor but were told there's no way to do that through the billing portal. Customers would get double charged and there was no way to warn them about it once they hit the billing portal. Now we want to charge the full amount and then handle any proration/refunding on the back side of things. That way we can tell the customer they'll pay the full amount today, see that charge in the billing portal, then we can manage refunds/prorations using API calls.
The hope is that this will result in fewer upset customers than the double charge would.
vestal lintel
Thanks for sharing! Upon checking "charge or credit the full difference" is the Dashboard feature. This can't be done through billing portal configuration created through API.
hidden ingot
Ok. So that gives me a couple questions.
The API billing portal configuration overrides the dashboard settings completely? We had been operating on the assumption that the API call overrides the settings it sets, but leaves the other settings alone. It looks like we were not correct.
Is there any way to only allow upgrades from certain products to others using the dashboard? We have 6 main products but also several other legacy products. We only allow certain plan switches. For example a pro customer can upgrade to pro-plus, max, or max-plus, but a max customer could only upgrade to max. This is the main thing we're using the API configuration to control. Is there any way to control this using the dashboard?
Or is there a way to not allow switching to a cheaper plan through the dashboard?
vestal lintel
If billing portal configuration isn't set in the billing portal session created, the default one on the Dashboard will be used.
It might be possible to "charge or credit the full difference" through API. I'd recommend writing to Support https://support.stripe.com/contact if there is any private / beta feature for "charge or credit the full difference" via API.
hidden ingot
Ok. So there's no way to limit downgrades or which products can switch to other products using the dashboard?
If we could just prevent downgrades through the dashboard I think we'd be ok.
vestal lintel
For example a pro customer can upgrade to pro-plus, max, or max-plus, but a max customer could only upgrade to max. This is the main thing we're using the API configuration to control. Is there any way to control this using the dashboard?
If we could just prevent downgrades through the dashboard I think we'd be ok.
I'm afraid such a customisation is not supported in the Dashboard
hidden ingot
Ok. We'll check with support to see if there's a way to get what we need through the API.
trail stratusBOT
hidden ingot
How do we test the billing portal if we're not using the API? It wants to send an email, but our test users are not real email addresses. I'm not sure how to log in to see it with the test customer.
balmy stag
Easiest would be to create a billing portal session via the api for a test customer for testing purposes
We don't send many emails in test mode
Some things work if you use a test customer that has the same email as your account
But I don't remember off hand if portal is one of those things