#clevermoth-List PaymentIntents

1 messages ยท Page 1 of 1 (latest)

harsh badge
#

๐Ÿ‘‹ There isn't a way to specify those field values when listing PaymentIntents. You'd just paginate through all your PaymentIntents (https://stripe.com/docs/api/payment_intents/list) and then locally you can filter by the payment_method to check types and mandates. You'd want to expand that payment_method when listing (https://stripe.com/docs/api/expanding_objects).

vestal ingot
#

@harsh badge and the original problem that we are faced is we call POST /v1/payment_intents to create a PaymentIntent but we don't listen to the response but instead we listen to payment_intent.created webhook. As a result the http call is returning 400 with a message This PaymentIntent requires a mandate, but no existing mandate was found. Collect mandate acceptance from the customer and try again, providing acceptance data in the mandate_data parameter. but we never know about it as the webhook event response doesn't indicate in any way that something went wrong and return the same data as for successful Payment Intent creation

#

and now we want to find out which payments were affected by that problem

harsh badge
vestal ingot
#

yeah that's the problem in that case payment_intent.payment_failed was never sent

#

is it because it is sent only for 5xx errors but not 4xx?

#

I can provide you with example PaymentIntent in case you want to have a look

harsh badge
#

Do you have the id of one of the PaymentIntents where this happened? I can check the logs from there.

vestal ingot
#

pi_3JZw9HCwXI9yfnGa1XrmjEcS

harsh badge
#

checking, thanks

vestal ingot
#

but there is also another payment intent for which for 4xx the failed webhook was sent pi_1J2SwmCwXI9yfnGa7owxYeqt

harsh badge
#

Yah that one is a real "bank decline" which will generate the event. Different reason for the failure.

vestal ingot
#

so for 402 it is sent and for 400 not sent

harsh badge
#

The missing mandates are a different error which doesn't appear to generate the event. Looking into how best to handle those.

vestal ingot
#

but also the first one is declined from bank as the mandate was revoked. what's the difference?

#

means that without mandate the bank cannot proceed with the payment

harsh badge
#

Right, and since we know the mandate isn't existing and/or valid, we return that on PaymentIntent creation as an invalid request. You'd catch that as an error at creation time and handle it. However, it looks like handling it after the fact (like you need to do) is really painful since you can't retrieve any events and the payment_intent.created event doesn't reflect the error ๐Ÿค”

vestal ingot
#

yes that's the case

#

also have another question

harsh badge
#

Aha, so in this case since you know you're dealing with a revoked mandate, you can list events of the type mandate.updated and look at what changed (https://stripe.com/docs/api/events/list#list_events-type and https://stripe.com/docs/api/events/object#event_object-data-previous_attributes). That will get you the Customers affected and then you can check their PaymentIntents for any that are pending (https://stripe.com/docs/api/payment_intents/list#list_payment_intents-customer).

vestal ingot
#

in the http call response payment_intent.status is requires_confirmation but in the webhook status is requires_payment_method

#

should't it be the same

#

?

#

seems like the requires_confirmation indicates all the cases with missing mandate

#

but it is changed in the webhook

harsh badge
#

It's kind of a race condition. The response is immediate and then right after that, the state machine updates the field to requires_payment_method since you can't actually confirm without a mandate.

vestal ingot
#

hmmm.... so this means there is no was to know from wenhook event. I was hoping to get it by status

harsh badge
#

Yeah unfortunately it's a request error rather than an actual failed payment attempt. Best way to find them is how I detailed above with the events for the updated mandates and then retrieve the Customer's PaymentIntents and inspect them from the list response.

vestal ingot
#

ok but no way to get it real-time

harsh badge
#

Meaning when you make the request?

vestal ingot
#

so is this not expected behavious an should be fixed by stripe developers in the future?

#

meaning getting it from webhook event

harsh badge
#

It's expected behavior. You don't get the error from the webhooks, you get it from the response to the request which can be handled in real time.

vestal ingot
#

as the way we handle payment is async with queues like fire and forget and listen to webhook to update the status

harsh badge
#

Yeah, that won't handle these types of errors as the payment isn't actually attempted. The request returns an error inline and it should be handled at the time. Best you can do with webhooks is see the status is requires_payment_method and act on that.

vestal ingot
#

are there another cases when the http call can return 4xx but not failed webhook?

harsh badge
#

Most likely. I'd never rely on webhooks to handle a 400 error, you should handle those directly in the response handling.

vestal ingot
#

shit i just saw event successful ones returns the status requires_payment_method pi_3JbXQ6CwXI9yfnGa0BCULYdS

#

i mean webhook event

harsh badge
#

Correct, that means the PaymentIntent needs a PaymentMethod added. That's what will happen if, for examples, there isn't a mandate for the PaymentMethod you provided as SEPA. You'd get the 400 error on the request because the PaymentMethod was invalid, and you'd act on that by trying another PaymentMethod (which may involve asking the customer for new details, if you need to).

vestal ingot
#

no that is not 200

#

please check the last PI i provided

#

it returns 200 and status requires_payment_method

harsh badge
vestal ingot
#

pi_3JbXQ6CwXI9yfnGa0BCULYdS

harsh badge
#

That event is definitely confusing. The request and the events on the Dashboard all show processing which is correct.

vestal ingot
#

processing as a status?

harsh badge
#

Yeah, it's a bit of a delay with SEPA because we check with the bank/mandate before completing the payment. You still wouldn't want to rely on webhook events to see if a newly created PaymentIntent succeeded. You have to handle the failed request.

vestal ingot
#

ok. is this also true for other endpoints?

harsh badge
#

Any time you get anything but a successful HTTP status code, you should handle the response directly. Doesn't really matter what endpoint you're using.

vestal ingot
#

ok and only for 200 wait for webhook with more info?

harsh badge
#

Correct. Essentially, as soon as you can know there was a problem, handle it there. Either a failed request, or later/async a webhook event.

vestal ingot
#

ok ok. thanks for the explanation

harsh badge
#

Sure thing. Sorry it's a bit confusing, it can be tough to grok since it's understandable that it looks like a failed payment in the response.

vestal ingot
#

yeah. the thing now it to find all the payment that are affected by this xD

#

to set the as failed

#

i mean existing ones

#

will it o ass all payment intents by status 402?

harsh badge
#

Yeah, what I mentioned earlier is about as easy as you're going to be able to do that. You might just want to go straight to listing any PaymentIntents that are currently in status: requires_payment_method and loop through them to cancel them with https://stripe.com/docs/api/payment_intents/cancel

vestal ingot
#

but there is no way to get ones by status right?

harsh badge
#

Correct, you'd filter locally from the larger list.

vestal ingot
#

ok. are there any rate limits for the list api?

#

we have thousands on payment intents

harsh badge
vestal ingot
#

ok thanks

#

thanks for you time and support ๐Ÿ™‚