rtarnaud-confirmpayment-elements | Stripe Developers | Page 1

cyan lintel Dec 16, 2021, 12:44 PM

#

@sonic pasture my advice is to avoid any query params beyond the 2 we mentioned. It's best to retrieve the PI and look at its status since anyone can change the query parameter during the redirect

sonic pasture Dec 16, 2021, 12:55 PM

#

Ok. Actually, I am asking this because the target page of the return_url must use the payment intent status to determine what to display to the user. As a consequence, I retrieve the payment intent status when serving the target page but this status is (concurrently) updated via webhooks and they are usually called after the request to the return_url is served which means that my target page uses an outdated status. I can work around this problem by implementing some sort of waiting mechanism but is there a best practice regarding this?

cyan lintel Dec 16, 2021, 12:56 PM

#

I am asking this because the target page of the return_url must use the payment intent status to determine what to display to the user.
yes but you use the Retrieve PaymentIntent API https://stripe.com/docs/api/payment_intents/retrieve to get that real status during the redirect

sonic pasture Dec 16, 2021, 12:57 PM

#

That's what I am using already.

#

It is a problem of asynchonicity.

cyan lintel Dec 16, 2021, 12:57 PM

#

So that is the right way to do this really. You don't need to wait for the webhook and you should not trust the parameter in the URL

#

There shouldn't be. You can do this synchronously during the redirect, completely separate from the webhook

sonic pasture Dec 16, 2021, 1:04 PM

#

I am not sure I am making myself clear. During the redirect, I retrieve the status which determines what message appears on the page: success or error, basically. At this point, the status is still "requires_payment_method". But a few seconds after, my webhook endpoing gets hit by Stripe with a payment intent event which updates the status and sets it to "succeeded" but that is too late since the user has already seen a (misleading) message saying that the payment failed (due to the "requires_payment_method" status).

cyan lintel Dec 16, 2021, 1:06 PM

#

yeah I'm sorry I don't really follow you unfortunately. It's not that you're unclear, but I need detailed information and examples. But after the redirect you should not have it as requires_payment_method, that's ~not possible

#

Are you explicitly looking at the real status on the PaymentIntent from the API or something else? Do you have a concrete example I can look at?

sonic pasture Dec 16, 2021, 1:11 PM

#

In order to retrieve the payment status for the redirect, I use this:
$paymentIntent = $this->stripeHttpClient->retrievePaymentIntent($purchase);
The latter method is wrapper for the Stripe PHP SDK and is defined as:
public function retrievePaymentIntent(Purchase $purchase, ?array $opts = null): PaymentIntent
{
$paymentIntentId = $purchase->getPaymentIntentId();
if (is_null($paymentIntentId)) {
throw new UnexpectedValueException('The payment intent id is not supposed to be null!');
}

    return $this->baseStripeClient->paymentIntents->retrieve($paymentIntentId, null, $opts);
}

with baseStripeClient being the official Stripe PHP client from the SDK.

#

Sorry, I don't know how to format code in Discord.

cyan lintel Dec 16, 2021, 1:12 PM

#

you can wrap between three ` before and after

#

but I can read it's fine

sonic pasture Dec 16, 2021, 1:13 PM

#

ok

cyan lintel Dec 16, 2021, 1:13 PM

#

I'm fairly confident what you describe is impossible though, I would need a concrete example

sonic pasture Dec 16, 2021, 1:13 PM

#

but that's what I am seeing 🙂

#

but that's alright, I will simply add a polling mechanism for a short period of time on the target page.

cyan lintel Dec 16, 2021, 1:14 PM

#

I mean you can, but I would like more details, there's absolutely no reason to have to do this, card payments resolve synchronously before the redirect

#

I work for Stripe so I'm confident in what I am describing

sonic pasture Dec 16, 2021, 1:16 PM

#

Maybe the webhooks are not triggered exactly right after the card payment resolve and the slight delay is enough to cause this issue.

cyan lintel Dec 16, 2021, 1:19 PM

#

the webhook does not matter whatsoever though

#

this is completely unrelated to the redirect, webhooks are asynchronous and used for async flows like order fulfillment or sending emails

sonic pasture Dec 16, 2021, 1:19 PM

#

Yes, you are right.

cyan lintel Dec 16, 2021, 1:19 PM

#

I literally just tried from scratch right now with a card payment and when I redirect the PI is succeeded as it should

#

if you don't see this, it's a problem somewhere that I'd like to help you dig into

sonic pasture Dec 16, 2021, 1:24 PM

#

Ok I am an idiot, I found the issue thanks to your explanations. I was using an internal version of the payment intent status which is exclusively updated via webhooks which (sort of) explains that mix up in my head. Sorry about that!

cyan lintel Dec 16, 2021, 1:25 PM

#

ah phew

sonic pasture Dec 16, 2021, 1:25 PM

#

I should have reviewed this part of the code.

cyan lintel Dec 16, 2021, 1:25 PM

#

that's what I assumed at first but when I saw your code I was worried we broke something 😅

#

Glad you figured it out. It's a common mistake as we advise to do fulfillment from the webhook but with the redirect you want a separate flow that looks at the real status

sonic pasture Dec 16, 2021, 1:26 PM

#

Yes, at least I know a bit more about the payment flow now. Thanks a lot for helping!

#rtarnaud-confirmpayment-elements