#JulesR - Fraud
slow lotus
For Fraudulent test card: 4000000000000259 With default account settings, charge succeeds, only to be disputed as fraudulent. This type of dispute is protected after 3D Secure authentication. -- the test order went through for me. We use Connect express. how do i know if 3D secure is on
is it a setting i turn on or off
rich vortex
Yep, you can manage that here: https://dashboard.stripe.com/test/settings/radar/rules
slow lotus
cool, but for py_1Kq1xPPGVGxmVWr0KHN8fLsd it was using fraud card that was covered by 3D but i don't see a fee
rich vortex
The Payment Intent associated with the Transfer that created that Charge was set to off_session, so it was not possible to run 3D Secure.
slow lotus
ok so dev needs to be able to turn that on for any client that wants it, then it would show it as fraud ?
where is api to set that pls
rich vortex
That's not exactly how it works. You're making an off-session payment, so the customer is not around to provide 3D Secure authentication.
At a higher level what are you trying to build?
slow lotus
this is using our POS, for manual card checkout - so i entered that card on checkout and it went through
rich vortex
3D Secure does not apply to point-of-sale transactions where the customer is physically present.
3D Secure is only for online payments.
slow lotus
our pos is online, cloud
web based
i can't try card as an ecom order and see
but I am confused, do you think that our system is already set up to check for 3-D already, or it needs to be turned on
or it's always on but not for this order type?
rich vortex
To clarify, you're building something so people can take in-person payments with the customer literally standing right in front of them?
slow lotus
Yes, using terminal, but on checkout there is option to manually enter a credit card too - ie, if at offsite event and don't have terminal to swipe
rich vortex
Stripe does not support in-person payments without Terminal. I think you're running into issues caused by using Stripe for a use case it wasn't designed for.
slow lotus
ok so try as ecom order then
rich vortex
You should absolutely not be prompting people for 3D Secure in person on a device that does not belong to them, for example.
slow lotus
let me check if we are
rich vortex
If you want people who are physically present to pay for something and you don't want to use Terminal you should give them a URL to type in or a QR code to scan that sends them to a payment page they can use on their own device.
slow lotus
Ok, where is api on that please, to use QR code?
This is how we have currently
it's like this if not hit Card Manual
rich vortex
We don't have an API for QR codes, you would need to handle that on your end.
slow lotus
we did this becuase in our current implementation with WorldPay and open edge, which we are retiring, sometimes the terminal goes down and cannot connect, so this gave away to checkout when terminal went rogue
rich vortex
Keying in card details yourself opens you up to all kinds of PCI compliance burdens. Are you fully PCI compliant for handling raw card data like that yourself?
rich vortex
If you, as in the person running the POS device, are typing in card details manually you're opening yourself up to a lot of PCI compliance burdens.
slow lotus
Both are embedded solutions so cards are not hitting our server
rich vortex
We do not recommend you fall back to typing in card numbers when using Stripe Terminal unless you are fully PCI compliant to do so specifically.
It doesn't matter that the cards aren't hitting your server, the person at the POS device is handling the raw card details.
Please read through that article and let me know how you want to proceed.