#dmitry-3ds

1 messages · Page 1 of 1 (latest)

mighty depot
#

you probably didn't pass off_session when creating the PaymentIntent for the charge on the saved card

#

yep, indeed you didn't

trail anchor
#

Okay, now that I've added this param, I'm getting another error You cannot confirm with the off_session parameter when setup_future_usage is also set on the PaymentIntent. Could you please clarify the purpose of setup_future_usage? Do I even need this param here?

mighty depot
#

no you don't need it for the off session payment so you'd omit it in that case

#

it's for if you were using that PaymentIntent to save a card(it has the effect of saving the card and setting it up for future payments, exactly the same as doing a SetupIntent. But if you are e.g. saving the card now and also charging it now, you should use PI+sfu, not SetupIntent->immediate PaymentIntent, to be clear).

#

setup_future_usage is what you set on a PaymentIntent being used in a flow like that one where you charge the card+save it, in one step

unknown.png
trail anchor
#

In case of PI+sfu, How would I use StripeJS's functionality to automatically display the 3DS screen?

mighty depot
#

confirmCardPayment // confirmPayment, same as any payment, it will display any 3D Secure needed and process the payment

trail anchor
#

Are there any downsides in using SetupIntent->immediate PaymentIntent?
My UI is built in such a way that it's allowing a customer to both add a card and pay immediately, or add a card without paying, all on the same page.
Can I use a single approach (SetupIntent->ConfirmCardSetup->PaymentIntent) for both of these scenarios? Or do I have to also implement PaymentIntent->ConfirmCardPayment?

mighty depot
#

the main disadvantage is the customer sees the 3D Secure page ask for $0 even though your messaging might make them think they are paying $100(since you're going to charge that immediately after), that's a common complaint we see

#

also there's no actual guarantee the payment will succeed and not require authentication as well(since you should process it as an on-session payment, so it doesn't actually have any exemption(that's what you saw when you tested this, after all).

Also potentially a chance of the bank declining the payment if they think two charges in quick succession(the SetupIntent can technically charge a small amount to validate the card(https://support.stripe.com/questions/unexpected-1-charge-on-customers-bank-statement) ) looks like fraud.

so there's a few reasons to never so SI->immediate PI. (all of these are things I see occasionally when supporting our users so they're not purely hypothetical)

#

My UI is built in such a way that it's allowing a customer to both add a card and pay immediately, or add a card without paying, all on the same page.
maybe split the flow, so you call just stripe.createPaymentMethod when the page is submitted, then when handling the form submission event, based on what the user picked either get a SetupIntent from your backend and confirm that using the PaymentMethod, or get a PaymentIntent and confirm that with the PaymentMethod, with branching logic in the Javascript . That I think makes more sense.
https://stripe.com/docs/js/payment_intents/confirm_card_payment#stripe_confirm_card_payment-existing // https://stripe.com/docs/js/setup_intents/confirm_card_setup#stripe_confirm_card_setup-existing

trail anchor
#

also there's no actual guarantee the payment will succeed and not require authentication as well

Why is that? I thought if I do SetupIntent->ConfirmCardSetup, this should take care of any future off-session usages?

mighty depot
#

sure, it does(though note it's not a guarantee, any payment might require 3DS, the bank can refuse the off-session exemption so you need a recovery) but if you do a PaymentIntent immediately that's not off session though

#

like you can claim that is it by passing off_session:true but it's technically not correct(though it's unlikely Stripe or the bank notices, but you still shouldn't do it)

trail anchor
#

So in theory the bank might refuse an off-session payment even if ConfirmCardSetup succeeds, right?

mighty depot
#

yes

trail anchor
#

And just the same, it can also refuse subsequent off-session payments if I use non-off-session PaymentIntent + setup_future_usage for 1st payment?

mighty depot
#

any payment at any time can require 3D Secure

#

the way you integrate is either :

  • SetupIntent if you're accepting the card without a charge but want to prompt for 3DS; then charge the customer's saved card without them present using a PaymentIntent with off_session or
  • PaymentIntent with setup_future_usage if you're saving a card during a charge, then then charge the customer's saved card without them present using a PaymentIntent with off_session

if you do it that way we can claim exemptions and it has the best chance to succeed. The 'happy' path is the 3D Secure done at the start of either of those flows results in the later payments not needing it(the 3155 card simulates that happy path) and it should mostly work that way. The bank can still refuse and prompt for 3DS on any payment though regardless of doing things this right way, so you need to bear that in mind in having a recovery flow

trail anchor
#

Or is this caused by something else?

mighty depot
#

you didn't set that PaymentMethod up from what I can tell

trail anchor
#

didn't set up in what sense?

mighty depot
#

you first used the payment method there in the PaymentIntent pi_3K1zEwEIzwO0cI9a12GXcHhI but didn't finish it

#

basically you ran that card with a PaymentIntent with setup_future_usage (good!) but you didn't actually complete the 3D Secure process, so it wasn't actually set up, so it's expected that trying to charge it later would still fail