dawid-paymentelement-sfu

[primal pilot]

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.

• dawid_fw, 6 days ago, 24 messages
• dawid_fw, 6 days ago, 20 messages

[wide zinc]

Hello! How are you currently using Payment Element? Are you using the deferred flow or are you creating the intentn ahead of time and passing that to payment element?

[visual gale]

We use deferred flow

We tried to dynamically set setup_future_usage based on selected payment method on FE and BE, but we receive error when trying to create paymentIntent on backend that selected payment methods do not support it

`setup_future_usage` cannot be used with one or more of the values you specified in `payment_method_types`. Please remove `setup_future_usage` or remove these types from `payment_method_types`: ["p24"].

And if we try to skip it on BE it returns:

"message": "The provided payment_method_types ([\"card\"]) does not match the expected payment_method_types ([\"p24\", \"card\"]). Try confirming with a Payment Intent that is configured to use the same parameters as Stripe Elements.",

on FE

[wide zinc]

With the deferred flow are you using createPaymentMethod and confirming server-side? Or are you confirming client-side with confirmPayment?

[visual gale]

clientSide with confirmPayment

[wide zinc]

Sorry I had a draft message and completely forgot to send it!

Gotcha - so I can think of two workarounds to get the behavior you want:

• You switch to using createPaymentMethod and confirming server-side (I believe create PM has laxer validations with how the PaymentMethod can be used so you shouldn't get the "does not match" error you were seeing)
• You switch to creating the PI first, set setup_future_usage: off_session but also you can set setup_future_usage: none for specific PM types under payment_method_options (here's an example for bancontact: https://stripe.com/docs/api/payment_intents/create#create_payment_intent-payment_method_options-bancontact-setup_future_usage)

[visual gale]

Hmmm
It sounds like it also might work with deferred flow.

Are you sure it doesn't? 🙂

stripe payment_intents create --amount="2000" --currency="pln" --setup-future-usage="off_session" -d "payment_method_types[0]=card" -d "payment_method_types[1]=p24" -d "payment_method_options[p24][setup_future_usage]=none" 

above on backend + dynamic setup_future_usage on fe, won't it work?

At least one above went through, so I guess we can test it Tomorrow

[wide zinc]

Yeah the suggestions I mentioned above are two separate workarounds - the first one IS the deferred flow, just with a modification to use createPaymentMethod instead

[visual gale]

But I mean 3rd option. With our current flow, but just adding payment_method_options (that I didn't saw before!)

I will test it Tomorrow and eventually try one of yours proposals if it won't work.

[wide zinc]

I don't think that'll work because you'll get the mismatch error (since setup_future_usage that you set client-side won't match what you're setting top-level on the intent)

But you're welcome to try!

[visual gale]

    const setupFutureUsage =
      selectedPaymentMethod === 'card'
        ? checkout.paymentConfiguration?.stripe?.setupForFutureUsage
        : null

But we already have it dynamic on FE based on selected payment method and it seems working

Ok, thank you!

[wide zinc]

Yeah definitely try it out and see how it goes - it's hard to predict what will/won't work because of all of the special casing you have in your logic

[visual gale]

Thank you! Have a good day!

[wide zinc]

you too!