#Pipe
compact yew
snow blade
How can I help?
undone kernel
Thank you roadrunner... I will try to explain
In our site busk.co, we have a list of "buskers" (people who do street acts), and people can "tip" them using Stripe.
About 1 year ago we had problems related with "card bombing" (people trying to use a lot of cards many times a day), so we added some restrictions and added a recaptcha verification, and the problem was solved.
Now, recently, we had a lot of fraudulent transactions coming from the same card and trying to tip the same busker.
The problem is every transaction was between 100 and 150 USD (not a normal tip value, but a possible value)...
We need to refund a lot otf transactions (many of them were done in 2-3 days)... They generate more than 20.000 USD in "tips"
We blocked that card and the problem was solved...
But... how we can protect against it?
We have currently a form with only card info fields.
Our CEO is not a so technical guy.
He talked with someone in stripe and they suggest to add first name, last name and all the fields of the "billing_details" field...
Do you think that could be useful? Are those fields also validated by stripe? Or are those fields only "informative"?
Can those fields help to prevent fraudulent transactions?
What do you think?
Do you have another suggestion for us so we can prevent that in the future?
snow blade
Thanks for the context!
We have currently a form with only card info fields.
Do the tippers have to log in before they can access the card form? You could implement some login flow that a tipper has to complete first
undone kernel
No... because the tip can be anonymous and we need the tips to be as fast as possible.
Thats why I'm asking if those fields could be useful, because I don't think that if someone is trying to tip 5 USD to a busker, he will be happy filling a form with 10 fields
Also... We are not delivering any product... so why we need the first name and billing address of the tipper...
I don't see any reason for that
snow blade
Got it
undone kernel
We have a login on our site, but its optional... in a busker festival I don't want to create an "account" in a site just to send a 5USD tip
snow blade
We outline some recommendations here. It looks like you've tried a few of them, and others add too much friction to your current flow (e.g. logins) - https://stripe.com/docs/disputes/prevention/card-testing
If all activity was coming from a single IP or a range of IPs, you could use some custom Radar rules to block those charges - https://stripe.com/docs/disputes/prevention/card-testing#radar
undone kernel
We are also using CSRF tokens.
We can also do some type of rate limits...
But... is there a way to identify a card between different payments? (as far as I know, a different token is issued for each of the payments) and we only have access to the last 4 digits... Is there any unique identifier for them?
So, for example, if there are more than 5 tips from the same card in a single day we can block other tips with the same card
undone kernel
If all activity was coming from a single IP or a range of IPs, you could use som...
Thank you, I will check this
steep urchin
Hi there 👋 each card has a fingerprint, so you could check that for duplicates: https://stripe.com/docs/api/cards/object#card_object-fingerprint
undone kernel
Oh! thank you... that will be useful too!
So... asking for name and billing_details will have no effect?
steep urchin
Those are useful for differentiating the Customer that was using the Card, but ultimately won't help you differentiate the Card by its payments
undone kernel
I mean, Stripe do not use those field values to "check" whether a payment could be "risk" or "fraudulent"?
steep urchin
I'm sure that it helps dial in the Radar score, but it's not really a good solution for preventing card testing
undone kernel
Ok...
Thank you so much @steep urchin and @snow blade for your help.
Have a nice day!