#sayori_best-practices
pseudo otterBOT
👋 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/1392166887651152045
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
fickle gale
another relevant page I saw earlier was https://github.com/stripe/stripe-node/issues/538
in which a subscription create request reportedly takes 4.5 seconds. this is 7 years old though, and not sure if there's any better info
alternatively if this is unknowable, but you have suggestions for reducing our sequential API call count, that's also useful. right now we are calling the stripe API 4 times in sequence:
- fetching the current subscription for the item_id
- adding an invoice item to discount the next upgrade
- updating the subscription, replacing the old item's price_id
- lastly setting cancel_at_period_end=False
umbral echo
Hello, can you tell me more about these timeouts and what you know about how they are happening? I can look at average request latency but subscription updates can entail a lot of different things from simply updating metadata so something that creates an invoice and tries to charge the customer immediately so what makes sense for the latency of one update may be very different from another.
fickle gale
Yeah, sure! I think that last comment might answer your question but the gist is that we're making a subscription upgrade and charging the user
umbral echo
From that description, it sounds like you can likely make updates 2-4 as one API call
And is the Stripe API or SDK raising a timeout error or is the timeout more that your page times out waiting on your server
fickle gale
timeout is our page, not on your end. our gql mutations had a 5 second timeout. I had it raised to 10 seconds but that raised questions on our end about why it's taking >5 seconds for upgrades sometimes
One issue is that step 3 is done with payment_behavior="pending_if_incomplete",
so step 4 can't be combined with step 3, I believe. but perhaps step 2 can?
umbral echo
And depending on how much you do #1, it may make sense to cache the item IDs for each subscription on your side so that it doesn't need to be looked up each time. The IDs will stay stable unless you add/remove them
fickle gale
Hmm, yeah good point, that's something we could do ourselves
umbral echo
And yep, the update call has an add_invoice_items parameter that you can use to add one-time invoice items while making an update https://docs.stripe.com/api/subscriptions/update?update_subscription-proration_behavior=#update_subscription-add_invoice_items
fickle gale
Great, I didn't see that before and just called stripe.InvoiceItem.create separately. thanks for directing me to that
umbral echo
Oh though I forget if it allows items with negative value. This may need to be three separate charges after all 😅
Definitely test that in test mode though to confirm either way
fickle gale
A positive integer in cents (or 0 for a free price) representing how much to charge or a negative integer representing the amount to credit to the customer.
appears to work it seems
umbral echo
Nice!
pseudo otterBOT
fickle gale
i'll try it
and I suppose update #4 could be a deferred/asynchronous task rather than have the user wait on that last update...
stark path
Hi hi! I’m going to be taking over for my colleague here. Please give me a minute to read back and understand things.
Current API calls:
- fetching the current subscription for the item_id
- adding an invoice item to discount the next upgrade
- updating the subscription, replacing the old item's price_id
- lastly setting cancel_at_period_end=False
So your goal is: Change a Subscription's Price and make sure it won't cancel at end-of-period ya?
fickle gale
hey sorry for the late response. yes, that's correct on current API calls.
the goal is correct. when changing a subscription's price, we also charge the user for the new Price amount and potentially discount based on some metric that's internal to us
pseudo otterBOT
stark path
Using Node.js, ya? What SDK version?
https://docs.stripe.com/api/subscriptions/update?lang=node#update_subscription-items-price
You should be able to do all of this in a single API call:
const subscription = await stripe.subscriptions.update(
subscriptionId,
{
items: [
//, ...items before the one to update
{
id: existingItemId,
price: newPrice,
},
//, ...items after the one to update
],
cancel_at_period_end: false,
}
);