#chung-yi_best-practices
wicked nexusBOT
👋 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/1458921888100384870
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
frigid trellis
Hello 👋
I'm reviewing my test integrations and I don't see a clear way to determine what payment method types are presented to each user for each session with the Payment Element.
I think it would make sense to be emitted in the ready event. I can file this as a feature request
alpine orbit
Yes, it'd be great the presented payment methods can be provided in the ready event in a similar way as Express Checkout element.
Thank you for filing the feature request. Is there a good way to keep track of (future) changes?
frigid trellis
You can write in to Support here: https://support.stripe.com/contact
They will be able to find my feature request and link it to your email. That way, when there is an update about it, they will get notified and can share that info with you.
wicked nexusBOT
alpine orbit
Great! I can contact them. Thanks!
frigid trellis
If you just want to track all future changes to Stripe and Stripe.js, I recommend signing up for the Stripe developer digets: https://go.stripe.global/dev-digest
You will get regular newsletters about updates to Stripe APIs and Elements
alpine orbit
In the mean time, if we want to track the presented payment methods, I assume we probably need to somehow work around it. For example, on the ready event, search for the UI identifiers for each payment methods (which is subject to change). Something like that, right?
Good to know about the Stripe developer digets. I'll sign up now!
frigid trellis
I don't think you can access those elements directly but you can try. However, Stripe updates Stripe.js 2x per day so I would be wary of any hacky work-around that relies on HTML attributes.
alpine orbit
Yeah, hack and not reliable for sure.
Can I ask you another Payment Element implementation question?
bronze tulip
Hi there, taking over for @frigid trellis as they had to step away. Happy to help with your question
alpine orbit
Thank you @frigid trellis ! And hi @bronze tulip !
So, our use of Payment Element may be a bit complex. Users can check out with credit card, us bank account, or sepa debit. When checking out with credit card, we want to do a credit hold. However, specifying captureMethod: "manual" in the elements option would make us bank account and sepa debit disappear. And my understanding is that inapplicable parameters would further limit the presented payment methods in Payment Element.
To be able to show users all possible payment methods, what we are doing is to configure Payment Elements with minimal compatible params, and later before submit, update the params to the exact ones, based on the selected payment method. For example,
We render the Payment Element initially with:
mode: "payment",
paymentMethodOptions: {
us_bank_account: {
verification_method: "instant",
financial_connections: {
permissions: ["payment_method", "balances", "ownership"],
prefetch: ["balances"],
},
},
},
setupFutureUsage: "off_session",
captureMethod: null,
paymentMethodTypes: null,
onBehalfOf: "acct_xxx,
And later on submission, if the user checks out with us bank account, update the params with:
elements.update({
captureMethod: "automatic",
setupFutureUsage: null,
mode: "setup",
paymentMethodTypes: ["us_bank_account"],
onBehalfOf: null,
})
It works fine based on our tests, but it feels strange that we can update the params after the user interacts/submits the payment through Payment Element UI. I'd like to double check if it's a valid implementation.
bronze tulip
Got it, looking into it now
alpine orbit
Thank you!
bronze tulip
Okay, so if I'm understanding your approach correctly, you're using a deferred approach where you render the Payment Element prior to creating the PaymentIntent
https://docs.stripe.com/payments/accept-a-payment-deferred
Is it possible to create the PaymentIntent on the server first? Because if you can, you can configure the capture method option specifically for the card payment method (basically configure options for each separate payment method type with payment_method_options)
https://docs.stripe.com/api/payment_intents/create#create_payment_intent-payment_method_options-card-capture_method
alpine orbit
Our needs are more complex than the capture method. As you can see above, we want to use payment mode for credit card but setup mode for us bank account and sepa debit. We also wan to not specify on_behalf_of for us bank account transactions. I guess those can't be pre-configured per payment method in the Intent?
bronze tulip
Got it. I would say it's a unique use case where the PaymentIntent is either setup or payment depending on the payment method, I haven't run across this before. Can you explain a bit as to why this is a requirement for your integration?
alpine orbit
It's a business decision where we don't process the payment immediately after checkout and require sellers to approve. However, for CC we do want to place a hold to make sure sufficient, etc.
and then the on_behalf_of differences was because of ACH mandate I believe. We want the bank account to be set up on the platform account (so without the on_behalf_of) so it can be reused in the future with a different merchant (connected account).
bronze tulip
Got it, let me think about this some more. In the end, the approach you outlined does what you intend, I'm just a bit surprised that you're able to edit the mode afterwards like you mentioned. I feel like there may be some other flow that separates these steps to avoid that kind of editing, giving it some thought
wicked nexusBOT
alpine orbit
Yeah, I was surprised too. I feel there may be cases where the payment/intent ends up being created differently than how the user saw/interacted with the UI. Wonder if it's technically possible but we have to take the responsibility if going down this route.
coral moth
Hi there - I'll be taking over for nobs
Just getting caught up
okay sorry - helping other folks as well
alpine orbit
I have to step away shortly and check back later. If you have any insight, it would be appreciate! 🙏
coral moth
Okay so I wanted to recommend you our two-step confirmation guide because that is kind of the "right" way to do something like this but you run into the same validation errors about the "mode" that elements used when creating a Confirmation Token.
I think there are three possible ways to handle this but I need to do a little testing to validate my expectations
Okay, so one approach you can take is listen to the Payment Element's change event and then update the Elements instance's options (mode, etc) if the change event's value.type is a payment method type where you want to do a SetupIntent instead of a PaymentIntent. There is visible indication of this to the user because it causes the Payment Element to be unmounted/remounted
The second approach is that instead of creating a SetupIntent/PaymentIntent/Confirmation Token, you can create a Payment Method directly
https://docs.stripe.com/js/payment_methods/create_payment_method
We don't seem to validate the Elements' mode if a Payment Method was created directly, so you can use a Payment Method collected in payment mode to create/confirm a SetupIntent. I wonder if there are limitations to this approach, but I have not found any so far