#john_subscription-duplicate

1 messages ¡ Page 1 of 1 (latest)

serene elbowBOT
#

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

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

wooden verge
#

Do you need multiple subscription objects?

wheat crown
#

a customer can only have one active subscription in our app, so from our end we dont need it - i guess the question is, should we be doing so to match stripe data?

wooden verge
#

So why do you create multiple subscription objects?

#

Your code controls when subscriptions are created

#

Can you share the subscription id's so I can see how they're being created?

wheat crown
#

we arent explicitly creating subscriptions at all - we create sessions, but is there a way to link sessions to a single subscription?

customer: cus_QtzdnlJirdEvgS
subscriptions: sub_1Q5RcaRpzuCOqCEby5FRK6hC, sub_1Q5RSgRpzuCOqCEbuW8yxcXj, sub_1Q5RJhRpzuCOqCEbOgS06R3J

wooden verge
#

Wait so why did this customer checkout 3 times?

wheat crown
#

my understanding is that payment failed the first two times, im unclear on why

wooden verge
#

If you click the other 2 invoices from the cancelled subscriptions in the dashboard, you can see that the payemnts required action/3ds which the customer never completed

#

So we eventually expired the checkout session, which cancelled the payments

#

But really if you listen for invoice.paid, that will contain the subscription id of the one that succeeded

wheat crown
#

yeah i see how we got to this state - the problem is, we listen to customer.subscription.updated and customer.subscription.deleted too, so we're getting webhook events from the other two that override the active status of the successful one

#

we just arent filtering on subscription id on our end

#

i see a few ways to fix it, i was just curious what is recommended

#

we can either:

  • track one subscription on our end per stripe subscription
    • update them all distinctly via webhook events
    • use the highest status as the org's subscription status

or:

  • keep tracking a single subscription on our end
    • allow webhook events from new subscriptions to upgrade the current one, to allow upgrading to TRIALING, or to ACTIVE, and then track that subscription ID
    • once tracking the ID, allow only the current subscription webhook events to downgrade the active subscription
#

or ideally, would there be a way to avoid creating multiple on the stripe side?

wooden verge
#

You should explicitly track subscription id

wheat crown
#

right i know, but from there, there are two ways to handle this

#

because if we simply tracked the first ID we received and then disallowed any other subscriptions to update the status on our end, we would have ignored the active subscription once it was paid

#

so we need a way to manage statuses from multiple subscriptions on our end - either by tracking them each explicitly in our DB and then figuring out which to use for provisioning, or by using some logic to determine if and when to modify a single subscription's status on our end as a result of a webhook event that may have come from one of many subscriptions

wooden verge
wheat crown
#

would that be affected by session expiration?

#

e.g. if i repeatedly try to create an idempotent session but the existing one is expired or no longer active/valid, would a new creation reopen it?

#

also, is there any time limit to the idempotency? My understanding from those docs is that this is really designed more to handle quick request retries, not potentially lingering customer behavior

wooden verge
#

Yeah so if the session was paid or expired before idempotency key eviction, then customer wouldn't be able to checkout again

wooden verge
serene elbowBOT
wicked hearth
#

john_subscription-duplicate

wheat crown
#

so that would help but not entirely prevent multi-subscriptions, right? i'd still need to choose one of these two options

wicked hearth
#

@wheat crown yes

wheat crown
#

does stripe recommend a best practice regarding one or the other?

wicked hearth
#

not really, that's up to you

wheat crown
#

okay cool

#

i think that's all i needed to know, thank you!