[neurostimulant]

But OP doesn't specify whether he's using Stripe Checkout integration (where stripe 100% control the landing page hosted in stripe domain) or other integration types (e.g. direct API call / embed which has higher risk). With Stripe Checkout integration type, you redirect users to a payment page hosted by stripe and have no ability to check whether the user is performing card testing there because the payment page is in stripe's domain, so stripe should be the one responsible with card testing prevention when using this discussion integration type.

[simfree]

That is a very hopeful (and naive) view of liability in the merchant processor space. By default all liability falls onto the business, not your merchant processor unless you specifically negotiated for a liability shift.

Stripe will not eat the fees for card testing.

[neurostimulant]

What can we do then? Stripe's own documentation recommends us to use Stripe Checkout because it's the most secure against card testing, and that checkout page is owned and operated by stripe so it's not like we can add custom card testing detection logic there.

[weird-eye-issue]

Radar fraud rules. Like is already discussed in the Twitter thread. How hard is it to read?

[neurostimulant]

I admit I didn't scroll too far down beyond the signup modal.

[weird-eye-issue]

You are so naive (and wrong) lol

Also, it is mentioned in the thread they are using Stripe Checkout (we are too)