Hacker News Reader

Comment by neurostimulant | Hacker News Reader

I'm under impression that we basically don't need worry about card testing if we're using Stripe Checkout instead of direct API calls. Is that true?

View on HN

I'm the thread OP – can confirm we're using Stripe Checkout and all CC processing happens in a fully-managed Stripe Checkout page.

We're not using any other API from Stripe other than that required to launch the hosted Checkout page.

No, that's clearly not true. Otherwise this thread would not exist

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.

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.

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.

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

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

You are so naive (and wrong) lol

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

Reply on news.ycombinator.com