#jackson_api
crude canopyBOT
👋 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/1361369721026383912
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
fervent bluff
glacial garnet
Hi 👋
The trouble is, that setupFutureUsage parameter applies to all payment methods, so any that do not support it are not presented in the Payment Element.
fervent bluff
yeah
glacial garnet
I know that you can customize this with the Intent-first integration with the Payment Element but I'm not certain we support it with the deferred intent approach
fervent bluff
ideally want scenario where like for card it will do setup_future_usage but then for everything else it won't
is there an approach where you mutate the elements instance some how before submission?
glacial garnet
Yeah, if you use an Intent-first approach you can specify setup_future_usage for only the payment methods that support it in the payment_method_options parameter
fervent bluff
or mount two separate elements, one for future usage and another for non-future usage? and then just display them side by side in the UI?
glacial garnet
That would get pretty unweildy, in my opinion. You would need two instances of elements to handle each one and one instance could not confirm the other's element
fervent bluff
I guess another possibility would be to just use a separate CardElement and then Payment Request buttons for card / apple pay / google pay, and then just have the PaymentElement render all other payment methods besides those
Trying to see what the easiest / most logical path is here
glacial garnet
Yeah, ideally we would replicate the same functionality between our intent-first and deferred intent integrations.
Unfortunately, without that feature parity, it's quite difficult to achieve what you are looking for.
glacial garnet
The problem with multiple elements (Payment Element, Card Element) is that Stripe.js was designed and generally assumes you are working with a set of elements that are all inter-related (like the Address Element and Payment Element).
That said, you might be able to achieve this with enough trial/error. But it wouldn't be as clean as I think we'd all prefer.
glacial garnet
I have flagged that you are interested replicating the paymentMethodOptions in Stripe.js that currently exist when creating Payment Intents. Hopefully we can prioritize that work.
Right now, I think setting up distinct UIs that instantiate their own Elements options with SFU and non-SFU payment methods is likely your best bet (SFU = setup future usage)