#jrserqung_api

1 messages · Page 1 of 1 (latest)

signal vigilBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1257319007782965350

📝 Have more to share? Add details, code, screenshots, videos, etc. below.

calm stormBOT
#

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.

agile urchin
#

Hi there 👋 I'm not quite sure I'm following. You're saying a payment_intent.succeeded Event is being generated when a payment fails? If so, can you share the ID of an Event where you saw that behavior?

celest lantern
#

It's really a weird one. I don't actually see the fact the the succeeded event is fired, but when the payment_intent.payment_failed is triggered comes back with 200 and right away after with 500, but if I were to remove the content of the payment_intent.succeeded the error goes away so it is definielty something with triggering the succeeded event.

#

I know its hard for you to help me with no solid evidence, just thought you might have an idea

agile urchin
#

Those are two different Event types, but neither is a payment_intent.succeeded Event it seems.

#

I also won't have much insight into how your endpoint is choosing to respond to the Events that are being forwarded to it. Offhand it seems like your Event handling code is prepared to handle one of those Event types, but not the other. When it receives the one it can't support, I suspect it's crashing leading to the 500 being returned. Are you seeing errors/exceptions in your server logs when the 500 is returned?

celest lantern
#

I know why that error happens yeah. The reason is inside my "succeeded" event I am trying to get the payment method, but obviously Stripe can't give it to me since the payment hasn't succeeded yet, but ragradless the succeeded event is event almost like unvisibly. I do lon inside it so i know for a fact it fires the event

#

but ragradless the succeeded event is fired almost like unvisibly. I do log inside it so i know for a fact it fires the event***

#

Ohh... I found the solution..

agile urchin
#

Awesome, glad to hear you got to the bottom of it!

celest lantern
#

Just for reference if anyone has similiar issue, here is what happened. This was the lineup of my hooks:
case 'payment_intent.requires_action':
case 'payment_intent.payment_failed':
case 'payment_intent.canceled':
case 'payment_intent.succeeded':

First of all the succeeded event must be the first event and also because I didn't have a default case, it did try to fire the last one which happened to be the "succeeded". Feel almost like a bug. Correct layout:
case 'payment_intent.succeeded':
case 'payment_intent.requires_action':
case 'payment_intent.payment_failed':
case 'payment_intent.canceled':
default:

agile urchin
#

Ah, gotcha. Your case statement wasn't set up for all the Event types that you were sending to your endpoint. So you had Events getting miscategorized and the wrong code running for them.