#xfechx

1 messages · Page 1 of 1 (latest)

rigid patioBOT
#

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.

rancid whale
#

👋 happy to help

azure cliff
#

hi @rancid whale thanks

rancid whale
#

Checkout Sessions don't automatically invoices unless you tell it to

azure cliff
#

I have this problem because my webhook which I have been using for years, uses two main events: charge.succeded, and invoice.payment_succeded, for generating notification emails of payments

#

I think it is good that it creates an invoice, because then on the receipt email, I can just point them to view invoice/receipt from stripe hosted receipt and invoice urls

#

are Payment Links generating invoices also?

#

or can do?

#

So my problem at the moment, is that my webhook is sending two duplicate email receipts

rancid whale
azure cliff
#

one for charge.succeded and another one for invoice.payment_succeded

rancid whale
#

so it's the same

azure cliff
#

so I am thinking about removing notification on charge.succeded and just leave it in invoice.payment_succeded

rancid whale
#

ok to handle that first, instead of listening to the charge.succeeded it's best to listen to payment_intent.succeeded

azure cliff
#

why is that?

rancid whale
#

and if the payment_intent.invoice is not null you ignore the event

azure cliff
#

thing is my webhook is extremelly big

#

does a lot of things

#

so, I would like to keep it without listening to new events

rancid whale
#

just change the event

azure cliff
#

also, many websites already have defined which events they listen to , and the only way to change it, would be to go into their dashboards, etc. etc.

rancid whale
#

instead of listening to the charge.succeeded you listen to payment_intent.succeeded

azure cliff
#

too much manual work, i don't have time at the moment

#

so, with those two options: charge.succeded and invoice.payment_sucdceded

rancid whale
#

then you would have to retrieve the PI and look at the invoice

#

from the charge.succeeded event

azure cliff
#

on the charge

rancid whale
#

yes

azure cliff
#

will it ALWAYS have it?

#

also, charges coming from checkout sessions, have metadata setup, which helps the webhook decide a few things.

Also, invoices coming from subscriptions and one-off charges have metadata setup.

Not sure if payment intent inherits any metadata? Or if the invoice coming from checkout session inherits metadata?

rancid whale
azure cliff
#

PI -> invoice

rancid whale
#

if it doesn't have PI-> Invoice then it definitely means that no invoice was created for this charge

#

Charges inherit the metadata from PaymentIntents

azure cliff
#

hmm, but for example. on my one-off invoices, the charge related to that invoice doesn't have metadata

#

so that is how my webhook discerns (maybe not the best way, but has worked so far)

rancid whale
#

the metadata topic is a wider issue, and you shouldn't rely on that

#

my advice is still to change from charge.succeeded to payment_intent.succeeded but if that means a big breaking change than the only thing to help here is as I explained retrieving the PaymentIntent and checking the invoice property whether it's null or not

#

in case it's not null you should just ignore the event

#

because it will be handled by the invoice.payment_succeded event

azure cliff
#

yes, that sounds good..

#

Payment intent, ALWAYS comes up in the event, right?

rancid whale
#

if you're using the latest APIs and not some legacy integration then yes

azure cliff
#

for example, here am I using something legacy?

#

req_3EPhMnUW9hfuHM

rancid whale
#

nop! Invoices use PIs

#

but there's a deprecated integration path where you would use Charges with Tokens instead of PaymentIntents and PaymentMethods

#

which in that case the charge.succeeded event won't have the PI in it

azure cliff
#

how can I test that, could you help me?

#

I can do a checkout session right now

#

and send test payment

#

I think it is updated, but with so many changes, and so many years, i don't really know

#

this one for example:
pi_3Ojga12lgzywWyEx0Wi6jSHa

rancid whale
azure cliff
#

if you check charge.succeded of that one. charge->invoice == null

#

I should not rely on that , right?

rancid whale
#

charge won't have invoice on it directly

#

you need to retrieve the PI first

azure cliff
#

and then check if pi->invoice != null ? or will it always have an invoice related to a pi ?

rancid whale
#

oh wait

#

sorry my bad!

#

it does actually have an invoice property

azure cliff
#

yes..

rancid whale
#

I'm terribly sorry

#

so yes you just need to check the invoice on the charge

azure cliff
#

but in this case, it says charge->invoice: null

#

however, an invoice WAS created lol

rancid whale
#

then there was no Invoice generated

azure cliff
#

so, it is confusing

rancid whale
#

is it in the case of Checkout Session with invoice_creation.enabled: true?

azure cliff
#

yes

rancid whale
#

hmmm that's interesting

azure cliff
#

i know

rancid whale
#

I really dislike listening to the charge.succeeded events for so many reason now you just added one to my list 😛

azure cliff
#

also, payment intent's invoice is null

#

i know! me too, i hate having to fix things on my listener

rancid whale
#

yes I agree

azure cliff
#

it is so convoluted

#

but i have to

#

because i come from the times where invoice was related ONLY to subscriptions

#

now invoices are everywhere

rancid whale
#

but does it send an invoice.payment_succeeded in this case?

azure cliff
#

yes

rancid whale
#

ok...

#

give me a second

azure cliff
#

if you check that payment intent i sent you, you will see

rancid whale
#

I'm thinking of a way to solve this

azure cliff
#

thanks a lot

#

I am breaking my head around it, too much

rancid whale
#

ok I know what's happening

azure cliff
#

because i really can't find the element for my code to discern between all the different type of charges

rancid whale
#

my colleague @flint marten always advices not to rely on the data object that you receive in the event but rather retrieve the object from the API

#

and one of the reasons is because some events are sent while the whole process hasn't been done yet

azure cliff
#

ok, so they are async

rancid whale
#

so basically the invoice gets created afterwards

#

and then I guess what ends up happening is that charge.invoice would be null but then it will change

#

I'm testing it out

#

give me a second

azure cliff
#

ok

#

tnx

rancid whale
#

do you happen to have an event ID?

#

that would be much easier than having to recreate everything

#

for a charge.succeeded event

#

no worries I found an example

#

where charge.succeeded event didn't have the charge.invoice

#

which updated the invoice

#

which is why when Checkout Sessions is at play we don't recommend using neither payment_intent.* or charge.* events but rather checkout.session.* events

#

before checkout.session.completed you can't be really sure that all of the objects where created correctly and are at their final state