#christian_unexpected
lone loomBOT
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.
- christian_ece-link, 1 day ago, 8 messages
- christian_unexpected, 3 days ago, 8 messages
finite hollyBOT
đ Welcome to your new thread!
â˛ď¸ We'll be here soon! We typically respond in a few minutes, but in some cases we might need a bit more time (e.g., server's busy, you've got a complex question, etc.).
âąď¸ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can 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/1261433090572681237
đ Have more to share? Add details, code, screenshots, videos, etc. below.
thorny gate
Picking up from our last chat: https://discord.com/channels/841573134531821608/1260289159352942674
What errors do you see in the console when you refresh the page?
lofty temple
hmm not seeing any console errors relevant to link. Just seeing warnings about "This element will be mounted to a DOM element that contains child nodes", an error that an icon from pay.google.com failed to download
thorny gate
Ah, I just realizzed this question is slightly different from the last one. Apologies. Let me dig a minute and circle back
lofty temple
no worries. its in the same vein though, the "ready" event seems to be firing unexpectedly
thorny gate
So, on('ready') only fires when the element is rendered. Not necessarily when Link is displayed.
Triggered when the Element is fully rendered and methods on the instance, like element.focus() and element.update(), can be called.
lofty temple
I see okay. so the element can be rendered but not have any buttons displayed in it basically
thorny gate
I believe so. Let me spin up my test integration and check. I'm pretty sure Stripe renders the Element as as skeleton first and foremost, then makes calls to external resources for things like Link, Google Pay, Apple Pay, etc
lofty temple
sounds good. Would a loadError event fire if none of the buttons could be displayed
thorny gate
sounds good. Would a `loadError` event fire if none of the buttons could be disp...
No. There are legitimate reasons for not displaying the buttons (e.g. Apple Pay doesn't show in Chrome) so there won't be a loadError
Yeah, so I confirmed that the element can/will load and fire on('ready') while client-side calls are still being made to get resources for the inner elements
lofty temple
ah alrighty then
Can you suggest a best approach here? Thats a vague question outside-in but we create our payment intent objects on the backend with setup_future_usage set to on_session, and we then use the same PI object for wallet payments, card payments and affirm flows. When confirming the wallet, Stripe errors as the element instance's setup_future_usage of null mismatches the backend
oh hold on a minute looks like theres an availablePaymentMethods property on the event that fires actually
thorny gate
I mean, even if you could detect the changes to the selected payment method type and asynchronously updated the Payment Intent, you wouldn't be able to merge the changes from the Payment Intent into the Checkout Element.
I'd recommend just not creating the Payment Intent until after the user has confirmed their payment method.