#smonroe4242_webhooks

1 messages · Page 1 of 1 (latest)

jagged apexBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1265004535592648784

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

dire marlin
autumn sapphire
#

I attempted to enumerate the needed endpoints based on the documentation, and ended up with this switch case template:

  switch (event.type) {
    case 'customer.subscription.created': break; // check status === incomplete (default_incomplete?)
    case 'customer.subscription.updated': break; // cancel_at_period_end check, sub.items.data[0].(price|quantity) check, oh god way more happens, this might be heavy
    case 'customer.subscription.deleted': break; // sub ends
    case 'customer.subscription.paused': break; // check if we need this, can we implement without this feature?
    case 'customer.subscription.resumed': break; // same as above for paused ^^^
    case 'customer.subscription.trial_will_end': break; // check for payment method
    case 'entitlements.active_entitlement_summary.updated': break; // possibly use this for all sub changes? need entitlements built out.
    case 'invoice.created': break; // respond or shit fails
    case 'invoice.finalized': break; // just means its ready to collect payment, respond success to proceed
    case 'invoice.finalization_failed': break; // payment cannot be collected
    case 'invoice.payment_action_required': break;
    case 'invoice.payment_succeeded': break;
    case 'invoice.paid': break;
    case 'invoice.payment_failed': break;
    case 'invoice.updated': break; // maybe this for simple paid check?
    // charges -> paymentintents -> invoices -> subscriptions ? Which level do we listen to exclusively for coherent updates?
    default: console.error('Unhandled event"'); break;
  }```
But after going over the list it seems like I should be able to implement the system with a subset of these events. What would the recommended set of events I need to listen to in order to receive all relevant customer subscription changes? Do I really need every one of these for my subscription system to be robust?
#

As a more specific example, do I need to listen for 'invoice.payment_succeeded' as well as 'invoice.paid' to handle all cases or are these redundant events?

#

Our system is subscription based only, there will be no Checkout usage or one off payments, only recurring subscriptions.

dire marlin
#

As a more specific example, do I need to listen for 'invoice.payment_succeeded' as well as 'invoice.paid' to handle all cases or are these redundant events?
Not really. You can choose either one.

invoice.payment_succeeded is for when the payment succeeds
invoice.paid is for when payment succeeds and the invoice is marked as paid

autumn sapphire
#

Does this imply invoice.payment_succeeded could be received while the invoice is yet to be marked paid? Or would the invoice be marked as paid after receiving either event?

dire marlin
#

Does this imply invoice.payment_succeeded could be received while the invoice is yet to be marked paid?
yes

autumn sapphire
#

I also looked into the entitlements API and it seemed like most of the subscription tracking logic I need could be offloaded to tracking entitlements, and thus only need to listen for entitlements.active_entitlement_summary.updated to track user access to products, but it seemed to good to be true considering the complexity of the subscription event api.

dire marlin
autumn sapphire
#

If I only listen for that event, and ignore the customer.subscription.* and invoice.* events, will Stripe take care of the subscription system automagically while I just manage entitlements and subscription periods in my DB, or do subscriptions rely on my application listening and responding to those other webhooks?

#

E.G will Stripe fall back to correct subscription handling if I don't listen to those webhook events or does my application NEED to handle those for subscriptions to work between stripe and my application?

#

It's unclear to me from documentation what the "no code default" is for webhooks and subscription, so to speak.

dire marlin
#

Entitlements are not 1:1 replacement for all the subscription related events..

for example: it won't reflect status of the invoices per se.. So depending on what information your application would require to function, you'd need to decide between what events you listen to..

For specific usecases, yes entitlements API can replace those events and allow you to only listen to one event for everything

jagged apexBOT
autumn sapphire
#

We intend to use the Stripe Customer Portal for customers to control their billing, and have a single product we either deny or allow access to based on subscription status. So for app functionality I think entitlements will cover granting/revoking access, but my concern is whether there are cases where errors could arise in a users payment/subscription/invoice sytem that can't be detected/recovered without these additional subscription and invoice specific events being handled.

So TLDR assuming entitlements can fully handle user access to product, will stripe take care of the rest or are the subscription/invoice webhook events required for handling recurring payments and their possible failures?

kindred coyote
#

Hello, hanzo had to step out but I can help. Can you tell me more about what you mean by "the rest" in "will stripe take care of the rest"? We will attempt recurring payments based on your account settings and the specific subscription's settings. We follow the failure settings that you have set in the dashboard. If that default behavior is sufficient for you, you won't need to listen to events. But if you want to automatically provision your product based on things or do much else automated around these subscriptions then those events are the best way for your application to listen to updates?
https://dashboard.stripe.com/settings/billing/automatic

Stripe Login | Sign in to the Stripe Dashboard

Sign in to the Stripe Dashboard to manage business payments and operations in your account. Manage payments and refunds, respond to disputes and more.

autumn sapphire
#

Okay, so if I understand what you're saying, as long as I have the right settings in my dashboard around stripe behavior, I can listen to the entitlements event to update a user's subscription status in my app, and stripe will handle recurring payments and notifying customers of issues? Are there any error states that need specific webhook handlers in order to resolve or can I safely delegate payment collection and error handling to stripe and only be concerned with entitlement status via the 'entitlements.active_entitlement_summary.updated' event?

#

Trying to not reimplement what stripe already does correctly while also not leaving our customers open to errors in subscribing to us that need maual resolution on our side by missing implementation requirements.

#

E.G. will 'entitlements.active_entitlement_summary.updated' be enough to enable users who are paid up and disable ones that have missed or are not completing payments or deleted their subscription, without leaving loopholes where a customer might retain access despite not paying, or prevent a paid user from not having access. Do I need to handle invoice or subscription events to keep track of these things or is entitlements enough for this use case?

kindred coyote
#

The main states here that I am aware of are if a payment failed or if it needs some kind of confirmation to continue. Our settings provide automated ways of dealing with that. Basically Stripe will email your customer and let them know about the decline or required action. The email will then provide them a link to the invoice page where they can try a new payment method or complete 3DS.

#

I am not as familiar with entitlements, looking in to this and I will get back to you

autumn sapphire
#

The documentation covered all the events quite well but left me hanging on what the critical set of events are to not miss stuff, and whether stripe by default handles these cases or whether webhooks /must/ be implemented for these systems to work.

#

https://docs.stripe.com/billing/entitlements it seems from this that I can just listen to the entitlement event and that oughta be enough to enable/disable user access, but it seemed odd that all the invoice.* and customer.subscription.* events are there for all sorts of use cases, and entitlements just seemed to do it all in one, without clarifying that Stripe will indeed handle everything else without additional implementation on the app/code side.

kindred coyote
#

As best I can tell entitlements.active_entitlement_summary.updated should be a summary of the product features that you can provision access to. Trying to test with it a bit myself

autumn sapphire
#

It seems like tracking entitlements should give me what I need in terms of tracking a user's access based on whether they have an active subscription, without managing teh details of the subscription. What I could not find was whether the subscriptions/invoices will be automatically handled with best practice or whether my app needs to implement event listeners for invoice/subscription stuff in addition to listening for entitlements.

kindred coyote
#

Subscription status is automatic based on Invoice status and Invoice status is automatic based on the state of the payment itself

#

So I think what you are asking about is automated

#

You don't need to change any states yourself when payments happen, those are more things for your integration to refer to to see whether the customer is in good standing with you and such

#

Did that help or did I just rephrase what you already know?

autumn sapphire
#

No, thats what I've been looking for. I couldn't find confirmation that "the rest", e.g. invoices/subscription status/payments would be handled if I'm only listening for entitlement changes. Originally I was looking for the minimal subset of events that needed handling to make everything work, but I misunderstood, as it seems stripe will defacto work and events are for syncing our system, and not necessary to stripes basic functionality. So in short, I can just listen for entitlement updates, and I only need to listen and respond to other events if I want notification of their associated event, and they don't need to be handled in order for payments to be processed.