#ionu_docs

1 messages ยท Page 1 of 1 (latest)

oblique wedgeBOT
#

๐Ÿ‘‹ 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/1309448373719535698

๐Ÿ“ 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.

random spruce
#

hi there!

#

what's your question?

pale harness
#

can klarna be used with setup_future_usage: 'off_session', ?

random spruce
#

so no it doesn't look supported.

pale harness
#

ok, so I cannot add/use a pm on a future payment. Thank you very much

#

I would have one question, is there a way to have payment_method_types klarna and card, card to have setup_future_usage and klarna no ?

random spruce
#

I know when creating the PaymentIntent first, it is possible yes.

pale harness
#

with code
const options = {
mode: 'payment',
amount: 10000,
currency: 'eur',
setup_future_usage: 'on_session', // with an if
// Fully customizable with appearance API.
appearance: {
theme: 'flat',
},
payment_method_types: ['card', 'klarna'], // Prioritize Klarna for display
};

#

ok, so not with createConfirmationToken

random spruce
#

but in the flow you are uisng I son't think it's possible no.

pale harness
#

what would be the flow for it than ?

random spruce
pale harness
#

so the elements would be without the setup_future_usage, in the backend a payment intent would be created based on the method they selected, and there would not be a conflict like it is now with the tokenization

#

this way you make the paymentIntent, than based on the client_secret returned, you confirm the payment in front end

random spruce
pale harness
#

yes, my problem with this approach is that the user clicks on the "pay button", it goes to the backend to process stuff, and upon return, if it takes too long, upon the selection of google pay, the popup for google pay will throw the error :
Something went wrong. Unable to show Google Pay. Please choose a different payment method and try again. and an error in the browser console saying Uncaught DOMException: Failed to execute 'postMessage' on 'Window': Delegation is not allowed without transient user activation.
So I switched to the token because I got stuck on this one

random spruce
#

it goes to the backend to process stuff, and upon return, if it takes too long
what does take too long exactly? I don't follow. you should create the PaymentIntent in advance to mount the Payment Element, so there's nothing to wait for.

pale harness
#

the issue is that the amount is variable, and the process would be: user selects some options, than hits pay. At that moment the process goes, calculates the amount, than returns the secret, and in the front it will confirm. This way the amount is calculated once, at the button click.
Otherwise I would need to create a paymentIntent with the initial amount, than keep updating it on every modification. And like this, every page access will create a payment intent

#

and also how would you know when using automatic payment methods what the user will select so to put or not setup_future_usage on creating the paymentIntent

random spruce
#

give me a few minutes to double check somthing

pale harness
#

sure, thank you

oblique wedgeBOT
random spruce
#

I double checked, and you can't set setup_future_usage on individual payment methods when using Confirmation Tokens. so if you need to than option, you need to find a way to make the PaymentIntent-first approach work.

muted juniper
#

๐Ÿ‘‹ taking over for my colleague. Let me know if there's any follow-up Qs I can answer!

pale harness
#

ok, thanks. I will take another approach, when the user selects an "one-time" payment from our platform, we will re-mount the form with the off-session removed. That way klarna will appear. If we have "recurring payment that we will handle later", again, the mount will refresh the options
that way, if it is one time payment, we will not use the card anyway

#

Thank you for the feedback. I really appreciate it

muted juniper
#

I think elements.udpate is an easier way to unset setup_future_usage instead of the un-mounting/remounting approach

pale harness
#

oh, great, thanks

#

yeah, works great. Thank you again