#gecko-subs-metadata

1 messages · Page 1 of 1 (latest)

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
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

eager axle
#

ok this makes sense, thanks much!

#

have a great day!

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?