#tobewisebeforeiamold_code
inland deltaBOT
👋 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/1393289900706762833
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
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.
- tobewisebeforeiamold_code, 42 minutes ago, 8 messages
grim raven
StripeBot gave me an invalid response to this same question, then locked me out of a reply. It suggested I pass in wallets as an option to checkout.createPaymentElement but wallets is not an available option on that method, so StripeBot was blatantly wrong.
vast oxide
checkout.createPaymentElement() isn't a Stripe.js function. Which integration guide are you following? Can you share the doc link?
grim raven
Another member of this company implemented this Basil code, and I'm not sure where he got his information. I believe it was a mix of Stripe Discord and https://docs.stripe.com/js/custom_checkout/create_payment_element and inspecting types on the @stripe/stripe-js@7.4.0 and @stripe/react-stripe-js@3.7.0 packages. So unfortunately I can't exactly reference his implementation documentation.
vast oxide
Sorry, my bad! Custom Checkout slipped my mind
grim raven
No worries! The code I'm looking at is const checkout = await stripe.initCheckout( { fetchClientSecret } ); const paymentElement = checkout.createPaymentElement(); paymentElement.mount( checkoutContainerRef.current ); checkoutElementRef.current = checkout; so it's pretty vanilla for custom checkout, I think. I'm just trying to get apple/google pay to not appear in some cases.
vast oxide
https://docs.stripe.com/js/custom_checkout/create_payment_element#custom_checkout_create_payment_element-options doesn't support wallets as an option. That's why it doesn't work when you attempting to set wallets config
grim raven
Exactly! but it looks like paymentElement.update does...at least the types the NPM package comes wit says it does.
vast oxide
Updating Payment Element also doesn't support wallets too: https://docs.stripe.com/js/elements_object/update_payment_element#payment_element_update-options
The type here can be misleading here
I'm afraid there isn't an way to disable Apple Pay when Custom Checkout is used using Payment Element.
Another alternative is to create a new Payment Method Configuration with Apple Pay and Google Pay disabled: https://docs.stripe.com/payments/payment-method-configurations
You can then set the newly created PMC to the Checkout Session creation: https://docs.stripe.com/api/checkout/sessions/create#create_checkout_session-payment_method_configuration
grim raven
So we can use wallets to disable apple/google pay via <PaymentElement options using @stripe/react-stripe-js - just saving a payment method to a customer, but in checkout we cannot optionally turn it off/on? Apple/Google pay is an all-or-nothing proposition in checkout?
Another alternative is to create a new Payment Method Configuration with Apple Pay and Google Pay disabled
Oh, that's interesting!
vast oxide
Custom Checkout respects the payment method configuration on the Checkout Session as opposed to direct Payment Element creation
grim raven
Got it. Is there any plans to augment the checkout session element to make it align more with the plain ol' payment element? I'm just curious so I can report back. Also, I'm not very familiar with payment method configurations: are there any down side to having multiples of those: any refund or dispute ramifications, etc?
I have to take my mother-in-law to her cardiologist, so I'll be away for a bit. Sorry!
I'm back, but I don't think it's fair of me to ask you to determine if there are drawbacks to using different payment method configurations. I can research that. Thank you for your help!
vast oxide
Thanks for the waiting!
Also, I'm not very familiar with payment method configurations: are there any down side to having multiples of those: any refund or dispute ramifications, etc?
There is no downside. It provides more flexibility for PMC on different scenarios
grim raven
Awesome, thanks again for your help!
vast oxide
No problem! Happy to help 😄