Derek Lance

[limber tapir]

Hello! Let me take a look, hang on...

Sorry for the delay, things got a bit busy.

Looks like they supplied a country which seems to have satisfied the billing address collection required setting. That does seem less than ideal though...

I'll flag this internally as something to investigate and improve upon.

[lucid bane]

@limber tapir but on the live site, if I go to the checkout page and try to only enter the country "Philippines", it will not let me subscribe

i don't understand how they are bypassing it

[limber tapir]

They're interacting with the underlying API directly, they're not using the web page. It looks like we need to adjust the underlying validation to account for this.

[lucid bane]

@limber tapir how was it determined that they are using the API directly?

and if they are using our API directly, they should still get a checkout session that requires a billing address, shouldn't they?

[limber tapir]

I'm looking at the request logs and it's clear these are normal Checkout requests coming from the Checkout page in a browser.

They're using Stripe's API direclty, not yours.

Sorry I wasn't clear about that. 😅

[lucid bane]

ah

but how do you know that?

not questioning it but just curious on how i would check that myuself

[limber tapir]

The User-Agent header is blank, which is the biggest indicator.

[lucid bane]

@limber tapir is there a way for me to check that as well? when i check the logs in the dashboard for this checkout session, it only shows me the body, but not the headers

[limber tapir]

In the Dashboard request logs we show the user agent as "Source".

Have a look here, for example: https://dashboard.stripe.com/logs/iar_f5k4vNzb8FcRtt

And here: https://dashboard.stripe.com/logs/req_aJ8lAyODCi7NTM

[lucid bane]

@limber tapir but if we take a look at this request here https://dashboard.stripe.com/logs/req_OLt7sTHvujlBll, we see a checkout session being created with the flag billing_address_collection: 'required'. and then the subsequent payment here (which is connected to the checkout session just created) here https://dashboard.stripe.com/logs/req_f5k4vNzb8FcRtt still has null address fields. to me that seems like it shouldn't be possible, Stripe's API should block the 2nd request as it does not have the info specified in the related checkout session

[limber tapir]

Yep, I agree. That's what I'm flagging internally for us to investigate and improve.

[lucid bane]

so to my understanding, the second request is a public API which does not require a secret key. so this does NOT mean our secret key is exposed right? @limber tapir

[limber tapir]

Correct. I'm not seeing evidence of your secret key being leaked when looking at this Checkout Session.

[lucid bane]

I'm a bit disappointed that Stripe doesn't have better validation on this. is there anything else I can do to prevent these card testers other than rate limiting and CAPTCHAs? we are working on those 2 solutions right now.

also it seems like Stripe's risk analysis is a bit my forgiving than I would like, see the screenshot where this payment from a card tester was approved with a very low risk score, and yet there are a lot of red flags here like "Authorization rate for transactions associated with this email (all time)" , "Number of declined cards previously associated with this email (last 7 days)" etc.

we are getting very worried about these card testing transactions eventually causing us an avalanche of disputes which will potentially lead to fees and even getting blocked by credit card companies
@limber tapir

[limber tapir]

A lot of what you're saying is beyond the scope of what we can help with here, unfortunately. I recommend you write in to support with these concerns: https://support.stripe.com/contact/email

Setting up captcha and rate limits on your end should help, and I will be flagging this internally as something to address on our end as well.

[lucid bane]

sounds good, thanks for your help

[lucid bane]

hi @indigo bronze, as discussed above, the card testers are directly calling the POST /v1/payment_pages API as evidenced by there being no "user_agent" in the request. in doing so, they can bypass our checkout session parameter billing_address_collection: 'required'. however, we can see in the logs here https://dashboard.stripe.com/logs/req_70gGZNX46PrLDV a (presumed) legitimate transaction where there IS a "user_agent", meaning they likely did not bypass the billing_address_collection rule. however, we can see in the logs that they still did not provide a complete billing address:

 "address": {
            "city": null,
            "country": "US",
            "line1": null,
            "line2": null,
            "postal_code": "29301",
            "state": null
          },

so, how were they able to not provide a city, address_line_1, state, etc? I would like to set up a Radar rule to block the card tester but the rule seems to be including these legitimate transactions because of the missing address fields

[indigo bronze]

Good question. Looking in to what happeend with that transaction and will get back to you.

[indigo bronze]

Hey apologies for the delay. I think our engineering teams need to take a deeper look in to this. Can you write in to our support team at https://support.stripe.com/?contact=true they should be able to escalate this properly