arya_

[upper lodge]

Hello! The answer to your overall question is really up to you, and depends on your specific business needs. When you receive an invoice.paid Event you can retrieve the subscription associated with it to determine the Price ID.

[cinder spear]

Thank you. How can the price_id be determined from the subscription? I do store the subscription in my db
Cant the payment still fail even after customer.subscription.created weebhook has been fired

[upper lodge]

The Subscription will have the Price ID in items.data.price.id: https://stripe.com/docs/api/subscriptions/object#subscription_object-items-data-price-id

It's possible for the payment to fail after the Subscription is created, yep. It depends on how you're using Subscriptions.

[cinder spear]

Inside the invoice.paid I console.log(data) which has a field called subscription which has the subscription id, but there is not field called items and there is no place where i see the price id

For context:

  const sig = req.headers["stripe-signature"];
  let event;
  try {
    event = stripe.webhooks.constructEvent(
      req.rawBody,
      sig,
      process.env.STRIPE_WEBHOOK_SECRET
    );
  } catch (err) {
    return res.sendStatus(400);
  }
  const data = event.data.object;

[upper lodge]

The subscription property on the Invoice is the Subscription's ID. You need to then fetch that Subscription using the API to get the full Subscription object.

[cinder spear]

Got it. Wouldn't it be nice if all this was an atomic operation? All actions fail or all actions succeed

[cinder spear]

Also, what's the difference between invoice.paid and invoice.payment_succeeded? How do I understand which one to use when

[leaden canopy]

Hello 👋 Rubeus had to step out but I can help. invoice.paid is typically the one we reccommend listening to. They are pretty much the same events, the one difference is that invoice.paid will also trigger if you mark a payment as "paid out of bank" (aka paid outside of Stripe) so that event is a bit more versatile

Other than that they have the same exact data and will be triggered for the same things

[cinder spear]

THank you! That's all I had right now 🙂

Wouldn't it be nice if all this was an atomic operation? All actions fail or all actions succeed

[leaden canopy]

What actions specifically are you interested in here?

The invoice being paid and the subscription becoming active are tied together. I am not 100% sure if the operation is strictly atomic but even if there was a temporary error preventing the status from changing we would correct it

[cinder spear]

When I catch the event.data.object inside invoice.paid, I get access to the subscription id as event.data.object.subscription which is then used to make an API call stripe.subscriptions.retrieve(event.data.object.subscription); to retrieve the subscription object and grab the price id. Just curious if this api call could fail as well

[leaden canopy]

The API call can fail but that would be because of something like a network connectivity issue

In that case we'd recommend making the retrieve call a few more times and maybe doing an exponential backoff to space out the retries

[cinder spear]

Got it, how can i implement this

[leaden canopy]

Which of our client libraries are you using? Node? I think our libraries have a setting for retries and can look it up for your specific one

[cinder spear]

Yes im using node.js

[leaden canopy]

We have this configuration for that https://github.com/stripe/stripe-node#network-retries

[cinder spear]

Thank you!

When cancelling a subscription, I want the user to have access till the end of the current billing cycle and then cancel. I know I have to call stripe.subscriptions.update withcancel_at_period_end: true, but I’m not sure how to update this in my database. Is there a webhook that fires when the subscription actually cancels (at the end of the period). If so, how can I know? If not, how should I handle this case in my server and db?

[leaden canopy]

Yes, customer.subscription.updated will fire when you initially update the subscription with cancel_at_period_end and customer.subscription.deleted will fire when it actually cancels

We have a very useful tool called test clocks for testing out this kind of thing https://stripe.com/docs/billing/testing/test-clocks

You can simulate time passing to that future cancel date without having to wait for it