#rjt_best-practices

1 messages · Page 1 of 1 (latest)

narrow archBOT
#

👋 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/1217190629453336686

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

uncut sequoiaBOT
thorny barn
#

Hello
Sounds like you're currently creating PaymentIntents prior to rendering the Element.

I believe you'd benefit from following flow instead:
https://docs.stripe.com/payments/accept-a-payment-deferred

It allows you to collect PaymentMethod details before creating an Intent. This way you can look at the tokenized PaymentMethod prior to creating the intent and set the fees accordingly

chilly flicker
#

Interesting, I will take a look at this

thorny barn
#

👍

chilly flicker
#

I will need to check this to make sure it supports all the features of our current checkout page

#

I can see that this uses the same .confirmPayment() method that our current implementation is using. If the client is calling this method, what would prevent the client from changing the used payment method before confirming?

thorny barn
#

Not sure what you mean by that. Can you elaborate?

chilly flicker
#

I am imagining a situation like

  1. Client enters a payment method through the payment element
  2. Client submits the payment form to the server
  3. Server creates PaymentIntent
  4. Server sends client_secret to client
  5. Client, now holding the client_secret, selects a different payment method in the element
  6. Client calls stripe.confirmPayment()
thorny barn
chilly flicker
#

Looking at the two-step confirmation flow, the client is still calling confirmPayment(). Does setting payment_method on the server prevent the client from modifying it?

#

I have not been able to find this confirmed in docs but my understanding is that possessing the client_secret gives the client the ability to choose the payment method (from the list of enabled types)

thorny barn
#

Actually, Elements give the customer ability to choose payment method type. Client-secret is just used to link the collected payment method to a payment.

Once you've called confirmPayment, the elements won't let the customer attach any other payment method to the same PaymentIntent afaik.

I'd recommend giving the flow a go in test mode. That should simplify things a bit.

chilly flicker
#

Once you've called confirmPayment, the elements won't let the customer attach any other payment method to the same PaymentIntent afaik.
Maybe I'm misunderstanding the flow here, but isn't there a period after the PaymentIntent is created (therefore after the application fee is set) but before the client calls confirmPayment?

I'd recommend giving the flow a go in test mode
Will do

thorny barn
#

I think the piece missing in the docs (at least I couldn't find it) is that you could use stripe.createPaymentMethod(...) function to create a payment method prior to confirming the PaymentIntent
https://docs.stripe.com/js/payment_methods/create_payment_method_elements

And then pass it to confirmPayment via confirmParams
https://docs.stripe.com/js/payment_intents/confirm_payment#confirm_payment_intent-options-confirmParams-payment_method

Which is the flow I was thinking about but it looks like we've updated our docs to not recommend that flow for some reason.