#ionu_docs
1 messages ยท Page 1 of 1 (latest)
๐ 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.
- ionu_docs, 2 days ago, 19 messages
can klarna be used with setup_future_usage: 'off_session', ?
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 ?
I know when creating the PaymentIntent first, it is possible yes.
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
but in the flow you are uisng I son't think it's possible no.
what would be the flow for it than ?
the flow would be to first create the PaymentIntent, and there set setup_future usage not at the toplevel, but for each payment method. For example for cards: https://docs.stripe.com/api/payment_intents/create?lang=php#create_payment_intent-payment_method_options-card-setup_future_usage
then use the client secret of the PaymentIntent to mount the Payment Element.
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
I recommend reading this guide that covers the standard integration (not using tokens): https://docs.stripe.com/payments/accept-a-payment?platform=web&ui=elements
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
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.
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
give me a few minutes to double check somthing
sure, thank you
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.
๐ taking over for my colleague. Let me know if there's any follow-up Qs I can answer!
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
I think elements.udpate is an easier way to unset setup_future_usage instead of the un-mounting/remounting approach