#gecko-subs-metadata
fiery river
Hi there, metadata will be retained on the Subscription object but it does not get passed down to invoices. Were you expecting otherwise?
eager axle
Maybe. the event I'm watching in webhooks is an invoice_paid, so that I see it indeed was funded. At this event, I'll need the metadata. So I can do a retrieve on the subscription, which is a field in the invoice, and from there, go find the metadata....this is the right idea?
fiery river
Yep!
eager axle
so....ok....I look at an invoice paid event...and get a sub_xxxx id from it. I went to web browser, and searched by the sub_xxx and find the subscription. There I see the metadata is blank.
fiery river
How are you setting metadata? Can you provide the Subscription ID that you are looking at?
eager axle
sub_1L3EFGDeb8L7gMecbSmsehWP
fiery river
Ah okay that Sub is created from a Checkout Session
eager axle
in a checkout session, I create a session, with the metadata attached
fiery river
And you are setting the metadata on the Checkout Session
Instead of the Subscription
eager axle
it flows through fine, and I see it when the paid events hit the webhook
for both the single time purchase, as well as a subscription creation
fiery river
So you need to be setting the metadata here: https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-subscription_data-metadata when you create the Checkout Session
eager axle
when a subscription renews, however, like this sub_xxx I shared, it seems empty
fiery river
Yep, that is because you are setting the metadata at the Checkout Session object level and not carrying it down to the Subscription. There are two options when you create the Session. It sounds like you want o be setting it in both places based on your flow.
eager axle
so payment_intent and subscription both need to push it below?
right now it looks like this:
await stripePayment.checkout.sessions.create({
line_items: [
{
price: ${price},
quantity: 1,
},
],
metadata:
{
'cid': ${cid},
fiery river
If it is mode: subscription then you want to also set subscription_data.metadata
With mode: payment you just set it at the Session level
(What you are doing already)
eager axle
the spec you shared seems to imply that a payment_intent_data object and a subscription_data object are peers and have the same metadata member. but you're saying ignore the payment_intent_data, and leave it at top level session?
seems inconsistent.... 😦
fiery river
That all depends on what webhooks you are listening for.
If you set it top-level the metadata will be sent with the checkout.session.completed event
If you set using the payment_intent_data.metadata then it will be in your payment_intent.succeeded event for your mode: payment sessions
And if you set it at the subscription_data.metadata level then it will be in your customer.subscription.updated events or you can retrieve it via the Sub ID from invoice.paid
fiery river
You too!
fiery river
Okay let's chat here!
eager axle
ok so on a checkout session create call, I need to send payment or subscription modes
to determine which sub object to assign the metadata to, do I need to do this logic before the create, or... can I "add" it in the the .then() after the promise resolves, and put the decision there?
fiery river
You can always update subscription metadata after the Subscription is created
The only issue with that is that it won't be included on any events that fire before you update the Sub
I'm not sure which promise you are referring to above exactly.
eager axle
await stripePayment.checkout.sessions.create({
i don't think any of the events will occur yet, because the session is still being created, so the user hasn't even seen the webpage form yet
once the creation completes, then a result.redirect will cause the website to be loaded for the customer to see. so if I add a session.payment_intent_data{} obj, or a subscription, and then do the redirect, it would save and carry the metadata, and I don't have to put it in the create call. yes?
fiery river
The Subscription won't be created until that Session is completed.
And you can't update a Checkout Session
eager axle
ok, so...in summary I need to decide the call to checkout.sessions.create dynamically, to handle the metadata insertion case. right now I don't have to do anything dynamically (except for mode which I use as a ternary)
fiery river
Yeah if you want the metadata on the initial events, then it needs to be passed with the Checkout Session creation.
eager axle
ok...so then my (hopefully) last question...for the events...
right now when I get a checkout.session.completed, I follow the templates for retrieving the session and checking for payment_status==paid.
but what I think you're telling me is I could watch for payment_intent.succeeded instead (as well as the invoice.paid for subscriptions) and I wouldn't have to handle paid status events inside the checkout-succeeded event. true?
solar sable
We highly recommend listening the checkout.session.completed still
you can listen to the other events additionally but it's best to deal with the Checkout-specific events
eager axle
I'm trying to minimize redundancy in code. I don't think it makes sense to handle order fulfillment in session completion, and payment-status-paid events...do you?