#techsheepdog_webhooks

1 messages · Page 1 of 1 (latest)

minor wraithBOT
#

👋 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/1220747947319365764

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

obsidian steppe
#

I guess the real question here is, do I need to handle all of the invoicing events or all the events on that list, or only some of them?

#

It's confusing me the most is the invoice events because I'm under the assumption that an invoice event is for a manually created invoice and I don't want any kind of manual anything in this system as that will greatly increase cost, But so does having to support extra events that were not really using.

tulip sandBOT
vernal walrus
#

Hi 👋 no, you likely don't need to handle every possible Event type. You should figure out which ones provide you with the information your flows need to proceed, and then build a flow to support and leverage those.

obsidian steppe
#

But that's not clear

vernal walrus
#

What exactly you need to listen to isn't universal, it depends on your business needs and flows.

obsidian steppe
#

And I'm explicitly telling you that my flow is digital only.

vernal walrus
#

What downstream processes do you want to trigger, and what information do they need?

obsidian steppe
#

For simplicity, let's model it after a Netflix subscription.

#

That starts when the user starts the subscription and doesn't have a specific schedule out. of being month to month

#

Outside of being month to month

#

From my perspective, all I'm going to be doing is setting a couple flags on the user object based on the payment status to make sure they only have access when they have paid. But I want to support canceled subscriptions and I want to support having the subscription fall off because of non payment

#

The bare bones, most simple thing possible in my mind, is to simply be able to tell if they've paid for their monthly subscription or not. And if so, they're a member. And if not, they're not.

#

But there's a lot of events that don't seem related

vernal walrus
#

It sounds like you're mostly worried about the status field on the Subscription object so you know how to handle provisioning access. So it sounds like you largely want to listen to Subscription related Events. Listening for customer.subscription.created, customer.subscription.updated, customer.subscription.paused & customer.subscription.resumed (if you're supporting pausing subscriptions), and customer.subscription.deleted Events is likely a good start.

obsidian steppe
#

Are you saying I dont need to worry about the invoice events?

#

Because I'm not doing manual invoices?

vernal walrus
#

Based on what you've described, it doesn't sound like you need to listen to Invoice related events as it sounds like you're more worried about the status of the Subscription. But you know your flows best, so please let me know if it seems like I'm not grasping them.

obsidian steppe
#

Why does it sound like you're scared of giving me an answer?

One of the examples I stumbled on on a talked about a newspaper and the need to do a subscription with schedules. It would be great if this documentation had something like that for common scenarios, as I'm noticing that it's basically just written to say all the possible events and not doing any real help at all as far as minimizing the amount of work that might be needed.

#

There are some extremely common scenarios that should be explicitly called out and that's not happening, not sure why

#

So its adding ambiguity

vernal walrus
#

Because I am, I don't know your full use case, and I don't want to say definitively that you only need to listen to certain Events without knowing the full context. I want to be able to provide you with clarity on what the different Events do, so that you have the understanding and confidence to pick the right ones for the business logic you're trying to build.

obsidian steppe
#

The invoice events are not being explicit about the need to do this from a manual perspective, and so I'm not sure if these are manually triggered invoices or if these are some sort of ephemeral transient invoice object that gets created as part of the subs flow or not. And that's not called out in the documentation.

#

The use of the events are not clear, so it's not clear on what is needed or how to use them, or if I need to use them.

vernal walrus
vernal walrus
obsidian steppe
#

You're talking to a blind guy, graphics aren't visible. So what you're really saying is that your documentation doesn't support the blind development community, If you're telling me this data is only presented to me in images that the blind cant see.

#

So if I understand you correctly, I can build out a subscription platform with those five events that you listed? And it will work if the user flow matches those basic use cases?

vernal walrus
#

It's also in text in the Invoice Lifecycle section of that doc

obsidian steppe
#

The problem is the documentation isn't very accessible to the blind.

#

There are so many iframes in everything that a lot of that text just isn't visible.

#

That's why I find myself having to come here and ask questions

vernal walrus
#

Let's break out one part of your flow, specifically revoking access to your service. What are the criteria, from a business perspective, that you want to trigger that? Do you want to revoke access as soon as one Invoice payment attempt fails, or do you plan on using our automatic retry funcitonality to let there be multiple payment attempts for an Invoice and only revoke access when all of those fail?

obsidian steppe
#

No idea because I didnt see a event that said it was a retry event.

#

There didn't seem to be any distinction between a failure or a failed retry

vernal walrus
#

Ignore the Events, what business logic do you want to trigger revoking access to your service?

obsidian steppe
#

So we hadn't even considered a retry

#

It would be nice to allow people some leeway and let them update their card or whatever if it expired.

#

But in general if the account isn't paid for, then we would like to turn it off

vernal walrus
#

When do you consider the account to not be paid for?

obsidian steppe
#

If they didn't pay for the initial subscription creation, then they shouldn't have a subscription. And if they started a subscription that they had successfully paid for before, that is now failing billing, then they don't have a subscription any more

#

One scenario I'm really worried about is Phantom subscriptions where people fail a billing cycle and fail a subscription and then have to create a separate subscription.

#

So the system now has two subscriptions of the same type

vernal walrus
#

that is now failing billing
Are they failing billing after a single failed payment, after all payment retries fail, something else?

obsidian steppe
#

Like I said before, I wasn't even aware that retry was possible. From my perspective, In the best case, the subscription would automatically bill to continue the current subscription. If that payment failed, then I would consider the subscription to be ended

vernal walrus
#

I'm trying to do two things here. 1) get more clarity so I can try to provide better guidance and 2) drive home my point that you know the business logic you're trying to build best. I'm not here to tell you how your business logic should be structured, but rather help with mapping that logic to the functionality Stripe offers so you can build that logic.

obsidian steppe
#

I get it. I'm just confused by the sheer amount of work that needs to be done. And the documentation not being fully accessible to the visually disabled makes it harder.

#

So I'm trying to figure out how to minimize the work that needs to be done

#

Every web hook event I don't need to worry about is less work that needs to be done, so I'm trying to just figure out which events I should care about and which ones I shouldn't have to worry about; I don't plan on supporting pausing or resuming subscriptions, so does that mean I can ignore those two events?

#

From my perspective, they either have a paid subscription or they don't.

vernal walrus
#

The events I described sound like a good start then. I'd recommend building your test flow with those, then test to see if they cover all of your scenarios.

obsidian steppe
#

You gave me five events to worry about. So in my mind, if I can remove two of them, that means I only need to focus on 3. Would it be correct to assume that the updated event is going to be the one primarily responsible for if I should continue the membership or not?

vernal walrus
#

You're welcome to ignore any events that don't benefit your flow.

#

Updated for continuing yes, created will also be relevant for initial provisioning.

obsidian steppe
#

thank you

#

so if the payment fails is that what triggers deleted?

#

for deprovisioning?

vernal walrus
#

Depends on your settings

#

I'm not sure if that's something you've incorporated or not though.

obsidian steppe
#

So hypothetically speaking, if the payment flow was very simple, I could check the subscription status and then cancel the subscription explicitly If the current payment status was updated to be unpaid?

vernal walrus
#

Yup, if your flow is set up to move the Subscriptions to an unpaid state.

obsidian steppe
#

Would noit the subscription flow automatically update the subscription to an unpaid state, if the billing date passed and it was not paid?

vernal walrus
#

Not if the setting in your dashboard that I pointed you to is set to cancel the Subscription or leave the Subscription past-due.

tulip sandBOT
obsidian steppe
#

So if the setting is to cancel the subscription, then I will get a deleted event automatically?

#

I would never choose to leave the subscription past due in this scenario.

vernal walrus
#

What may be eaiser for you, is to run through your test flow for creating, updating, maintaining, and ending Subscriptions. Then you can see exactly what Events are triggered and when during your testing, which may make it easier to see which ones you should expect and rely on.

obsidian steppe
#

Yeah, I'm just trying to scope the work right now. And when I saw the page of dozens and dozens of events, I freaked out and just had to ask

#

I didn't want to spin my wheels on a bunch of events that I don't really need.

#

But if I can get by on three events with the right configuration, that's much easier.

#

I'm just surprised that it's not called out cause stripe makes it seem a lot more difficult and complicated than that. It kind of feels like stripe has become the big, complicated mess that it was competing against. I still remember many of the flows from before stripe existed and they seem easier, Even if we did need to worry about running a crone job every day to deal with subscriptions. This event model basically makes me think you guys are just running the crone job And sending events to a queue to be distributed based on the customer. Or at least that's how I would do it. So my big issue is just understanding the events and what is needed from a minimal perspective.