#tanquish_api
1 messages ยท Page 1 of 1 (latest)
๐ 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/1349573124412280832
๐ Have more to share? Add more details, code, screenshots, videos, etc. below.
hello! Going through what you wrote, gimme a while
Thank you Alex ๐ I'm gathering a few screenshots to make it more understandable
Can you elaborate more on what specific issues you're running into?
Related to the multiple stripe events per single subscription.update, this happens. We're not sure if this is because we're updating the billing_anchor to now but there is multiple events.
I don't know what else would be useful, but let me know
How do I get this behaviour while maintaining our Customer Portal (with custom configuration)? We running into a lot of issues
Can you elaborate more on what specific issues you're running into?
We are getting a lot of Stripe events for a single subscription.update and we don't know how to filter them
Can you share what is the specific issue you're facing with a lot of Stripe events? Why do you want to filter them? Or to rephrase it in a different way, what are you trying to achieve here, and what are the problems you're running into while attempting to do so?
with regards to the many events you're receiving, all I can say right now is that you can define what events you want to be sent to your webhook endpoint in the Dashboard. It would be helpful to get more context so that I can provide more specific advice
Hi @unreal eagle I'm also an engineer from Stripe, can you share with me the subscription ID?
For sure, apologies
Can you elaborate more on what specific issues you're running into?
From my understanding, the natural behaviour of proration with the Customer Portal is that it charges the difference of the new plan within the existing cycle and it does not allow the billing cycle to be reset from the UI. Our objective is to find a way to implement the new proration behavior (resetting the billing cycle and charging the way explained above) without having to abandon the Customer Portal, as that is something easy for our Customers to access.
Our issue is that we're not finding the correct way to utilize the Stripe API here get the proration behavior. With Practical Examples:
What's Happening Now (all through the customer portal):
- User Subscribes to A Yearly $800 Dollar Plan on April 12th, 2024
- User Upgrades through the Customer Portal to a $1200 Yearly Plan on Jan 31th, 2025
- For this upgrade the user was charged $136.57
What we want to happen:
- User Subscribes to A Yearly $800 Dollar Plan on April 12th, 2024
- User Upgrades through the Customer Portal to a $1200 Yearly Plan on Jan 31th, 2025
- For this upgrade the user was charged $1200 - ~$125 (Unused $ from Original Plan)
- Billing Cycle is now Jan 31th, 2025 to Jan 31th, 2026
Can you share what is the specific issue you're facing with a lot of Stripe events? Why do you want to filter them? Or to rephrase it in a different way, what are you trying to achieve here, and what are the problems you're running into while attempting to do so?
with regards to the many events you're receiving, all I can say right now is that you can define what events you want to be sent to your webhook endpoint in the Dashboard. It would be helpful to get more context so that I can provide more specific advice
Because of the way we initial set it up (and I'm pretty sure it's not the best way) - Receiving multiple events from the same subscription is triggering the process multiple times. If allowed, I can send a brief loom video here to explain the setup, that might be more useful
Hi @unreal eagle I'm also an engineer from Stripe, can you share with me the subscription ID?
We were doing this in a Test Enviroment, the subscription ID we were working with were any of these
- sub_1R1yBpFECqJV43cGreAmYsiF
- sub_1R1xl5FECqJV43cG5ATRdo9Q
- sub_1R1xjbFECqJV43cGTN4rRLI1
- sub_1R1xOvFECqJV43cGUAzJ67c9
- sub_1R1xDNFECqJV43cGNcIrWDO9
- sub_1R1wqwFECqJV43cG5DsKtiWh
We were Cancelling the Subscription and Creating a new one to check out the behavior, let me know anything else I can provide
Ok, let me take a look
Thank you both for the attention ๐
Which subscription started with A Yearly $500 Dollar Plan on April 12th, 2024?
Sorry the initial plan was $800, I was looking at another example and mixed up
Ok, so basically you want to reset the billing_cycle_anchor when updating the subscription?
Correct but that was not working for us for some reason, it was giving us giving us the result, unless I'm mixing up items. View Subscription sub_1R1wqwFECqJV43cG5DsKtiWh or sub_1R1xDNFECqJV43cGNcIrWDO9
Thanks for the confirmation, Unfortunately the billing portal configuraitons API doesn't have params to support resetting billing_cycle_anchor.
Is there anything you can recommend to us that might have a similar outcome or experience for the user?
Let me think about it, will get back to you soon
I don't have any solutions for this case. You'll want to implement your own portal for your customer to manage the subscription, so that you can programmatically set billing_cycle_anchor and update the subscription.
regarding the webhooks, what process are you triggering and based off what criteria are you triggering this process? I don't think we need a video yet
The Webhook is triggering based on these events
alright, and what process are you triggering?
so to elaborate a bit more, you would typically trigger whatever process it is, based off a change of specific criteria such as a value change in the subscription
Correct, the process itself currently and what we were trying to adapt to is
- User Requests they want the upgrade in their plan (related to LLC Formations)
- Sales Rep has a link to the customer portal within our CRM, they send it over to the customer
- Customer Upgrades Plan
- We pick up the plan and do the expected Proration behavior
4.1 Because the portal doesn't natively support the behavior we want, we're picking this up through the subscription.updated event and then trying to process the new proration behavior
I don't have any solutions for this case. You'll want to implement your own portal for your customer to manage the subscription, so that you can programmatically set billing_cycle_anchor and update the subscription. @tender wren
Do you mean using Stripe's SDK or doing a custom interface of our own in where we fetch and update subscription information directly through the API (basically no Stripe Pre-Built Components here)
Because the portal doesn't natively support the behavior we want, we're picking this up through the subscription.updated event and then trying to process the new proration behavior
From my perspective, maybe you might want to consider retrieving the subscription when you get an event, then compare the value against your database value
I do want to point out that events are also not guaranteed to be delivered in order