#neha_webhooks

1 messages · Page 1 of 1 (latest)

shut brookBOT
#

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

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

dim tuskBOT
#

Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

pastel oriole
#

@sturdy holly

dim tuskBOT
pastel oriole
#

is the difference that created is just done once, at the "start" (maybe after "updated" though)

tulip widget
#

👋 the created event means this is a brand-new Subscription, while the updated event means that something about the existing subscription has changed

pastel oriole
#

and update is done on a recurring basis for subscriptions?

#

but when the user FIRST signs up

#

both will be called

#

correct?

#

so i should use "create" for like, one-time set up

#

and "update" for the meat of the stuff related to keeping the subscription running (or not, if it's past due)

tulip widget
#

Right, you may see both when the user first signs up if, for example, the subscription's status changes, the billing period changes, etc.

pastel oriole
#

may or definitely will?

tulip widget
pastel oriole
#

before it didn't matter if i repeated work in the create and update handlers

#

but now i have a credit system

#

so i don' want to allocate the user 2x the credits

#

should i only allocate in "update" rather than "create" ?

tulip widget
#

You will need to see what update was made by inspecting the previous_attributes hash on the updated event, then determine whether that kind of update warrants a credit allocation

pastel oriole
#

can you link me to that object declaration

#

and in general are you agreeing that, if my goal is to give the users 100 credits a month, for example, this should happen (encapsulated by certain conditons) in the "update" not the "create"

#

or are you saying it should happen in both

tulip widget
#

You likely want to allocate credits on a subset of update events

#

But that will really be up to you

pastel oriole
#

what, in the previous attributes field, would indicate that i don't want to allocate?

#

i basically only want to allocate when payment has been remitted and the subscription has officially begun its active period

tulip widget
#

Any change to a subscription would trigger a customer.subscription.updated event. So, for example, if you change the description, add metadata, or make any other change that doesn't impact billing/payment, you won't want to allocate credits then

pastel oriole
#

so how do i know it's a renewal per se

#

like the clock ran out on, the invoice was finalized, they paid, it's time to top up

#

'interval_count"?

tulip widget
#

You could listen for invoice.paid instead and inspect the payload for its subscription. For example, your event handler logic can then pull up details about that specific subscription (if you maintain some internal database that maps subs to customers, plan details, etc.) then allocate credits accordingly

pastel oriole
#

ok i'll give that a try

#

thanks

tulip widget
#

Sure thing!

pastel oriole
#

sorry one more

#

so for the invoice paid and invoice payment failed webhooks

#

do i still have to check the latest status of the subscription? bc the webhooks can be called out of order?

tulip widget
#

You can check the subscription if you want but, assuming you have a subscription that bills monthly, you won't get invoice.paid and invoice.payment_failed for the same subscription on the same day as part of a normal renewal

pastel oriole
#

and how do i put my client_reference_id as metadata in the invoice object? is that possibel?

tulip widget
#

If you do make a subsequent call, you can retrieve the Invoice that's mentioned in the event and expand the subscription This will return the invoice and subscription objects in one call: https://docs.stripe.com/expand

pastel oriole
#

ok so if i double-check the status
then i can get the subscription=>metadata as part of that

#

but in general it's probably ok to not double check the sub status for invoice.paid and invoice.failed

tulip widget
#

Right, yep

pastel oriole
#

will the payment_failed be called on every retry?

tulip widget
#

Also note that metadata on a subscription and metadata on an invoice are different things

tulip widget
pastel oriole
#

ok so i can look at attempt_count or attempted i guess

tulip widget
#

Yep, you can look at that too

pastel oriole
#

what's the difference between invoice.paid and invoice.payment_succeeded

tulip widget
#

invoice.paid is the one you should listen for as it will be emitted anytime an invoice is transitioned into the paid status, including when you manually mark an invoice as paid

#

invoice.payment_succeeded is not sent if you manually mark an invoice as paid

pastel oriole
#

so for payment_succeeded

i should fetch the full object associated with the subscription in the invoice object?

#

in order to get the line items

#

(let me look, don't close the thread please!)

tulip widget
#

I don't quite follow. If you listen for invoice.paid, you can make a subsequent request to retrieve the Invoice, and expand the subscription if you want to inspect the Subscription object in a single call

pastel oriole
#

ok got it

#

but the invoice object has a "subscription" key

#

so can't i just get the subscription w/ that?

# 
    "subscription_details": {
      "metadata": {
      }
    },
tulip widget
#

Can you be more specific? I don't follow. The invoice.paid event will be an Invoice object, so you'll see subscription: sub_123 in the payload but nothing else about the Subscription. If you want more information about the Subscription at that point, you can either make a call to retrieve the Subscription directly or make a call to retrieve the Invoice and expand subscription

pastel oriole
#

ok got it

#

ok so here's what i did

checkout.session.completed: used for one-off purchases (topping up credits)
customer.subscription.created: used for one-time set up (storing stripe customer ID in my User table)
customer.subscription.updated: used to perform side-effects related to downgrading
customer.subscription.deleted: used to cancel
invoice.paid: used to create/update subscription and provision credits
invoice.payment_failed: used to perform side-effects related to failed payment

tulip widget
#

This looks like a good plan but I still recommend mocking this out and testing it with test clocks