#mattwoberts

1 messages · Page 1 of 1 (latest)

inland brookBOT
fickle canopy
#

Hiya

pale umbra
#

Hi! Let me help you with this.

fickle canopy
#

Sure - here is the customer. cus_NlV2VJX5TQBKI9

#

So we've got code that listens for the invoice.payment_succeeded event, but in this case, that webhook event never fired 😦

pale umbra
#

Is the event notification not being sent to you, or the event is not happening at all?

fickle canopy
#

The event doesn't happen at all - which is definately not what I expected

#

We know it does usually fire - I"m wondering if something has changed

#

The customer is paying with a BACS Direct Debit, so it's a delayed payment, so that might be related, but I'd still expect the invoice.payment_succeeded event to fire, but it's not

#

(What I mean is we have hundreds of customers, many paying with DD, and this is the first time I've seen this issue where there is no event created)

pale umbra
#

Could you please share the Invoice ID?

fickle canopy
#

Hang on

#

in_0NAqL8EHSdXPilfD2djnl3p8

#

I can see that the invoice was updated, and paid set to true. But I would still expect invoice.payment_succeeded to happen.

pale umbra
#

Sorry, I need another moment to take a closer look.

#

Do you have an example event invoice that had the event?

fickle canopy
#

I do....

#

cus_ADJylHy1lr4y8Q is one example - they're paying with DD. If you look you can see that the event happened the last time they were invoiced.. .evt_0N73PlEHSdXPilfDg5LdpYyP

#

evt_0N73PlEHSdXPilfDg5LdpYyP

#

in_0N5qvaEHSdXPilfDdCspnVea

pale umbra
#

I see, this might be a bug actually.

fickle canopy
#

😬

#

I'm slightly worried if there are other customers for who this hasn't happened and and so our intergration won't be working as expected

tough dew
#

Hey! Taking over for my colleague. In fact I can see only the event invoice.updated evt_0NC7tyEHSdXPilfDy2N1bUZg

#

which reflect the update of the status paid to true

#

let me check a bit more if I can find something please..

fickle canopy
#

Yes it does but the docs state that we should get a invoice.payment_succeeded, and our integration uses that one in order to transition the customer on our side.

tough dew
#

invoice.paid or payment_intent.succeededyou mean ?

fickle canopy
#

invoice.payment_succeeded

tough dew
#

no there is no such event

tough dew
fickle canopy
#

E.g. evt_0N73PlEHSdXPilfDg5LdpYyP

tough dew
#

What guide are you following exactly ?

tough dew
fickle canopy
#

I'm not following a guide, this is an existing intergration we've had for months. We have hundreds of customers using it.

#

That event fires all the time successfully

#

But not this time.

#

Yes that event fires for BACS payments - I just gave you an example of it...

#

I'm now very confused

tough dew
tough dew
fickle canopy
#

I can find one I think... just give me a min....

tough dew
#

Yes of course, take your time

inland brookBOT
fickle canopy
#

evt_0N6gkvEHSdXPilfDJ53qoqZ8

#

That's an event for one... I'm basically looking through our customer list for all BACS customers, the ones I see, I look at the events, and sure enough there is always an event for invoice.payment_succeeded

tough dew
#

Ah I see, this when a recurring payment went successfully without passing throw processing state.

#

That's the difference I see between the two invoices in_0NAqL8EHSdXPilfD2djnl3p8 and in_0N4R5nEHSdXPilfDAIK7Gzbn

#

But for all invoices, I see you are getting payment_intent.succeeded event right ?

fickle canopy
#

I think so - just let me check one or two....

#

Yes that does seem to be the case

#

I accept though what you're saying - about the docs saying we should listen for different events.. .This integration was initially credit card only, and has been extended to handle BACS too, so I wonder if there are additional things / checks that we should look at adding.....

#

So what your'e saying is that the first invoice - because there were additional checks / state changes on stripes side, that meant that the invoice.payment_successful didnt't fire - because it was unable to complete immediately (i.e. there were some delayed things that need to happen) - so in that scenario then you don't get the invoice.payment_succeeded, and so for BACS we shoudn't rely on it. Is that about right?

tough dew
# fickle canopy So what your'e saying is that the first invoice - because there were additional ...

Well, I'm sure that for all cases you'll receive payment_intent.succeeded, but honestly I'm not sure for invoice.payment_successful... and

because there were additional checks / state changes on stripes side, that meant that the invoice.payment_successful didnt't fire
that's what I'm seeing so far... maybe I'm looping something else. However according to the doc it says clearly to rely on the event payment_intent.succeeded

#

And that looks accurate, according to the different invoice types I'm seeing in your account.

#

That event is relyable too for card payments.

fickle canopy
#

Ah that's interesting, so it should be simple to switch to that one

tough dew
#

I would say that yes.

fickle canopy
#

Right, OK, I'll make sure that happens, I'm sure we'll have missed some other customers with this too. Thanks for your help on this

tough dew
#

Happy to help, and please don't hesitate to come back if you you have any other follow up question.