#nickdnk-3ds
1 messages ยท Page 1 of 1 (latest)
@civic raft radar is the easier, you can write rules to declines any card that didn't go through 3DS
Yeah I can't do that for Standard Connected accounts though
otherwise, you have to write custom code for this, look at the 3ds outcome and decide based on that whether to refund (or delay capture to not pay a fee)
yea that would be an option
My take: this is an engineer's position. I have the same. You want to minimize fraud as an engineer by blocking everything not doing 3DS
but the conversion loss will be bad for you and all your users will be up in arms :p
it's really tricky, if you block too much, people complain, if you don't block enough, they complain, there's no good solution that fits it all
so like Radar, make it an option for your user to decide their "risk appetite"
or teach them Radar
Well, all cards used should support 3ds, so I don't really understand why it doesn't get triggered
It's really weird
It's even for significant amounts like several hundred dollars
I get the point of conversion vs risk, but it really should just work and I don't know why it doesn't
I talked to Pompey about this a couple of days ago and they suggested I try some different methods of confirmation (manual vs automatic and all that) to rule out if it's Stripe or the bank not doing what it's supposed to with request_three_d_secure
If I did enable 3ds via Radar, what would the error handling look like?
I mean what error would it throw if 3ds was not supported
I'm sorry, you have been coming with numerous questions about 3DS over multiple months, it's hard to keep track of them all
We're happy to help with code questions but if you have specific transactions not doing 3DS when they should, the support team is a better place to get consistent help with all the context in one place
but if you have an example I can check
Sure, I'm just trying to rule out if this is code that's not doing what it's supposed to or the bank not doing what it's supposed to
pi_3JaiguIXmFfWZ4Ev2TZg0O55 probably should have been 3ds and I'm pretty sure (hard to be sure) the card should support it.
Also has a authentication_required for some reason but still succeeds
And for what it's worth, the reason I mainly ask here is because the quality of support tends to be significantly higher than via email/chat support. If there are things you cannot help with, then fair enough, I will e-mail support.
No?
ah wait no that one is ApplePay?
Might be, hold on
apple_pay: {},
dynamic_last4: "xxxx",
type: "apple_pay"
}```
It says it's a Lunar Way card, yea
(Danish digital-only bank)
Well that explains that one at least
Point of feedback; having Apple pay (or not apple pay) on the dash for a PI would be helpful
on there that is
At least in this case this would have avoided a few questions on my part
yeah makes sense. When you start going deep in debugging this it's hard
there's another "gotcha" where you can try to do 3DS and if the bank is down/broken, we move forward anyways without 3DS"
mostly we optimize for conversions (because that's what almost all users want)
I also read that in those cases there's still a liability shift because it's basically the banks fault
somewhere
hence why I recommend looking at the outcome of 3DS in payment_method_details[card][three_d_secure] which has all the info to decide "did this really do 3DS" and then decide what to do
and it's not always liability shift, it's more subtle than that (and I won't get into it becuase it's beyond code and I only know 70% of this)
Cool. I think most of the "problems" (which then aren't really problems) stem from there being no obvious distinction between regular non-3ds payments and Apple Pay on the dash
Perhaps just drop in an Apple logo somewhere where you would otherwise have the padlock or something, since these are mutually exclusive (as far as I understand)
Not sure if this kind of iconography would conflict with other payment methods, but you get my point. Just any indicator.
yeah though won't happen any time soon sadly
I have asked a few times, but in the grand list of things to do.... ๐ฆ
I understand. Seems like a pretty simple change though since it's already in the dash info, just buried in JSON. Well, +1 from me anyway. Thanks for your help as always and I apologize if I ask too many questions.
ah no no no please continue asking as many questions as you need
you give great feedback on top of it
what I meant is that for some shapes of questions, you talk to multiple of us over time and we don't really keep state on things yet and so for long running 3DS issues (Which you clearly encounter multiple complex ones) making sure you have an ongoing support thread is better.
But we're always happy to spot check specific objects for you to align because that's easy for us and to offer alternatives and such
Okay, I interpreted the "sorry, but" as "dude, really?" and not "i am sorry but I can't find required context because of multiple threads".
It would be a good addition to have access to your own threads if in any way possible with Discord.
like archived threads
yeah my bad, sometimes I'm a bit too direct, I value your feedback and always am happy when I see you report stuff (though yes I shiver a bit as I am worried you found a really bad bug)
you can search all your messages in Discord, it's just a bit manual/annoying
I know that feeling from my own users. The "best" of them are also the most vigilant.
Okay, I'll see if I can use that going forward
overall, while we'd love to keep state of ongoing issues, it's too much volume unfortunately for one brain to remember ๐ฆ
My advice with those shapes: always give a clear example id for all inquiries that way we can quickly zoom in and align on it ๐
Haha, yeah, of course
but do not leave or anything, keep reporting. I'm sure at some point I'll be able to bribe someone to add the Apple Pay logo for those transactions
Yeah I try to always supply object IDs with my questions
going to try that right now since I had some luck yesterday to get a change through in exchange for chocolate :p
Haha. Good luck. I think it's a pretty valuable addition compared to its complexity
agreed