#shadizx-event-order

1 messages ยท Page 1 of 1 (latest)

tawny emberBOT
keen ridge
#

Hi ๐Ÿ‘‹ you should avoid assuming you will receive Events in a specific order. Since they take time to reach your system, there is always the possibility that they will get out of order during transit.

Instead your flow should be able handle Events being received in any order.

Depending on what you're getting from each Event type, you may not need to listen to both. If you do though, you will likely want to explore allowing the code you run for either Event to create the necessary record in your DB if it detects that it doesn't already exist. Or you could look into building a queuing system that holds an Event and waits to process it until the Events you were expecting to receive before it have been received and proceseed.

devout dock
#

hm yeah good point

keen ridge
#

shadizx-event-order

devout dock
#

I guess the reason that I depend on the checkout.session.completed is because I can grab the metadata from that event, but I don't think I can grab the metadata from the invoice.payment_succeeded event since I couldn't find any way to pass metadata for it to be recievable from the invoice object when that event gets sent

#

and I need the metadata because the userId is stored there

keen ridge
#

Gotcha, are you using Checkout Sessions to handle one-time payments, and are using the feature that causes those to generate Invoices? Or are you working with Subscriptions that are creating the Invoices?

devout dock
#

using subscriptions

keen ridge
#

Ah, gotcha. The only thing that comes to mind which may make this a bit easier, is to store the metadata on the Subscription object rather than the Checkout Session object:
https://stripe.com/docs/api/checkout/sessions/create#create_checkout_session-subscription_data-metadata
Then when you receive the Invoice Event you can make a request to retrieve the Subscription object associated with it, and pull the metadata from that Subscription.

devout dock
#

Thanks alot, I will try that now.

#

Also just wondering, what is the usual workflow for people in my situation?

#

I feel like I'm doing it very wrong lol

keen ridge
#

That's a bit tricky to answer as it depends on what you're trying to trigger by an Event, and exactly what information you need to quickly access. Those are the key criteria that change which Event types you should be listening for, and where in the object structure you will want to look for the information you need.

devout dock
#

yeah good point

#

hm okay pretty interesting I just tried this, and it worked first of all so thanks alot!

but what I found was that there was enriched metadata in subscription.lines.data[0].metadata, and also in subscription_details.metadata,

are both of these caused by just adding the subscription_data.metadata when I created the session?

keen ridge
#

Hm, can you share the ID of the object you're looking at so I can take a closer look at what you're seeing?

devout dock
#

in_1NfNKSABhPXCq9Vu0FdT2CKT

#

also it may be since I am passing the metadata and the subscription_data.metadata when I create the checkout session

#
  const session = await stripe.checkout.sessions.create({
    line_items: [
      {
        price,
        quantity: 1,
      },
    ],
    mode: "subscription",
    success_url,
    cancel_url: pricingUrl,
    metadata: {
      userId,
    },
    subscription_data: {
      metadata: {
        userId,
      },
    },
  });
#

oh my bad I was looking at the invoice

#

the invoice had both

keen ridge
#

Ah, that's right, subscription_details.metadata is a newer field on the Invoice object that I was trying to remember. With that you should be able to get Subscription level metadata directly from the Invoice without needing to make another request.

devout dock
#

awesome! Thanks you for your time and help, it means alot.

keen ridge
#

Any time, we're always happy to help!

devout dock
#

Just a quick verification that this subscription_details.metadata will always be provided for the invoice right? What I understand is that the metadata is tied down to the subscription, so for as long as the subscription is active the metadata will be provided in the subscription, and so the invoice object just references the metadata provided in the subscription.

tawny emberBOT
keen ridge
#

I don't think it's a continuous sync between the two objects. I believe subscription_details.metadata is a snapshot of the metadata on the Subscription when the Invoice was created.