What Stripe Radar rules do you use to reduce card testing?

TheGreatOakley

Hey,

Noticed surge of attacks with stole credit cards after New Year, so I had to modify and make Stripe Radar rules more strict. I understand that rules will differ on different provider/market/attacks, but it still would be nice to see what kind of rules everyone is using and what could be improved or tips in general. I use currently next set:

Block if :card_country: IN ('br', 'BR') 
Block if :total_charges_per_ip_address_hourly: > 5 
Block if :blocked_charges_per_ip_address_hourly: > 1 
Block if CVC verification fails

Also fucking hate Stripe for not blocking carders that tried to pay like from 5 different cards and then they are "ah alright sixth card worked, this is totally normal".

Also big fuck you to all non EU banks that cannot fucking implement basic security and safety for their customers. In my case 99% of payments with stolen cards are coming from non-EU countries and US is the leading one.

Rant over. Regards.

nanankcornering

stupid question: have you tried forcing 3DS for all transactions?

emgh

@TheGreatOakley said: Also big fuck you to all non EU banks that cannot fucking implement basic security and safety for their customers. In my case 99% of payments with stolen cards are coming from non-EU countries and US is the leading one.

I've heard banks in the US use SMS for 2fa, they really don't care at this point

nanankcornering

@emgh said: I've heard banks in the US use SMS for 2fa, they really don't care at this point

unfortunately other countries are using SMS for 2FA/3DS too. however, this (reduces) risk of unauthorized transactions.

card details can be stolen but sim swapping.. less chance of it happening.

TheGreatOakley

@nanankcornering said:
stupid question: have you tried forcing 3DS for all transactions?

Yes, but turned it off eventually. For example according to the Stripe stats that would only block one payment (and it was already blocked by Stripe without 3DS). But would force 3DS to over 100 payments that could potentially reduce the conversation rates. So not really worth at the moment.

Also from my understanding 3DS is mainly used in Europe.

@emgh said:
I've heard banks in the US use SMS for 2fa, they really don't care at this point

I have a strong feeling that they don't even use SMS.

nanankcornering

@TheGreatOakley said: Also from my understanding 3DS is mainly used in Europe.

you're talking about SCA, which is a european law thing. 3DS is a standard

as far as I know, all banks worldwide under mastercard/visa are mandated to implement 3DS nowadays. each with their own way of verifying (SMS/in app/PIN codes, etc)

it's beneficial for both you & banks, as you're not liable for any fraud transactions, since customers authenticated the payment.

in stripe radar, you could check if card is 3DS supported. if yes, force them to verify. if not, then you could skip any checks related to it.

nanankcornering

you mentioned brazil in stripe radar rules, it is supported for 3DS now.

https://docs.adyen.com/online-payments/3d-secure-for-regulation-compliance/#visaliabilityshiftrules

https://docs.adyen.com/online-payments/3d-secure-for-regulation-compliance/#mastercardliabilityshiftrules

tentor

We have 3DS enabled for all cards that support it and no issues happened since then

TheGreatOakley

@nanankcornering said:

@TheGreatOakley said: Also from my understanding 3DS is mainly used in Europe.

you're talking about SCA, which is a european law thing. 3DS is a standard

as far as I know, all banks worldwide under mastercard/visa are mandated to implement 3DS nowadays. each with their own way of verifying (SMS/in app/PIN codes, etc)

it's beneficial for both you & banks, as you're not liable for any fraud transactions, since customers authenticated the payment.

in stripe radar, you could check if card is 3DS supported. if yes, force them to verify. if not, then you could skip any checks related to it.

Like I told before there is small amount of payments that support 3DS (about 100 last month) in our case. And only one was fradulent and got blocked by radar rules. There is no need to enable it at this rate, because most of the banks don't support/ask for it.

@nanankcornering said: you mentioned brazil in stripe radar rules, it is supported for 3DS now.

The fact that it supports 3DS, does not mean that X bank have it. The case with Brazil was that we received around +100 fraudulent payments from the same bank that did zero verification. They just spammed and tried bunch of cards.

@tentor said: We have 3DS enabled for all cards that support it and no issues happened since then

Luckily you, we been on carders radar since day one. I think it all depends on the size, volume, price and product you sell. Hopefully it will stay like that for you.

MannDude

Be careful. Stripe sort of sucks and I hate seeing that they haven't fixed this issue yet. We had the exact same issue and luckily I caught it early, before it became a big problem, but it still resulted in our account getting closed by Stripe. From our thread here: https://lowendtalk.com/discussion/comment/4259605/#Comment_4259605

We used to do quite a bit of business via Stripe, at least in terms of percent of our sales at one point.

No issues, things were fine.

I'm OCD and review all new orders / transactions. One day I notice a bunch of $10~ transactions that were "add funds" invoices that were being paid for over the course of a couple hours, spread out across a few accounts. From the list view of transactions in WHMCS, you get an idea of what normal activity is and seeing a long list of these certainly stood out. I look into it more, and one thing these accounts all had in common was like 10 cards linked to them. Admins can see the last 4 digits in your WHMCS profile.

So I dig a bit deeper via the Stripe portal, and see where (for example) invoice #98765 failed to be paid for by card ending in 1234, card 3456 and card 5678 but the user was successful in paying that $10 add funds invoice with card 6789. This pattern repeated until they had successfully spent about $800 across many different cards, with even more attempts from other cards failing.

So, naturally, there was no doubt that this was fraudulent activity so I terminate the suspect accounts and spent the next hour or two manually refunding about 80 individual transactions back to their original source.

I thought I was being good. I thought I was being proactive, honest, and doing the right thing. Stripe's Radar's default settings failed to catch this. Our own custom rules failed to catch this. In my opinion, the activity should have been easy to detect as suspicious and stopped even without special rules or Radar subscription, seems to me that if a customer tries to pay for an item and keeps trying cards until one works that, hey, that's sort of a red flag, y'know?

What did Stripe do? Did they pat us on the back and say, "Good job!" or "Thanks for catching this, we're updating how we detect such behavior"?

No. They closed our account because we processed too many refunds in such a short time... LOL.

In my mind, it was either refund them now as I caught them when the transactions were literally only a few hours old or get hit with massive chargebacks a month or so from now.

Anyway, that's my rant about Stripe.

Regardless of Radar rules, you'd think any processor would detect multiple attempts from different cards to pay a single invoice as a red flag. In our case, we observed exactly what OP is talking about. Someone generates a small invoice for $10. They try with several cards until one works. Generate a new invoice, do the same. How Stripe doesn't auto-flag this as fraud or for additional review is beyond me.

TheGreatOakley

@MannDude said: Regardless of Radar rules, you'd think any processor would detect multiple attempts from different cards to pay a single invoice as a red flag. In our case, we observed exactly what OP is talking about. Someone generates a small invoice for $10. They try with several cards until one works. Generate a new invoice, do the same. How Stripe doesn't auto-flag this as fraud or for additional review is beyond me.

Yeah, and funniest thing is that we have to pay extra for Radar to unlock quite basic functions.

MannDude

@TheGreatOakley said:

@MannDude said: Regardless of Radar rules, you'd think any processor would detect multiple attempts from different cards to pay a single invoice as a red flag. In our case, we observed exactly what OP is talking about. Someone generates a small invoice for $10. They try with several cards until one works. Generate a new invoice, do the same. How Stripe doesn't auto-flag this as fraud or for additional review is beyond me.

Yeah, and funniest thing is that we have to pay extra for Radar to unlock quite basic functions.

Yup. It is nice to be able to create custom rules. We had an issue with Japan once so we just straight up put the entire country in time-out via Stripe, just wouldn't accept any payment from them. That level of flexibility is nice. But it's also a bit shocking that basic common sense stuff like a single IP trying to pay a small invoice with 5 or 6 different cards before one works, and then repeating this process with a new invoice isn't an automatic red flag in their system.

10thHouse

I've never had to use stripe, and thank goodness for that (based on this thread).

Obelous

@MannDude said: and spent the next hour or two manually refunding about 80 individual transactions back to their original source.

Now imagine 3500+ transactions

naphtha

all of them
also listen to stripe suspected pre-fraud notifications, refund the card, contact the user and if they come up with a good explaination let them pay again using a different method, if not ban them

yoursunny

@emgh said:
I've heard banks in the US use SMS for 2fa

For online banking login, I can choose between SMS or voice call or email.
Some banks only support SMS.
Some banks only support email.

For transaction verification, most transactions are approved right away.
If the issuer is suspicious, the transaction is declined right away, and then I get both an SMS and an email.
I need to either reply "1" to the SMS or click "approve" in the email, typically no login required.
Then I need to ask the merchant run the transaction again, and it will be approved as long as it's same merchant and same amount.

@nanankcornering said:
card details can be stolen but sim swapping.. less chance of it happening.

Force Apple Pay only.
iPhone stolen and finger chopped off, less change than SIM swap.

Neoon

I fucking hate stripe radar, its a pain the arse.
I usually pay my VPS stuff with a single virtual card, but since stripe radar popped up, I have too use 2 or more virtual cards.

Nobody can explain me why, it just ends up to be more work for me.
Revolut does provide a bunch, so not really an issue but annoying as fuck.

TheGreatOakley

@Obelous said:

@MannDude said: and spent the next hour or two manually refunding about 80 individual transactions back to their original source.

Now imagine 3500+ transactions

Good read.

@naphtha said: also listen to stripe suspected pre-fraud notifications, refund the card, contact the user and if they come up with a good explaination let them pay again using a different method, if not ban them

Yeah once decided that the pre-fraud email was no wrong and that was a mistake. I think 99% of time it's just better instantly refund the payment, if you that email.

@10thHouse said:
I've never had to use stripe, and thank goodness for that (based on this thread).

What are you using? I think all payment processors have the same issues.