#Dara-customer

1 messages · Page 1 of 1 (latest)

hushed vault
#

Hi, checking

elfin moon
#

Thanks

hushed vault
#

It looks normal to me. Seems you have logic on your backend somewhere to call this API

elfin moon
#

Yes, it's part of the payment process, one that you guys scrapped. First, create customer, then try to subscribe with authorization and all. But all the steps require emails to call backend server. So, I don't get it. Did you guys change any think in APIs?

#

The source says Stripe/v1 NodeBindings/8.160.0. I've never seen that before.

#

And the payment attached to the customer got picked up by the radar and under review.

hushed vault
#

I don't think that behavior changed. Sounds like you require emails to call backend, but inside backend you still have some code triggering the create Customer API without providing an email address.

#

Don't you use NodeJS?

#

How about this IP address? 35.203.245.114

#

Is it one of your server?

elfin moon
#

Let me check the IP address.

#

Yes, looks like our server. It's Google.

#

We use NodeJS

hushed vault
#

So yes it comes from your server. I would recommend checking your server logic where could trigger that call

elfin moon
#

I always create customer with email like so:
stripeCustomer = await stripe.customers.create({ email, metadata: { 'firebase_uid': userMetadata.userId } })

#

But i didnt reject if there is no email bc the email is part of the request body.

hushed vault
#

I see. but that request doesn't have metadata

#

Unfortunately we can't know how your server logic is working. We only can see from the log that there was request from your server. I would suggest investigate on the IP Address, the exact UTC time the unrecognized request was being sent

elfin moon
#

There's no point bc hackers use VPN, even normal people do nowadays.

#

Our site has been used for card testing for years now bc of flaws in the process of Stripe card elements.

#

And unfortunately, our boss like card elements bc it's personalized design.

#

Should I refund these payments? We have a lot.

#

They are likelyfrauds.

#

How would the exact UTC time the unrecognized request was being sent help in my investigation?

hushed vault
#

How does VPN matter to request from your server to Stripe? I am sorry to hear about card testing, but what flaw do you mean specifically?

#

For the UTC time, you can open the request in your Dashboard and hold over the time

#

This is an example

Screen_Shot_2022-08-08_at_11.03.54.png
elfin moon
#

Yes but it's happening all the time and as we speak.

#

I mean the IP address of the user from Stripe dashboard,

#

The flaw is that the field for entering the card, anybody can type or paste the frauded cards.

#

Is it possible they somehow bypass the email like by copying our PK_live Stripe key?

hushed vault
#

Eventually you will need to have some fields for your customer to type in. It's impossible just by frontend to detect fraud card. It requires backend and products like Stripe Radar that we built to help you fight card testing

elfin moon
#

Radar is not enough, still lots of payments went through... 😦

#

We use the default card element with the postal code required.

hushed vault
#

Is it possible they somehow bypass the email like by copying our PK_live Stripe key
It depends on how your server handing those requests. They can copy your PK live key yes, sending request to your server, but your server need to presume to not trust every incoming requests is from your own client

#

It's the same with any server-client auth protocol

elfin moon
#

Indeed, that needs to be enforced. I think you have an example for Stripe in NodeJS, right?

hushed vault
#

Yeah

elfin moon
#

Please send me the link.

#

Though on the dashboard, it says it's from our website.

hushed vault
#

Choose customer-payment-flow, server choose node

elfin moon
#

It's the webhook secret, but in this case, it's not from webhook.

hushed vault
#

I don't follow that. Why webhook here?

elfin moon
#

I couldnt find in the example except for using a webhook signing secret key

#

So what happens when the payment is under radar review? I wanna know if we should refund it first or wait until the review is over?

#

I'm gonna block this IP address 149.18.58.53.

#

I wish i can work with cops to nails those guys.

hushed vault
#

I also don't follow the under radar review part. Stripe Radar is a preset of rule that automatically apply to all Payments. You can set a radar rule blocking an IP I guess

#

I would recommend getting in touch with Support and they can provide better help tailored to your account, including card testing defend mechanism

#

Here is a public forum when we haven't authenticated you

elfin moon
#

Done that before, all they said it's to add Captcha...

#

And let radar do its job. SO no help.

#

I mean the review has to be done by us not Stripe right?

hushed vault
#

Yeah you will be the one to look at those Insight part of each Payment

#

pi_3LU9z14ugWOxILKl1SjCe6yI

#

Placed in review by Radar due to an elevated risk of fraud

#

I see Radar did output some insights

elfin moon
#

ok got it, I'll refund those payments and fail the function if no email is provided.

#

oh thanks for the link

hushed vault
#

yeah there are some suggestions downside of the page. PTAL!

elfin moon
#

PTAL?

hushed vault
#

PTAL = Please Take A Look. sorry
Yes I see IP blocking is not so effective. Let's try other suggestions as well

elfin moon
#

We are using the 3rd option whhc is card elements with customer signals such as email and postal code. Name would help?

#

Ideally, I want to change to checkout but my boss says it doesnt justify increase in sales...

#

with the cost spend in updating payment process

#

What would be a good rate limit to apply for limiting the number of new customers that can be created by a single IP address in one day. 3 new customers a day per IP?

#

Would that be under rules or list?

hushed vault
#

name + email + billing address as suggested, also CAPTCHA/Login session/rate limit/Radar customer rules

#

Those are the tool to help you fighting

#

And rate limit of creating new Customer would be your own logic, not radar

#

How many is good really depends on your business 🙂 3 sounds okay-ish to me

elfin moon
#

yeah i wanna add the rate limit now

#

3 i okish meaning i should increase or reduce?

#

i really like the captcha after the 1st payment is done.

#

login session is what i reommanded but denied by the business logic of my boss.

hushed vault
#

Personally I think 3 is reasonable, but I can't say since I don't know how a legit customer in your system looks like.

elfin moon
#

Would stripe tried to match name of the card with the name entered? Wouldnt the hackers have the name in their list?

#

We sometimes do have teams.

hushed vault
#

I guess you need to have a conversation to your boss or your company risk team. Fighting card testing should be a high priority to any company if they want to continue using payment processor

elfin moon
#

Actually we do have a lot of teams and sometimes big teams.

hushed vault
#

Any Payment processor, not only Stripe, will stop working with a company if it can't defend fraud

elfin moon
#

Trust me i tried. It's not high priority to him.

hushed vault
#

We are bound to the card networks too and a lot of obligation/financial law in countries

#

You would need to explain/escalate to your company management team about the priorities thing

elfin moon
#

There is only 1 person bc we are a start up and small team.

#

But i'll try to apply some of those.

#

Let me try to add the rate limit.

#

it's under custom rule right?

hushed vault
#

Customer creation rate limit would be your own custom logic not related to Stripe radar

elfin moon
hushed vault
#

No

#

an effective deterrent might be to limit the number of new customers that can be created by a single IP address in one day

#

This should be a custom implementation on your server before calling the Customer creation API

elfin moon
#

If from front end, we don't track IP address from client side, I dont know if it's legal?

#

I'll do this then. Block if :declined_charges_per_ip_address_daily: > 3

hushed vault
#

Oh that looks good but first they needs to be declined charges

elfin moon
#

This is likely a bad rule. Based on recent history, it would have blocked 119 good payments for every blocked case of fraud.

hushed vault
#

But yeah, I think it could be a good attempt, even better combining with your own rate limit implementation

#

Maybe increase a little bit?

elfin moon
#

it's fine for now. Even a legitimate person, we should give a feedback after 3 attemps.

#

failed

#

I would have to figure a way to do the rate limit. And activating captcha after 1st payment is a success. We'll see

#

I wish Stripe does only allow if the email is legitimate. block is email is bounced.

#

WOuld you know how to capture an IP address for the rate limit rule to add to my function?

hushed vault
#

Are you referring to the custom logic?

elfin moon
#

well, the one not under radar as you said that would be in my backend logic instead.

#

I wish there were examples in those suggestions.

hushed vault
#

It's a common logic, really. It's like any request comes to your server and you takes its IP address

elfin moon
#

to be honest i tried that before, but we had to rely on third party api that we dont know if it's trust worythy...

#

but thanks anyways. if i can use Stripe api for that, that'd help.

elfin moon
#

Thank you for all of your help. It's late where I am now.

hushed vault
#

Good luck and I really mean it 🙂

#

It's more of common way to implement rate limit