#b33fb0n3_api
silk obsidianBOT
👋 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/1227561359718486056
📝 Have more to share? Add more details, code, screenshots, videos, etc. below.
tawdry ospreyBOT
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.
- b33fb0n3_docs, 1 day ago, 9 messages
- b33fb0n3_best-practices, 1 day ago, 42 messages
- b33f_paymentmethod-retrieve, 5 days ago, 20 messages
- b33fb0n3_api, 6 days ago, 11 messages
meager forge
you found my problem 🙂
Yea
meager forge
let me know if you need any more help
I need more help
rapid hill
yes sure...
meager forge
https://docs.stripe.com/payments/payment-element/migration-ct#client-side
I tried to replace the payment method creation to a confirmation token creation...
I already described it and whats the problem with it
rapid hill
do you mean you just want to retrieve the confirmation token https://docs.stripe.com/api/confirmation_tokens/retrieve ?
meager forge
give me a second I paint it for you..
rapid hill
yes sure
meager forge
yes sure
this is the default initialization from my own checkout session right now with payment method id. I've left out the part about changing the payment method, because it's not part of the problem right now
meager forge
yes sure
and the red text is the problem:
The Server can't create a confirmation token
based of the default payment method, because
it's not possible serverside
rapid hill
give me a couple of minutes to review this and get back to you
I think you're going about this wrong
meager forge
why?
rapid hill
if you already have a payment method, you don't need a confirmation token
meager forge
if you already have a payment method, you don't need a confirmation token
right now I have only this: https://docs.stripe.com/api/customers/object#customer_object-invoice_settings-default_payment_method
rapid hill
Build an integration where you render the Payment Element before you create a PaymentIntent or SetupIntent, then confirm the Intent from your server.
https://docs.stripe.com/payments/finalize-payments-on-the-server
if you already have this payment method on the customer object this means it's already saved for future usage
you no longer need a confirmation token
meager forge
why not?
rapid hill
because a confirmation token is a way to validate a payment server side when your customer enters their payment details
meager forge
ok, and what if the user just enters a checkout session, the default payment method is already chosen and the customer want to directly buy it? Without modifying anything. And what if the customer want to modify it?
rapid hill
if they don't want to modify you just use the existing PM to handle the payment in the backend
and if they want to choose a new payment method then you can use the confirmation token
meager forge
if they don't want to modify you just use the existing PM to handle the payment ...
how? and how to display it correctly when there is no paymentmethod id inside my cart?
meager forge
and if they want to choose a new payment method then you can use the confirmatio...
ohhh ok
meager forge
why can't I then directly use the paymentMethod id?
payment_method: '{{PAYMENT_METHOD_ID}}',
Why should I migrate to confirmation tokens, when I later still need to provide a payment method id?
It makes no sense for me to build a second flow, just to support confirmation tokens...
tawdry ospreyBOT
jovial pivot
yeah confirmation tokens are a new thing, and full disclosure, I haven't looked at/used them at all yet. The idea is that they contain more than just the PaymentMethod, they have all the 'context' of like the other payment options and stuff like shipping addresses so you don't have to pass as much state around between front and back end.
meager forge
oh ok, so in my case while just having the paymentmethod from stripe it's not important for me to migrate to confirmation tokens?
jovial pivot
I'm not sure sorry, haven't looked at CTs yet so I couldn't give a confident answer
if you have something that works I wouldn't say you have to migrate?
but totally reasonable to want to , and ideally we could help you, just my team hasn't had training or a chance to get up to speed yet(if you open a support ticket we can definitely help, will just take a bit longer as we figure it out)
meager forge
yea, I saw it's a new feature and I like new features, because normally they make the life better (in most of the cases). I think with a bit of training it will be better ^^
I guess I stay with your opinion, that if it works I don't need to migrate.
Can I ask a different question?
jovial pivot
sure
jovial pivot
which one lol, we had two different Orders APIs that were both deprecated and removed
meager forge
idk, the last one lol
jovial pivot
I can't answer "why" questions, mainly its things like prioritisation and product-market-fit. I believe one of the main reasons was one of the main problems it was solving we decided was better handled by a standalone tax calculation solution(https://docs.stripe.com/tax/custom) instead, and also things like further investment in Checkout(including its embedded mode not requiring a redirect) solved a lot of the same problems