#deputycheese

1 messages · Page 1 of 1 (latest)

split geyserBOT
wintry trellis
#

Yep, this is expected. An initial payment attempt is made once the invoice is finalised. If the bank requests auth/3DS for that payment, an invoice.payment_failed event will fire

fluid jackal
#

Okay I see. Right now we are using the payment.failed event when the subscription has ended and should be renewed but the payment fails (for example if the customer cc was stolen etc).

#

Is there a way to differentiate between those 2 use cases?

#

Because if it happens during his session on our website we dont want to cancel his subscription (this breaks our checkout atm)

#

But if his subscription has ended and the renewal fails, then we want to cancel his subscription

#

(so he can just go back to our website to renew/create a new subscription)

#

Should we therefore ignore invoice.payment_failed but use invoice.finalization_failed ?

wintry trellis
fluid jackal
#

Is there a way we can tell if the user is off session?

#

If off session -> cancel

#

If on session -> do nothing and wait for the finalization event

wintry trellis
#

off_session field on the same Payment Intent

#

I would think, may need to check it

fluid jackal
#

I cant find any of those properties in the logs of the event

#

That's the json I am getting during the payment failed event

wintry trellis
#

Yeah you'll need to make an API request to expand the payment_intent field on the Invoice

fluid jackal
split geyserBOT
silver patio
#

there is no marker

fluid jackal
#

Okay. So how can I differentiate between those 2 requests?

#

I want to do this:

#

If off session -> cancel
If on session -> do nothing and wait for the finalization event

silver patio
#

maybe check the billing_reason on the Invoice

fluid jackal
#

"billing_reason":"subscription_update"

silver patio
#

not really the same thing but I usually see this question from the context of treating the first Invoice payment (which happens on session) differently from recurring(which happens off-session)

fluid jackal
silver patio
#

cool, then that can help

#

billing_reason is subscription_create on the first Invoice of a Subscription

fluid jackal
#

That's strange because for me it's subscription_update on the first one

silver patio
#

are you using an really old API version?

fluid jackal
#

No it should be the new one, I'm checking to be sure

#

2020-08-27

silver patio
#

invoice ID in_xxxx?

fluid jackal
#

in_1NkOD1ClDK2O5WMjxSJAhIqo

#

Ah wait

#

It says subscription_create

#

Let me try again, strangely for the one in the LIVE environment it said subscription_update in my logs, even though it was the first one. I will try again.

silver patio
#

it depends where you look

#

your account has a default API version from 2016, so when you look at raw events in the dashboard they're rendered using that

#

also your livemode webhook endpoint does not have a specific API version set,(your test mode version does though), so it recieves everything rendered in the 2016 version

fluid jackal
#

I thought I define that via the API/request itself ('stripe_version' => '2020-08-27')

silver patio
#

that's the version your request uses yes

#

that doesn't influence what webhooks do, the webhook is sent either using your account's default version, or the API version set on the webhook endpoint (there's options in the Dashboard and API when creating the endpoint to pick "latest version or account default")

fluid jackal
#

Oh okay where can I change those to the api that I'm using?

silver patio
#

you can't change it on an existing endpoint, it can only be set when creating an endpoint

#

if you look at the UI in the Dashboard->Developer->Webhooks section for creating a new endpoint you should see the options

fluid jackal
#

So I need to create a new one and delete the previous one?

#

And is there a way to see all open endpoint requests? If a request fails, it will be send again if Im not wrong. Is there an option I can see all failed ones that have not yet been requested again?

silver patio