#nadia-webhook failed

1 messages · Page 1 of 1 (latest)

mint marsh
#

Hi, could you please provide the event id evt_xxx that you think you haven't received?

sacred light
#

we don't have the event

#

as mentioned in my message
here is the customer id : cus_JTG3Xo3IoGIgoB

#

the upgrade has been made on april 12

#

hello btw !
& thanks for taking care of my issue

mint marsh
#

I will try to investigate but please bare with me a couple of minutes

sacred light
#

no pb thank you !

mint marsh
#

when did the customer update their susbscription?

sacred light
#

the subscription has been updated on april 12

#

but i dont know when he asked the upgrade

#

i can see on the event page march 31

mint marsh
#

yes I just saw the change

sacred light
#

he asked for the upgrade on march 31

mint marsh
#

let me double check

sacred light
#

thanks !

#

i can see that this event has been sent : evt_1KnlIDFxsE4pn4oaZ8H0av9P

#

but it's not the way it worked back then

#

that why i asked if stripe made some changes regarding subscription update process

#

is my workflow still good ?

#

*i listen to the "invoice.paid" event & i check the billing reason, if it is "subscription_update" then i perform a plan update on my side (app)
i can see that i haven't received this event for the client, which explain the absence of upgrade on my app *

mint marsh
#

yes I see the issue now

#

basically you are not subscribed to that event on your production endpoint

sacred light
#

which event?

#

invoice.paid ?

mint marsh
#

customer.subscription.updated

sacred light
#

yes i know

#

because at the time it wasnt useful

#

the customer.subscription.updated was sent right after asking a sub upgrade

#

and not when the change is made on stripe

#

that's why we dont listen to customer.subscription.updated

#

is the process been updated ?

#

if it is, why didn't we receive a notification to update our workflow

#

the plan updates are made at the current period end

#

@stone heart was the one who explained me the case

#

he advised me to listen to invoice.paid event & look for subscription_update billing reason

mint marsh
#

I guess what happened is that the invoice was drafted on the same day (before) the update to the subscription was made

#

which makes sense that on next cycle you will get the normal flow

#

that you already implemented

sacred light
#

it makes no sens :/

mint marsh
#

the plan updates are made at the current period end

sacred light
#

the draft has been made on april 5

#

and the paiement on april 12

mint marsh
#

yes and the upgrade was made on the 12

sacred light
#

as the sub update

mint marsh
#

which means that the current period end is on the end of this invoice

#

so it would start next month

sacred light
#

i dont get it sorry

mint marsh
#

ok let me rephrase myself

sacred light
#

would i receive the invoice.paid event with this billing reason : subscription_update

mint marsh
#

this is still going to be the case

#

but for next billing cycle

#

since the change to the subscription was made after the invoice was created

sacred light
#

no because on stripe the update is made

#

his invoice is on the price

#

which workflow should we implement to prevent this kind of problem please

#

we are not on a testing phase
we have customers

#

we need to fix that problem quickly

mint marsh
#

please take a look at this event

#

the billing_cycle_anchor is the date when this subscription change would start taking effect

#

which is on May 12th

sacred light
#

but why the price's been updated

mint marsh
#

the only thing for me to do in this case is to notify your customers that if they upgrade after a certain date (in regards to their subscription) then the plan wouldn't take affect before next billing cycle

#

the amount that was paid is the same

#

it's 19.99

sacred light
#

yes i know
the products has the same price

#

(amount)

#

the price is "Pack Découverte"

#

not "Pack découverte"

#

you can see that the he has paid for the new price

#

there is just a discount

#

the real price is 39.90euros

#

please could you answer to the following question :
is the "invoice.paid" event billing_reasons "subscription_update" is still sent & recommended to perform an update on my app ?

mint marsh
#

I'm sorry for keeping you waiting, I'm still trying to investigate what happened to the subscription/invoice you are inquiring about

#

could you please hold a moment?

fathom ice
#

Hi! I'm taking over tarzan. Give me a few minutes to catchup.

#

Did you get an invoice without a billing_reasons? If so, can you share the invoice ID?

#

For in_1KnlIDFxsE4pn4oaPwYOFUCB the billing_reasons is subscription_cycle, which means the subscription started a new billing cycle.

sacred light
#

hello @fathom ice
Thanks !
i didnt receive the : subscription_update reason

#

no invoice.paid with subscription_update billing reason

#

as you said i only received the subscription_cycle

#

is it normal ? or it's a pb ?

#

should i change my implementation ?

#

could you please have a look at my first message

sudden laurel
#

can you share the event ID evt_xxx you received?

#

also what is "pb" ?

sacred light
#

pb = problem, sorry

#

i have no evt_xxx to give you

#

because i didnt receive the event

#

after a plan update i should receive an invoice.paid event

sudden laurel
#

ok, then what's the subscription ID sub_xxx that was updated?

sacred light
#

with the billing_reason = subscription_update

#

but i have not

sudden laurel
sacred light
#

at the current period end

sudden laurel
#

can you share the subscription ID sub_xxx that was updated and you didn't see the event you expected to see?

sacred light
#

here is the customer id : cus_JTG3Xo3IoGIgoB

#

& the subscription id :

#

sub_JTG6vIOmNCpuTN

sudden laurel
#

ok, give me a second.

sacred light
#

the sub schedule was created on march 31
the sub upgrad was made on april 12

sudden laurel
#

yep yep I see that

sacred light
#

but no invoice.paid billing_reason : subscription_update

sudden laurel
#

correct

sacred light
#

i very worried to be honest

sudden laurel
#

why?

#

there's not supposed to be such an event in this case

#

you get an invoice.paid with billing_reason:subscription_cycle in this case where you change the price at the end of the cycle

sacred light
#

we've been advice by your colleague months ago to do so

#

& we've tested it

#

many time

#

it worked

#

sttripe made some changes then?

sudden laurel
sacred light
#

because it wasn't the process back then

sudden laurel
#

can you share an example of one of those other subscriptions where you tested the same thing and got different behaviour , so I can investigate if something changed?

sacred light
#

yes on test mode

sudden laurel
#

cool. Subscription ID sub_xxx please?

sacred light
#

Bear with me a moment

#

plaease

#

i cant find it sorry

#

there are a lot of events

#

what process should i apply please
we are live

#

at the time the customer.subscription.updated
was sent right after the customer asked the change

#

is it still the case ?

#

our is it when the subscription is really updated

sudden laurel
#

sorry, I don't follow the question.

sacred light
#

how should i catch the subscription update of my customer please

#

when its effective

#

we are not on the development phase, our product is live

#

on the market
we need to hotfix that problem

sudden laurel
#

how should i catch the subscription update of my customer please
there's a few ways.

  • customer.subscription.updated will happen and the previous_attributes hash will show that the items on the subscription has changed
  • invoice.paid happens at the start of a new billing cycle and you can sync your database to the current state of the Invoice's subscription(regardless of billing_reason )
sacred light
#

thanks for your response
whats the reliable way please ?

sudden laurel
#

see my post above

sacred light
sudden laurel
#

yes

sacred light
#

i've seen it

#

to my mind invoice.paid is better because it happens at the start of a new billing cycle but it's not the case

#

it's not what happened

sudden laurel
#

it does happen.

sacred light
#

where ?

sudden laurel
sacred light
#

i have no event

#

yes but the billing reason is not subscription_update

sudden laurel
#

yes, and I explained why that is

sudden laurel
#

if you apply an update and an invoice is not created directly as a result of that specific update, and instead the update is just rolled into the next recurring invoice(which is what happened here) , then you just get the usual recurring invoice with billing_reason:subscription_cycle

fading wigeon
#

Hey @sudden laurel I'm working on the same project with Nadia!

sacred light
#

i set proration_behavior: 'none' because start_date: subscription.current_period_end,

#

will proration_behavior: 'always_invoice' work (no proration) if i keep the start_date: subscription.current_period_end

#

i mean will the customer pay the full price ?

fading wigeon
#

I remember that last year we had a lot of tests and exchanging with you guys (on the webchat that time), there was a subscription_update in the billing_reason from the invoice.paid event :/

sacred light
#

with no proration (real price)

sudden laurel
#

probably you tested something different (like using a different value of proration-behavior).

sudden laurel
fading wigeon
#

unfortunately we can not retrieve events before 01/27/2022 :/

#

stripe didn't keep that far in test mode I guess

sudden laurel
#

we only guarantee events for 30 days yes

#

almost certainly you tested this with proration_behavior:always_invoice, or with an update that causes an immediate payment, and then this production example is a different scenario. I explained above, not sure what else I can add here.

sacred light
#

so we cant show you :/

#

we will test on dev mode & get back to you

#

please keep the thread open 🙏

sudden laurel
#

I'll keep it open but I have to run now so another colleague will take over

sacred light
#

thanks a lot