#montecarlo_api
dense zenithBOT
👋 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/1292878399781470241
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
astral eagle
Hi 👋
This is a pretty general question and we focus on helper developers with specific coding questions regarding the Stripe API. That being said, I can offer some suggestions.
First, why would you need to create a new account? That doesn't seem to have any relationship to whether or not you are using Checkout vs Stripe Elements.
cursive fern
Thankyou for your fast response! Basically we are unsure if we can just plug Checkout into our old Stripe API Version and if it would be really safe to do that.
Our backend dev who implemented Stripe on our website wrote this to me:
Upgrading the existing integration for the new API would be a huge undertaking that we should try to avoid. Especially as the integration is way more complicated than we need anyway. If we were to start over today, we would just use Checkout. So that's exactly what I'd suggest: Let's start over and use Checkout. Run it in parallel with the old integration, so that old subscribers continue to get billed on the old account - new ones come in through Checkout. Then, when Stripe wants to take down the 2016 API, we can migrate all remaining users from old to new stripe account
For context, our backend dev is also pretty packed with other stuff at the moment, so we want to avoid giving bigger tasks to them. However we also want to migrate to Checkout ASAP, because we want to introduce more subscription type and also coupons. We basically wanted to have as little backend task as possible at the moment and let frontend do most of the work.
astral eagle
Okay we help developers here so it would make more sense to be talking to your developer
But you should be able to integrate Checkout without upgrading the API
It will be more limited than on later APIs but it should still have the functionality you are looking for
Ultimately you can build out the whole integration and just hide the checkout sessions from your customers until you are ready to use that UI instead of your current one.
cursive fern
I’m a frontend developer so i will also be working on this on the front side. Our backend developer still feels risky to upgrade the API in-place when the 2016 version is deprecated one day.
Do you think the duplicate account approach will cause problems the way I described it?
astral eagle
Wait wait wait. I am NOT saying you should change your API version at all
I"m saying you should be able to use Checkout without changing your API version
However we recently launched a new test environment tool called Sandboxes and that can help you test the latest API version is a totally isolated fashion and should make any future API updates easier
cursive fern
Yes but I’m talking about if the API version one day is deprecated from your side