#farfa7886

1 messages · Page 1 of 1 (latest)

tropic zincBOT
novel olive
#

Hi there 👋 so that code looks like it will set metadata on both the Checkout Session object and the created Subscription object. Are either of those the object you're listening for with your webhook endpoint? Metadata is not automatically copied from one object to another, so if you're listening to Invoice, Payment Intent, or Charge events then extra steps are needed to fetch the metadata you're looking for.

limpid fiber
#

I just wanna say sorry in advise for understanding 😓

novel olive
#

All good, no need to apologize. Do you know what type of Events you set your webhook endpoint to listen for?

limpid fiber
#

Ups! just realised I sent the block of code twice thinking it was the webhook, i'll update it rq

#

midified

novel olive
#

Gotcha, so that is expected then. payment_intent.succeeded Events will contain a Payment Intent object, but that isn't where you're setting the metadata so you won't see it on that Payment Intent object.

You have two options here. One is to listen to a different type of Event that will contain the object where you're setting metadata. The part of the type before the . indicates the type of object that will be included in the Event. So you could listen for customer.subscription.created or checkout.session.completed Events.

limpid fiber
#

ooh

#

hat's the difference between them

novel olive
#

The other is to change your event handling code, so that it uses the Payment Intent's ID to retrieve either the Subscription or Checkout Session object so you can inpsect the metadata on those.

limpid fiber
#

but customer.subscription.created will trigger even if the user did not pay?

#

or payment went wrong?

tropic zincBOT
novel olive
#

That is a possibility, that Event is triggered whenever a Subscription is created. It doesn't guarantee that the Subscription is in an active state.

limpid fiber
#

so I have to listen to checkout.session.completed

#

to get metadata and confirmation of payment success

#

right?

#

or it will trigger on cancel?

novel olive
#

That is generated when a Checkout Session is completed, and should allow you to inspect the metadata on the Checkout Session object. I would recommend testing with asynchronous payment methods if you're planning to support those though. I believe with those the customer can complete the checkout experience, but then still encounter a failed payment later.

novel olive
limpid fiber
#

ok

#

i will see, thanks a lot!

novel olive
#

Any time!

limpid fiber
# novel olive Any time!

sorry if this may seem sully but if i replace payment_intent.succeeded with payment_intent.completed, the ".completed" event wont trigger

novel olive
limpid fiber
novel olive
#

Most objects and Event types support metadata. The key is that you need to listen for the same objects where you're putting the metadata, or adjust your flow to retrieve the objects that contain the metadata you're setting. Which one of those approaches are you planning to pursue?

limpid fiber
#

i'm not sure but i think

novel olive
#

In that case, you wouldn't change the type of Events you're listening for, you can continue to listen for payment_intent.completed Events.

You can use the ID of the Payment Intent included in those Events to make a request to retrieve the associated Checkout Session. To do so you use this endpoint/function to make a request to list Checkout Sessions, and provide the ID of the payment intent to the payment_intent parameter, which will cause the request to only list Checkout Sessions associated with the payment intent you specify:
https://stripe.com/docs/api/checkout/sessions/list

Then you can read the metadata off of the Checkout Session object.

limpid fiber
#

i will try

limpid fiber
novel olive
#

No, it starts with pi_. The Event ID starts with evt_.

limpid fiber
#

ok

#

oo

#

maybe i got it

#

got it!

#

thanks a lot @novel olive!