#some1ataplace-subscription-events

1 messages · Page 1 of 1 (latest)

regal juniperBOT
#

Hello! We'll be with you shortly. 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.

vale seal
#

Recommendations for what exactly? Which webhook event to listen to?

#

If so, invoice.paid makes sense here

fathom vault
#

Yes for the most part

#

Interesting because the invoice payment page says to use payment_intent.succeeded when using payment methods like paypal or cash app

#

Also curious if you have any way to not run these webhooks at the same time? My database will be updated twice - once during a checkout session and another time during invoice.paid or payment_intent.succeeded

#

And curious also if you have any feedback in my code to see if I am doing it the right way

vale seal
#

since you want to handle invoices that are related to subs (along with one time payments) too, invoice.paid gets you all the info you need in one go like what sort of subscription its attached to etc

#

Yeah you'd want to only handle the DB if invoice was previously in a different state

fathom vault
#

About asynchronous payments

Once the redirect is completed for this PaymentIntent, the payment will be completed. Your integration should rely on webhooks to receive the payment_intent.succeeded or payment_intent.failed events to determine if the payment was successful.

#

Okay how would I know if the invoice was previously in a different state?

vale seal
#

I think that page's recommendation just applies to PaymentIntents/PaymentAttempts

Zooming out a bit, you could listen to any/all webhook events that you think are necessary in order for you to fulfill the orders/handle your usecase.

invoice.paid is triggered when invoice is marked as paid after payment is processed successfully and give you access to the invoice object as payload.

So based on the information you need, you can listen for those events

fathom vault
#

okay i will use that then

#

Is there a way to determine if the invoice is one time or subscription based?

vale seal
fathom vault
#

So it will be null or None?

vale seal
#

It won't be null if its linked to a subscription

fathom vault
#

okay cool

vale seal
#

It would be null for one-time payments

fathom vault
#

Nice

#

Would I have to do this to get the invoice previous state?

if event['type'] == 'invoice.updated':
    previous_status = event['data']['previous_attributes']['status']
    print(f'Previous status of the invoice was: {previous_status}')
vale seal
#

yup

fathom vault
#

hmm but it runs separately from the invoice.paid event.

#

or would I have to use both events for the same webhook url?

vale seal
#

I'd say try a few things out 🙂
The only way to know for certain is to test it

fathom vault
#

okay, but isn't there a chance the invoice.paid event will run before invoice.updated event?

vale seal
#

It can, yes

regal juniperBOT
fathom vault
#

Yea that worries me

vale seal
#

Sorry, why though?

Let's take a step back, what concerns you about listening to invoice.* events?

fathom vault
#

That invoice.paid will run before invoice.updated and then the database will still run twice

vale seal
#

what sort of information do you store in your database?

fathom vault
#

just if the subscription is active and what membership they have and what payment type they used

vale seal
#

so what exactly would change/update in your DB when you receive invoice.* event?

fathom vault
#

Subscription.objects.filter(user_id=database_username_id).update(active = True, membership_type_id = 2, payment_type_id = 2)

The subscription table with the user, if it is active, if it is monthly or yearly membership and if it was a stripe payment or crypto payment

vale seal
#

I'm sorry, I think we've gone down a rabbit hole and just going in circles.

Taking a step back, Can you maybe share a specific example of a subscription and how the events related are handled by your server?
Also, what's the ideal end goal?

fathom vault
#

The goal is I do not want Subscription.objects.filter(user_id=database_username_id).update(active = True, membership_type_id = 2, payment_type_id = 2) to run twice (an update of my database). Once during checkout session complete webhook and invoice paid webhook.

vale seal
#

you want it to only run on subscription creation correct?

fathom vault
#

yes, but only when the invoice gets paid or the checkout succeeds since they are 2 different paths a user could take. I do have the subscription.created webhook if that is what you mean. But that will trigger when the subscription id is created in the stripe dashboard. Does not necessarily mean the user completed a successful checkout or invoice payment page.

frigid tulip
#

Gotcha, so listening to invoice.paid and checking if the billing reason is subscription_create should cover both of those paths

fathom vault
#

I see so listen to the invoice billing_reason and if that is subscription_create then run the database update?

frigid tulip
#

Yep, that would inidicate that the first invoice on the subscription has been paid

fathom vault
#

okay i will try it thanks give me a few minutes i'll let you know if it worked

#

okay cool it was indeed subscription_create

#

So now if there is an old invoice and the user pays it, it will not update the database?

frigid tulip
#

I don't think so, though if your first invoices from previous subscriptions don't get cancelled when they aren't paid for 24 hours, then I think it may be possible to get a payment from one of those

#

So I'd reccommend creating a test subscription and simulting 24 hours passing to make sure your settings are right for the first invoice to be cancelled

fathom vault
#

okay cool so should i remove the checkout webhook database update and only keep the invoice.paid one?

#

And wondering for each subscription cycle renewal recurring date, does invoice.paid get sent every time?

frigid tulip
#

I think it would make sense to go entirely off of the invoice.paid event, but the decision is entirely up to you. I would reccommend testing in test mode to make sure the event meets you needs

#

Yes invoice.paid will be triggered for subscription renewals, the billing reason will be subscription_cycle

fathom vault
#

Gotcha makes sense thank you I will try that out