#Charlie

1 messages · Page 1 of 1 (latest)

shy socketBOT
old lynx
#

Hi there

barren jay
#

Hey!

old lynx
#

I think:

If there were no crossreference I guess I would have to handle everything on invoice.paid and the distinction would be if invoice.subscription is null or not.
is goin to be the correct way to handle this but let me double check

#

The other thing you could do is add metadata yourself to the Checkout Session to carry it down to the PaymentIntent

#

Then you would need to retrieve the invoice and expand the PI

#

So likely not as effective

barren jay
#

That honestly sounds a bit more of a pain than the invoice way ^^

old lynx
#

Yep I agree

#

I'd recommend just looking at whether invoice.subscription is null

#

There isn't going to be any direct association to the Checkout Session from the invoice object

barren jay
#

Yeah alright, issue is that I use the checkout.session.completed event on the frontend (with backend calls ofc) to show the process from handling, and since I only have the session id directly from checkout I need some internal way to cross reference since handling the checkout session would not represent handling the paid invoice. So a user (and the system) would think that the session was handled, while the invoice paid might have errored if thats a followable process for you

old lynx
#

Hmm not sure what you mean

#

If you receive a checkout.session.completed then the invoice was successfully paid

#

Like that wouldn't fire without successful payment

barren jay
#

Yes, but from a handling standpoint there could be an issue on my / our backend side where the paid invoice could not have been handled. While it of course should not happen and is not the case here think of buying a pair of shoes as an example, between starting checkout and invoice.paid event the pair of shoes might have been damaged or whatsoever.
The events all go through successfully but internally the invoice.paid can not be handled since the reqiured action to fullfil it (e.g. bringing the customers shoes) is impossible to do right now.
Since I can only directly track the checkout.session.completed event I can not tell the customer if something went wrong there.

So flow chart like

user requests session -> session generated -> user redirected to checkout -> checks out -> checkout.session.completed and invoice.paid event fired -> user gets redirected to example.com/success?session_id={STRIPE_SESSION_ID} -> sites does GET requests to api.example.com/sessions/{STRIPE_SESSION_ID} to show user progress on handling all of that

but since the main business logic is now in invoice.paid I could not track this process anymore.

While writing this I just noticed that I could just utilize both event handlers, let checkout.session.completed handler handle successful one-time payments and invoice.paid just puts the invoice url into the database which can be associated to the same user over metadata.
SO thanks for being my rubberduck 😄

daring vault
#

Hi there. Taking over for bismarck as they have to step out

#

Is there anything else I can help with? (catching up reading this)

barren jay
#

No thank you, I think I rubberducked myself successfully and found a way out ^^

A not that relevant question but is there a reason there is no crossreference between sessions and invoiced?

daring vault
barren jay
#

Oh I can get the invoice from the checkout session, alright that solves a few things too.
Thank you very much, thats all for me