#smee-payment-element
1 messages · Page 1 of 1 (latest)
thanks so much
Thank you for your patience. Currently we don't have a great way to handle this. The most stable/best performing path is likely to lock your customer's ability to alter the price after the payment element has been rendered.
Yes it is
got it, thanks for confirming. I'm wondering if you could help me figure out where that original payment intent state lives (e.g. is it in the Elements component?) Trying to figure out if another path forward is to blow it away every time a new payment intent is created somehow.
There is an option you can try, though admittedly I don't fully understand it myself. You can add a key prop to the <Elements /> component, and when that key changes it'll force a complete tear-down, refreh, and re-render of the payment element. The notes I'm seeing saying this approach has poor performance characteristics though.
I see- and is that key the client secret or the amount (or something else)? the only weird thing I'm seeing is that since the <Elements/> component renders children that are in charge of creating the payment intent (and getting a new secret to pass back to <Elements/>), it re-renders them and causes an infinite rendering loop. just trying to figure out if that was the expected "poor performance characteristics", though I'd expect not.
I'm really not sure as this was identified as a "hacky" workaround, so I'm not familiar with exactly how it works. I don't think key maps to the client secret or amount, I believe it is its own thing.
Any time! Sorry I couldn't be of more assistance.
I can capture that feedback and relay it to the appropriate teams for you.
that would be wonderful!
Perfect, I'll take care of that at the end of my shift.