#erict3331
craggy mantle
Don't think you can set Express Checkout Element to readonly mode as such.
Clicking on Express Checkout Element buttons should render a modal that should take over the screen completely, so the customer shouldn't be able to click on the button again until the modal is dismissed.
Are you not seeing that happen?
royal tartan
I am, but as far as I can tell, the confirm event fires after the modal is completed by the user. It's at that point that I need to call both createPaymentMethod and send that result to our backend, which takes the billing address and the payment method. It's during this interstitial period that I want to prevent a subsequent click.
I'm using this as an exemplar FWIW.
https://stripe.com/docs/elements/express-checkout-element/accept-a-payment?client=react#create-pm
craggy mantle
Hmm, let me check with a colleague
marble atlas
hey there, was chatting with hanzo and taking a look here
Is it possible to disable the wallet buttons?
From the rest of your message, you specifically mean some kind of disabled state?
I can look into that, but can you provide some context about how you expect to use this? From my recollect the same pattern you describe on PRB is not possible with ECE, which should always be directly triggering the relevant payment UI and making the underlying page interaction blocked.
My mistake, that create Payment Method flow is supported, just shaped a bit different: https://stripe.com/docs/elements/express-checkout-element/accept-a-payment#create-pm
royal tartan
👍 and just just to clarify I'm indeed looking for a way to disable the wallet buttons in the Express Checkout Element (ECE) when handling the confirm event.
That link is what I posted above as my exemplar.
marble atlas
Indeed it is -- ty and my bad 🤦♂️
Checking into the disabled state bit. It's not something I remember seeing, but looking
royal tartan
no worries at all, ty for your help.
ruby raftBOT
marble atlas
Ok, sorry for the delay here, was doing some testing of this.
In my testing the payment ui prevents double clicking before/during the payment UI, so nothing should be needed there. There's a use case not covered I think by after the payment UI dismisses, though.
When confirming the payment, the payments UI shouldn't disappear until the confirm call resolves, at which point you could remove it entirely if needed