#dannnnnnnnnnnnnnnnnnnnnn_unexpected

1 messages · Page 1 of 1 (latest)

torn wagonBOT
granite sealBOT
#

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.

torn wagonBOT
#

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

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

solid hull
#

What specifically is unexpected/different here?

main perch
#

the 3ds check we got on the new payment intents

#

we never previously got them before for what we thought were off session payments however after the earlier convo I found out that the latest payment intent is an on session payment

solid hull
#

So we assume customer is on-session and can auth the payment, and we won't request any MIT auth exemptions from the bank

#

FWIW the other payment didn't pass off_session: true either. So if they're actually off-session you need to pass that param

main perch
#

afaik we've never passed off_session=True in our payment intent create calls and we've never had an issue with this.

#

I'm just having a look back through our changes recently as we speak so if I spot anything I'll chuck that in here

solid hull
#

To be clear, when you use setup_future_usage we optimise to prevent any potential auth requests on future payments with those cards. However there's no guarantee they won't happen which is likely what is just happening here

#

You want to pay with card X that was previously saved, but the bank has determined that it wants auth on this occasion – totally normal and your integration needs to handle that accordingly

#

If these payments are actually off-session (MIT, where customer is not online) then passing off_session: true wil further optimise for those SCA exemptions to try and reduce auth

main perch
#

Sorry I am still here I'm just processing everything you've said and trying to find more info

#

afaik we've never used the setup_future_usage param as we force users to save cards which we add to their customer in Stripe and then select from those methods to pay

solid hull
#

setup_future_usage: 'off_session' === Setup Intent w/ usage: 'off_session'

#

s_f_u is just the Payment Intent specific parameter. Same principles apply

solid hull
main perch
#

yeah thanks for clarifying that the s_f_u is doing the same as our usage=off_session

#

makes more sense

solid hull
#

Let me know if I can clarify anything else

main perch
#

yeah will do, I'm just taking a look at everything

#

So can I just clarify, the only way to 100% make sure a payment occurs as off session is to create the payment intent with the off_session=True parameter? and if so whats the best workflow for us. We currently force users to save a card before being able to pay for anything which we save to their customer account in Stripe, then we display a list of all their payment methods which they can select from and then click pay now. Upon reaching the page with their card details we create the payment intent so have never passed off_session=True as that requires confirm=True and the selected pm but they haven't selected the one they want to use yet. Is the best practice to only create and confirm the payment intent on the post request to pay for the item?

solid hull
#

There's to way to 100% make sure it occurs unfortunately. As I said, banks can (and do) request 3DS/auth on payments even when we request exemptions from auth. That's just how it works and your integration needs to handle that

#

Upon reaching the page with their card details we create the payment intent so have never passed off_session=True as that requires confirm=True and the selected pm but they haven't selected the one they want to use yet. Is the best practice to only create and confirm the payment intent on the post request to pay for the item?
What you're describing is not an off-session payment. The customer is on-session selecting a payment method so should be able to complete auth (if requested)

main perch
#

but for our system it can also not be the customer so it can be off session

solid hull
#

Then flag those as such, but ultimately there is no way to completely prevent 3DS/auth requests

main perch
#

ok thank you, and one last thing then to clarify so I can go back to this chat, even passing off_session=True and confirm=True and the selected pm, it won't guarantee then that the 3DS/auth check won't occur

signal shadow
#

hi! I'm taking over this thread.

#

that's correct, the bank may decide to start the 3DS flow even when "off_session=True and confirm=True". so your integration needs to take this into account (ask the user to go back to you website/app to re-confirm the PaymentIntent to trigger the 3DS flow).

main perch
#

ok thats all cleared up for me now, but do you have any idea why we've never ran into this issue before? Our admins could take payment for a client and never got these 3DS checks before, and now all of a sudden we removed on session payments temporarily as we had an issue with them and it caused this 3DS issue. My colleague is asking why because all we did was comment out our on session code.

#

I get that its up to the bank, but why in a year and a half have we never encountered it until we made that switch and then all of a sudden within two hours we had multiple payment intents requiring 3ds checks when an admin was taking payment

signal shadow
#

Our admins could take payment for a client and never got these 3DS checks before
can you clarify what you mean by this? who are "admins" and what do they do exactly?

main perch
#

admins are also just users on our system, however they are not the client/customer they are taking payment for. So it would be an off session payment

#

sorry I've worded that badly, admins can take payment for a someone else basically

signal shadow
#

you mean it's not the end user who enter their card details in the form, but it's the admins that are doing this on behalf of the user?

main perch
#

yes

signal shadow
main perch
#

the admins never actually get the users card details, so they don't have access to all the information they would need for a MOTO payment it looks like

#

we just show a list of cards that the user has attached to their account which shows info like last 4 digits etc

signal shadow
#

got it, I see, so it's not MOTO then.

main perch
#

I think I found whats causing it on our end. We removed in the PaymentIntent.confirm the param off_session=True. Bringing that back should fix our problems right? And it doesn't require using confirm=True etc right?

#

Sorry for all this but thank you both for all the help and for improving my knowledge of how Stripe works