#Caio2021
tough saffron
green river
Hey there
Have you given a read through https://stripe.com/docs/disputes/prevention/card-testing ?
That talks about the different methods we recommend to counter card testing
lavish rampart
Yes, I have gone over and we do have some implementation that are mentioned here. For example we use the stripe checkout script along with a google recaptcha v.3. However, what we are noticing is that the bad actor is manually going through the checkout process in order to get the token that is provided by stripe, he will then use this token over and over to automate the process.
A few weeks ago a couple of attempts made it into our "failed" transactions only becasue of the rules (block transaction below $10).
cyan dagger
Hi there 👋 taking over, as my colleague needs to step away
Give me a few minutes to get caught up.
Which token are you referring to?
lavish rampart
I believe its client_secret token
Let me double check
Yes, "Client_secret"
response on create intent call
cyan dagger
I see. Our knowledge is a bit limited when it comes to this particular method of card testing. You may consider reaching out to our support folks and asking to have your question escalated to a card testing specialist, as they might have a better answer.
That being said, you might be able to make your Client Secrets single-use by canceling the Payment Intent or Setup Intent once a failed payment is made
lavish rampart
ah yes, if we are able to make it single use, it would solve all our problems. AS the recaptcha works really well, its just that the tokens arnt single use so its very easy to bypass it if you manually do it the first time.
Where can I read or find more about this payment intent / setup intent, is this on the api side or on the dashboard.
lavish rampart
I am not sure if I understand how to appropriately use this call for my use case. If I use payment intent cancel, will this cancel the client token for future use. As we would then need to run this call after every requests as we would not know which requests is coming from an actual customer or a bad actor
cyan dagger
If a payment fails, you could then just create a new Payment/Setup Intent and have the customer try again. The reason you do this, is so that the bad actor would have to manually create a new one every time they try a payment.
I guess since you're using Checkout, that would probably break your current workflow though, right.
Hmmm....
Do you know specifically which requests are being made to create the Charge? Like, are they taking the client secret and creating a Payment Method first? Or are they doing something else?
I'd recommend looking at the logs in your Dashboard to answer the above questions: https://dashboard.stripe.com/logs
lavish rampart
They are first creating the paymant method and taking the token. to then reuse it in their script.
lavish rampart
I guess since you're using Checkout, that would probably break your current work...
correct, that would break the architecture we have in plce.
lavish rampart
If a payment fails, you could then just create a new Payment/Setup Intent and ha...
Right we do not want to force the customer to redo all of the checkout process to get a new token. This will create too muhc friction for our customres.
I can get in touch with your support fraud experts too
how can I get in contact with them.
cyan dagger
That makes sense. I mean, as long as the Radar rule(s) is/are working, then I don't know how else you might detect that a bad actor is making these calls.
Our support folks can escalate to a fraud specialist though, so hopefully they'll be able to shed some light: https://support.stripe.com/contact/email
lavish rampart
Thank you