#bachir2921
maiden sluiceBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- bachir2921, 4 days ago, 4 messages
crimson sleet
There are limited things possible via client_secret and Publishable Key on client, so literally not much user can do unexpectedly to you.
They can only confirm the PI, which means to pay for you
They can't directly call Stripe API
buoyant field
They can also change the payment method - let's say a card - and confirm different cards on the same payment intent, right ?
They can't directly call Stripe API
How is that prevented from Stripe side ? Could that work if they use the Stripe JS library ? Which they presumably did here https://dashboard.stripe.com/logs/req_gXL8vQzrWzsSew
crimson sleet
They can confirm a different card yes, but only on your account. Basically everything on client-side is reproducable on its surface information, but should be harmless
buoyant field
If they can confirm a different card, this means they can run card testing like on this payment https://dashboard.stripe.com/payments/pi_3MbHQVH5tvrIOuhg1c85Yw84 ?
crimson sleet
Card Testing is a different topic and we have suggestions here for fight back: https://stripe.com/docs/disputes/prevention/card-testing
maiden sluiceBOT
buoyant field
Yes we already implemented most of that, but specifically the only use case that is still preventing us from confirming payments on the frontend is the one I describe in this thread
I feel it's not a different topic if you can :
- Confirm a payment intent as many times as you want when you have access to the client secret and the public key, bypassing our integration (hence our card testing mitigation tools)
- Change the card you confirm with on every request
The other issue of that is that at some point, they managed to hit our Stripe rate limit, which prevented other legitimate requests to be handled by Stripe.
ancient mural
Sorry, not understand the concern or ask here
buoyant field
No problem, I'll rephrase
ancient mural
@buoyant field Are you still there?
buoyant field
Hi, yes sorry
So basically it all went from a user that used a client secret of a payment intent https://dashboard.stripe.com/payments/pi_3MbHQVH5tvrIOuhg1c85Yw84 and hit Stripe API directly (using the JS library) to confirm the same payment using different cards.
We have mitigation processes for card testing on our server, but these confirmations were done outside of our server. This had two consequences :
-> card testing
-> Hit our Stripe API rate limit, which prevented other legitimate queries to go through.
My question : how can we make sure this doesn't happen ?
ancient mural
Hmm, there's no blanket prevention for card testing unfortuntalely really. Intents are confirmable client-side with a secret and your publishable key, which is fine to be public (and will be in your source code) so inherently there is risk that bad actors can capitalise on
Radar should automatically be working to prevent abuses like this, but you can implement stricter rules to block specific patterns you're seeing in your integration
buoyant field
Okey I see, so for this use case only the stripe radar can help ?
We did implement confirmation on the server only, but we want to use the client confirmation as it automatically handles all the flows such as 3DS / ACH etc...
ancient mural
Okey I see, so for this use case only the stripe radar can help ?
There's general recommendations here: https://stripe.com/docs/disputes/prevention/card-testing
buoyant field
For the Stripe Radar rule of cvc check, do you know why it didn't block this payment https://dashboard.stripe.com/logs/req_1uWkB1SI7XFv5f ? You can see the cvc field is an empty string, yet the payment was successfully confirmed by Stripe
ancient mural
Taking a look
FWIW, I can see we sent an early fraud warning event for this payment. Are you handling those?
ancient mural
For the Stripe Radar rule of cvc check, do you know why it didn't block this pay...
Which rule specifically? I only see a rule that blocks if CVC check fails
buoyant field
FWIW, I can see we sent an early fraud warning event for this payment. Are you h...
at that time i dont think so
ancient mural
id like to enforve cvc check, how can it be done?
I think we recently made a chance that requires CVC for all confirmations with pk_xxx keys now (this payment pre-dates that charge)
I think you just need to adjust your rule to check for the not_provided value: https://stripe.com/docs/radar/rules/supported-attributes#issuer-checks
Block if :cvc_check: in ('fail', 'not_provided')
https://stripe.com/docs/radar/rules/reference#post-authorization-attributes
buoyant field
Ok thanks ! that might do the work. But I guess we'll have to pay for the Stripe radar in order to update the default rules, right ?
ancient mural
Yeah not sure how that works
buoyant field
ok no worries, thanks a lot for your help
ancient mural
np