#slobfntsy_45417
mossy karma
Hi i hope you good
So here is my question
We have two webhooks for platfom/connected accounts
We support creation of subscriptions on both levels via checkout session
Recently we spoted difference in the behavior how we get notifed from stripe related to the order of events that we are notified upon succesful subscription
so here is two screen shots that demonstrate the difference
So in first case "checkout.session.completed" is send to us first ( as i think this is correct from logical process perspective )
forest finch
That's expected, Stripe doesn't garentee the order of events, as mentioned herr: https://stripe.com/docs/webhooks#event-ordering
mossy karma
While on the second screenshot Yesterday notifications , were in reverse order , "checkout.session.completed" is last
forest finch
So that's something that your webhook event code will need to handle.
mossy karma
Right i agree
So here is the problem that is side effect of the show case
So as i said the we create subscription via checkout session , we don't create customers before hand for the subscribers
in the checkout session we couple metadata from our system helping us to identify the customer and some other important aspects
now what happens is that "metadata" is present in the checkout session object
that is not the case for the subscription object that only holds metadata related to the product specific
So what would be the alternative how to correlate this events
Shell we do api calls to stripe upon notification to possiblity obtain the required missing information that will help us decide how to handle the incoming event
forest finch
If you want you could add the metadata to the Subscripton object directly with this: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-subscription_data-metadata
mossy karma
helpful inside let me check how the implementation looks like
`export const createCheckoutSession = async (line_items: Array<Stripe.Checkout.SessionCreateParams.LineItem> , mode: Stripe.Checkout.SessionCreateParams.Mode , callbackUrl: string , metadata?: Stripe.MetadataParam , customer?: string , email?: string , fee?: number, accountId?: string) => {
let payment_intent_data;
let subscription_data;
if (mode === "payment") {
payment_intent_data = {
metadata,
application_fee_amount: fee ?? 0
}
} else {
subscription_data = {
application_fee_percent: fee
}
}
return await stripe.checkout.sessions.create({
mode,
line_items,
customer: customer,
customer_email: email,
metadata,
// {CHECKOUT_SESSION_ID} is a string literal; do not change it!
// the actual Session ID is returned in the query parameter when your customer
// is redirected to the success page.
payment_intent_data,
subscription_data,
success_url: `${callbackUrl}?session_id={CHECKOUT_SESSION_ID}`,
cancel_url: `${callbackUrl}`,
} , prepareRequestOpts(accountId!));
}`
so you suggest we set subscription_data.metadata and this should work ?
forest finch
Depends on what exactly you are trying to do. But if you set the Subscription on the metadata, then you will be able to see it in your webhook events about Subscription.
solar boughBOT
mossy karma
Great stuff i have the metadata in the subscription event @forest finch
Just one final question
turbid escarp
👋 taking over for my colleague. Let me know if there's any follow-up Qs I can answer!
mossy karma
what notification event we should handle to be sure that subscription object is succcesuly created
hello @turbid escarp thank you for today help!
so what we do here to be sure that sub is created or updated is we handle
case 'customer.subscription.created': case 'customer.subscription.updated':
is that vaild or we need still to evaluate the result of case 'checkout.session.completed'
mossy karma
i see but intial payment will not have invoce paid right
that happen say month afterwards
and yes we handle that one too case 'invoice.paid':
the question was more for the initial interaction
turbid escarp
i see but intial payment will not have invoce paid right
even the first payment will have an invoice.paid
even if the invoice is 0
depending on the https://stripe.com/docs/api/invoices/object#invoice_object-billing_reason billing_reason
mossy karma
turbid escarp
you would know whether this is a new subscription subscription_create
a new period subscription_cycle
or something else
mossy karma
so this is one example of subscription creation
turbid escarp
maybe you're not listening to the invoice.* events
mossy karma
ok moment i will check
great stuff you are right ! good catch we have not listen invoce_created!
final last question if i may 😄
and for invoice payment failure we handle case 'invoice.payment_failed':
i hope that is right ?
turbid escarp
you too let me know if you need any more help