#bachir2921

1 messages · Page 1 of 1 (latest)

topaz topazBOT
#

Hello! We'll be with you shortly. 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.

narrow forum
#

Hi there!

full depot
narrow forum
#

Oh so you mean changing the paymnet method directly on the frontend?

full depot
#

Yes, I'd like to be able for example to say to hide the "PayPal" one based on some conditions in the frontend

image.png
narrow forum
#

You can change the order of PaymentMethod: https://stripe.com/docs/js/elements_object/create_payment_element#payment_element_create-options-paymentMethodOrder
You can disable wallets: https://stripe.com/docs/js/elements_object/create_payment_element#payment_element_create-options-wallets
But I don't see a way to disable/enable other payment method directly on the frontend. One option is to:

full depot
#

Oh ok that's interesting I didn't realize the PaymentElement was linked to the payment intent. So the payment intent should be created before we render the PaymentElement on the frontend, right ?

narrow forum
full depot
#

For now we are still using the CardElement, and looking to migrate to the PaymentElement. We use the deferred flow : we collect the payment method then creating the payment intent using the payment method ID.

#

This could be changed though if it allows us to control the displayed payment methods in the PaymentElement

narrow forum
#

Thanks for the clarification, looking into this...

fierce wadi
full depot
#

Ok! Would you recommend using the regular flow ? Would that work with subcriptions too ?

fierce wadi
#

Would you recommend using the regular flow ?
It depends really. Can you elaborate more on your use case?

Would that work with subcriptions too ?
Yep both deferred and non-deferred flows work with recurring and one-time payments

full depot
#

It depends really. Can you elaborate more on your use case?
We process payments for non-profits. So donors come on forms we host that non-profit have created on our platform, fill in an arbitrary amount for a donation then pay. We then transfer this amount to the non-profit stripe balance. They can also make recurrent (monthly, yearly) donations. We provide card, ACH, Pre-authorized debit payment methods.

We'd like to use the PaymentElement component to modernize our UI, take leverage of integrating new payment methods automatically through Sdtripe and simplify our frontend flow when handling non-card payment methods.

fierce wadi
#

Either flow would work in this scenario. I guess it'd depend on how you arcitect your checkout flow. I can imagine a scenrio where a donor ultimately changes the amount they want to donate, which the deferred flow is better suited for (as then you won't need to back backend calls to update the existing Payment Intent)

full depot
#

Indeed - i'll try to integrate it using our current flow.

Now I'm trying to instantiate the PaymentElement following this https://stripe.com/docs/payments/quickstart?client=react, but it seems like I need the payment intent secret in order to instantiate the component : so I need to create a payment intent at the beginning of the flow ?

Custom payment flow

Learn how to embed a custom Stripe payment form in your website or application. Build a checkout form with Elements to complete a payment using various payment methods.

fierce wadi
#

Well, that's the non-deferred flow. If you're going that route yes you need a PI before you can initialise the Payment Element

full depot
fierce wadi
#

Yup

full depot
#

Alright, thanks for your help!