#xaositect_docs
bright patioBOT
👋 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/1382824263945556081
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
floral shadow
Hi there
opal robin
Good afternoon!
One of our founders thinks there may be a way to better highlight google pay, apple pay via the accordion, which to me suggests allowing multiple payment methods in the instantiation.
floral shadow
I'm not entirely sure what you mean by that. I think what you're asking is if we expose the currently selected payment method type in Stripe.js on the change event for the Session object
To which the answer seems to be 'no'
opal robin
Also seems like the update capabilities for a checkout session are very limited
So we do need to go with the choose a payment method and then instantiate the checkout session?
In our ideal world, you'd see the accordion of acceptable payment methods, the user would choose one, and we'd charge the user the pricing for that particular payment method, but it seems like that is not possible.
floral shadow
You might be able to get the current payment method from the Payment Element change event, however https://docs.stripe.com/js/element/events/on_change?type=paymentElement
opal robin
Yeah but we're actually looking at the embedded checkout element. Maybe I should look at the payment element instead?
floral shadow
The taxonomy is a little confusing, but that is what I'm talking about. The "Custom Checkout" flow uses Checkout Sessions on the Payment Element
If you're going that route, though, what specific features do you need in this flow relative to a Payment Elements integration, if any?
Because I'm wondering if you'd be better served with an integration where you collect payment details and then create a PaymentIntent after, when you know what you're going to charge
opal robin
That's a great question. Our current integration uses the stripe card element and an apparently deprecated plaid flow to capture payment methods ( that we're trying to get away from ) and then does use payment intents and confirmation of those as you suggest
But most of the selection of pre-existing payment methods is done via our gui rather than stripe elements, because of the plaid bit
floral shadow
Custom Checkout / Embedded Components is the new shiny thing 😄
But maybe give that guide I sent a look and see what you think?
opal robin
Probably why our account manager was like "hey you should do this!"
I'll take a look at that one.
Thank you for the advice.
floral shadow
Isn't that always the way it is 😄
I mean I think the reason why we built this is so that people could have the low-profile nature of the Payment Element, but still get access to some of Checkout's features like automatic tax and the ability to update shipping rates and quantities and things like that
opal robin
We're also looking to expand into Canada late this year, and the tax features were attractive
floral shadow
understandable