#nyxi_paymentelement-updates

1 messages · Page 1 of 1 (latest)

teal salmonBOT
ancient waspBOT
#

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.

teal salmonBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always 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/1245055324088569917

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

scenic ice
#

nyxi_paymentelement-updates

fleet mirage
#

That doesn't really remove the race-condition issue though, it would just make the window smaller. In my previous integration I would select the row for update while processing the payment, but that's not possible with async payments.

When do you suggest I call this? On a timer? Before clicking the confirm button on the page?

scenic ice
fleet mirage
#

Hmm. As far as I can tell this code example suffers the same theoretical race condition after line 31, although we're in "highly unlikely" territory then. I think I have to rethink my integration a little if there are no safeguards against this particular condition on Stripe's end (from the client perspective). I would have hoped for https://docs.stripe.com/error-codes#payment-intent-amount-reconfirmation-required or a similar error when trying to confirm the payment intent on the client after the amount changed (also this error code is gated behind my account; I couldn't find it on my test account which confused me a bit - is it a beta error code?).

Also, can you point me in the direction of the documentation for the parameters stripe appends to the return_url after payment redirection? I cannot find them. I got redirect_status=pending but I'm not entirely sure what that means.

scenic ice
#

the same theoretical race condition after line 31
what is line 31?

This code has you create the PaymentIntent server-side after creating the PaymentMethod so you control the amount and you shouldn't change the amount server-side anymore in that flow.

fleet mirage
# scenic ice > the same theoretical race condition after line 31 what is line 31? This code ...

If we assume we won't change the amount, then sure, it will work all the time. What I'm saying is there is a gap after creating the intent where you can change the amount. In the code example it's very unlikely because it's immedaitely going to confirm it, but it's essentially the same problem I have: I create the intent when a payment is set up, and the amount can be changed at any time after that. That's just the nature of the payment flow. I could cancel the payment intent and create a new one if the amount changes -- that would at least remove all chances of a race condition, but I was under the impression that the payment intent was designed to be reused, including changing the amount (implied also since the amount can be updated).

Ok, I will fetch the intent and ignore the params.

scenic ice
#

I don't really get why you would change the amount of the PaymentIntent in that flow though. Like what is triggering this behaviour that the client-side code isn't aware of?

fleet mirage
#

You prepay for a table at a nightclub. The venue sets up the payment, including the amount, and ship off a link to you. At any time after this, they can choose to change the amount.

#

You could call them, say the amount is wrong after looking at the page, they could change it and then you could pay for it and get the old/wrong amount.

#

I'm not saying this is likely, just that it's possible

#

In my old synchronous flow, I'd have a "last edited" timestamp that the client would send to the server along with a payment method. If it didn't match, it would not process the payment but tell the user to reload the page.

scenic ice
#

You can use the same logic in this case right? Sorry I'm still not wrapping my head around what real issue you could be experiencing here.
But otherwise, don't update the PI anymore and cancel, that seems fine for your flow to just create a new one each time

fleet mirage
#

I cannot, because I no longer send data to the (my) server, I confirm the payment intent on the client and the server waits for a webhook where it captures and processes the payment, and the server has no way to determine what the client was looking at.

Yes, I think cancellation is the best solution.

teal salmonBOT
fleet mirage
#

I think it would be a good idea to perhaps investigate if the stripe SDKs could handle this case: When you confirm a payment intent, send some data from the SDK along with the payment to Stripe's API, and if there is a mismatch in something critical (whatever that may be; currency, amount etc.), throw an error instead of completing the payment intent.

light stream
#

Hello! I'm taking over and catching up...

fleet mirage
#

Sure all good

light stream
fleet mirage
#

I was hoping moving to automatic payment methods and webhooks would simplify the integration 😄

#

Not entirely understanding where the confirmation token would go into my flow

light stream
#

It's only designed for the two flows linked from the documentation above, it may not be suitable for your flow.

#

Basically the idea is that whatever changes the amount on the Payment Intent would also trigger the client-side update to show the new amount (and any other details that may have changed). There's always a chance someone can confirm the Payment Intent at the same instant the amount is updated; that's the nature of variable pricing during a payment flow.

fleet mirage
#

I understand, but Stripe sits in the middle and should be able to intercept this case and not process it. I don't know what data you send to Stripe when calling confirmPayment() on the client, but I don't see how it could not include the amount and currency and match it against Stripe's version of the payment intent on the server (which as I understand it gets locked during processing - at least you have that option), the same way you cannot cancel and succeed a payment intent, even if you make the API calls at the same time.

#

And yes, I also understand this is a rare case

#

Just from an implementation perspective, it should be solvable.

#

I think I will just cancel the payment intent instead of updating it; either the call to cancel will fail (and the venue will receive the original amount like the client sees on their screen) or the client will receive an error as the intent was canceled.

light stream
#

I mean, not really? confirmPayment() is client-side code that can be modified by the client. If it did an amount check it could be easily bypassed or modified by the client, so it wouldn't do any good.

fleet mirage
#

sure, if you're being intentionally malicious

light stream
#

It does sound like canceling the Payment Intent and creating a new one is your best option if you're worried about this situation.

fleet mirage
light stream
#

You are, yeah.

fleet mirage
#

Alright. Something to consider at least. Yes, you can modify the value, but you're essentially just "attacking yourself" in that case as it would just not work. People do all kinds of odd implementations that are not necessarily what Stripe recommends (or expects), based on this conversation alone. A check like this could prevent mistakes during async payments, and would never cause a legit payment to error.