#brayden
astral dome
livid sluice
hello! I think I know why, what test card are you using on the SetupIntent
iron crown
Hey, I'm using this one 4000002500003155
Which in your documentation says, "This card requires authentication for every payment unless you set it up for future payments. After you set it up, it no longer requires authentication."
To which, I believe I have set it up correctly as I get a succeeded status whenever I confirmCardSetup in my code on the SetupIntent that I create for it.
livid sluice
gotcha, that is the right card to use
so let's start here
1/ pls share the ID of the successful SetupIntent
2/ pls share the ID of the PaymentIntent which is requiring authentication
I can debug from those two
iron crown
One sec
SetupIntent confirming off_session usage: https://dashboard.stripe.com/test/setup_intents/seti_1LvBzjALivADE4Jr0qLekv6I
PaymentIntent requiring 3DS auth: https://dashboard.stripe.com/test/payments/pi_3LwRpKALivADE4Jr0EI4nXDE
livid sluice
thanks, digging
hmm wait
your SetupIntent creation and usage was fine
so that part checks out
but
ah I see
the PaymentIntent you're referring to is not the first PaymentIntent on the Invoice (which is expectedly going directly into "succeeded")
this is for a modification of the Subscription
which by default is not off_session
so you can (while updating the Subscription like in https://dashboard.stripe.com/test/logs/req_Xwq6705aRiMO82)
pass off_session: true to flag that your end customer is not in your payment flow, only then will this change be treated as off_session https://stripe.com/docs/api/subscriptions/update?lang=cli#update_subscription-off_session
iron crown
Interesting, is there any bad side effects to considering all payments off_session?
Okay, so here I added off_session: true to my Stripe::Subscription.update() call, and I still get that the payment method requires authentication: https://dashboard.stripe.com/test/invoices/in_1LwSetALivADE4JrcgloMi5B
livid sluice
your request did not pass off_session param, see: https://dashboard.stripe.com/test/logs/req_9CHpdKFMTwpWaa
Interesting, is there any bad side effects to considering all payments off_session?
really, it depends. Is your customer in your payment flow, manually changing their own Subscription Price/schedule? then you should not pass that param.
if they are not in your flow but you as a merchant are changing their Subscription, then you pass it.
the goal is to just reflect whether the customer is in session or off session. 3DS authentication is up to the bank really so it chooses when to prompt for it or not.
iron crown
Let me maybe describe the flow a bit and see what you think about the usages we're defining
We have a fraud review period that we put our customers through. In order to make their experience more streamlined, we collect a payment method from them at the start of the review period (where setupIntent is created and confirmed if 3DS is required). We then take about 2 business days to review and either approve or deny them. If we approve, we would like to be able to charge the payment method collected previously without having authentication happen again. Would you consider this an off_session payment scenario?
It seems to fit from how your docs are defining it.
prisma ibex