#_shadower
1 messages · Page 1 of 1 (latest)
hello
i had someone else in my ticket before
snufkin stripe
Ah, so you want to trigger 3DS more often to ensure this doesn't happen?
We have a couple ways to do that, both of which are covered in this doc https://stripe.com/docs/payments/3d-secure
One is to use Radar Rules you create in the Stripe Dashboard: https://stripe.com/docs/payments/3d-secure#three-ds-radar
The other way is to request 3DS when you create/confirm Payment or Setup intents: https://stripe.com/docs/payments/3d-secure#manual-three-ds
he send me these
but id like to know more about the top one
The top one meaning https://stripe.com/docs/payments/3d-secure ?
Did you have specific questions?
yeah how does it exactly work
cus ive had issues before with people saying they didnt authorise thepayment
You're talking about the radar rules approach right?
about this part
disputed payments and liability shift
Let's back up - what are you treally trying to ask here? Is there a specific scenario/payment that came through that didn't have like you expected?
Liability shift is a really complicated topic, so it's better to approach it from a specific example and explain what's happening
ive had issues in the past where costumers said they didnt authoriese the purchase to their bank and asked for a refund
however i dont want this issue to occur again so was thinking about adding more 3ds rules to ensure this doesnt happen
Were these recurring payments that happened when they were off-session?
no it was a 1 time payment
no subscribtion of recurring payment
Gotcha - so you're just trying to make sure you ALWAYS authenticate when your customer is on-session, right?
well i just want no issues with unauthorised payments
and i dont want to be the one responsible if it does happen
since i deliver an online product instantly
Yeah, but if you want to have no issues at all with unauthorized payments then you'll likely want liability shift, which would need you to run 3DS on the on-session charges
yeah
will it exclude a lot of peoples card tho
but i indeed do want it thats why i made this
Yeah that's the tradeoff you'd have to make - requiring 3DS on ALL your on-session transactions makes it likely that some folks will choose not to continue with payment
well some i dont mind
but this
Where is that screenshot from?
Do you have the specific link?
its in the same file
as the one i send earlier
Ah right at the top
So that note would only be relevant if you were using something old (like the Charges API)
If you're using newer things like PaymentIntents, then this wouldn't be a concern
ah alright
can you help with the other thing now
the liability thing
Your first step would be to make sure you're triggering 3DS in all the scenarios you want - so do you want to be requesting 3DS through the API or through Radar (this option will require radar for fraud teams)
No, that won't work - you need a custom 3DS rule, not the built-in ones we provide
can you give it to me
It's right there in the docs - https://stripe.com/docs/payments/3d-secure#custom-rules-for-3d-secure-and-liability-shift
You'll want the last one in the table and change it to Request if instead of Block
Request if ::foo:: = ‘bar’ and not :is_3d_secure: and :digital_wallet: != ‘apple_pay’ and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)
and where to put in in
You'd put those rules in through the dashboard https://dashboard.stripe.com/test/settings/radar/rules?startDate=2023-03-17&endDate=2023-09-14
If you need more specific help with getting radar rules configured you should talk to support (https://support.stripe.com/contact)
what settings do you recommend to have on
I already gave the recommended radar rule earlier -
Request if ::foo:: = ‘bar’ and not :is_3d_secure: and :digital_wallet: != ‘apple_pay’ and not (:digital_wallet: = 'android_pay' and :has_cryptogram:)
because this one sounds like 80% off people aint gonna go through with payment
yeah but any other not so extreme you reommend?
because i dont know what the verifying process is like
cus if its a pain in the ass no one will go through with it
At this point I'd really recommend talking to support (https://support.stripe.com/contact) - I can give general help on which radar rules may be helpful, but if you want more specific support on what radar rules would work best for you\
If I were you, I'd just request 3DS through the API and then just use radar for blocking transactions
i have 3ds on
do you recommend having allt hese enabled?
We don't have a specific recommendation for all those settings - it really depends on what your integration does because they all come with tradeoffs
And again, I'd strongly recommend talking to support (https://support.stripe.com/contact) about this - they know way more about fraud protection than we do
Find help and support for Stripe. Our support site provides answers on all types of situations, including account information, charges and refunds, and subscriptions information. Get your questions answered and find international support for Stripe.
they dont react xD
I'm sorry, but they're really the better place to get more personalized help with getting your radar rules set up in a way that works for you
can you explain atleast to me what 3ds does
llike how does it make them verify or smth
Recommend reading https://stripe.com/docs/payments/3d-secure
this doesnt work btw
it says couldn't parse expression
Hello. Recommend you talk to our support team. We aren't that familiar at all with Radar rules in here
ive been waiting an hour for support atm
when it was estimated 13 min
Sorry to hear that, but we really just don't know enough about what you're asking about to help
You could email in
email have been waiting 5 days
send multiple follow up emails
this is a dev issue tho
Yes the issue is we aren't familiar with how to write custom Radar rules