dulse

Thanks for the feedback! Will take a look at this, agreed that sounds easy and helpful.

We're going to automatically refund the transactions and fees, but also support any write-ins if you feel we missed any. (We have some ways to identify the transactions after they happen).

I agree with you, it's very counter-intuitive why these transactions are getting through Radar. We're iterating on some fixes right now that should stop this going forward by addressing this type of attack.

Really sorry to hear about that experience — we need to do better here. If you want to shoot me an email (wmegson [at] stripe [dot] com) I can take a closer look at those specific charges. We are identifying those charges and are going to automatically refund any impacted transactions and waive the fees for those payments. We'll also waive the dispute fee (if a payment has been disputed).

The team is digging into why the risk score is low. In general, the types of signals you describe weigh pretty heavily in Radar’s risk assessment, and should result in higher risk scores. In this particular attack, fraudulent actors are using some pretty sophisticated scripts to try and obtain lower risk scores. We’re iterating quickly to address and stop these types of attacks and score them correctly going forward.

[I lead Radar at Stripe] We're still investigating but have blocked the majority of this attack from the Stripe network. We're going to refund any impacted transactions and waive the fees for those payments. We'll also waive the dispute fee (if a payment has been disputed).

More broadly, we’ve seen an uptick in card testing attempts across Stripe. While the absolute rate of successful card testing across the Stripe network is flat-to-somewhat-down, it’s not evenly spread—some businesses are seeing more than others. For these new testing attacks, we’re deploying mitigants in real time.

Hi! I work on card testing at Stripe and would love to help. Sorry to hear about this experience, would be great to dig in and see how we can fix it and improve our system.

If you could, shoot me an email and we can dig in? I'm at wmegson [at] stripe.com (will DM you as well).

Congratulations!! Love the philosophy around the product and the dynamic treatment of higher risk transactions with Checkout routing to 3DS.

It must feel great to be able to support such a "simple" product, as I know there must be a ton of complexity under the hood enabling the simple form factor.

It’s an investment trade off around commitment (in person is better for connecting and relationship building but is more expensive as a time investment). If it’s more transactional a phone call is better (eg, quick question or advice about something specific). If it’s something more potentially meaningful, in person Coffee makes more sense (eg, if I’m looking to network with someone or trying to hire them / get them to hire me).

The defaults you set could make a big difference in the user experience. Maybe every first touch is chat/phone, then move to real world? Dunno if there’s a right answer but feels like something to be thoughtful about.

Couple thoughts.

1) bug report: your input on describe yourself is set to email, which messes with my keyboard on my phone. Have that be text input, the other to email as it is.

2) like the idea, connecting influencers can be relevant for sales referrals, recruiting, or networking. All seem like good monetization opportunities.

3) it feels tricky to get the balance right between in person vs phone call contact. Looking forward to seeing how you’re going to handle that.

Good luck!

Great advice, thank you! We'll make sure the date stuff works.

For EU cards, one experience I'm excited about supporting is the "tap to add" flow which may be even easier than OCR. Unfortunately only Android supports it for now, but love that experience when it's possible.

Thanks, and will do!

Thanks for the feedback!

Our goal for the experience is the Apple Pay OCR experience, but it's embeddable directly in apps (so users don't have to already have it set up, if they prefer to use cards, or navigate to apple pay and come back). I agree this would be for the users not using Apple Pay.

Long term, I agree the trend is moving toward apple pay and digitized payments, but I found lots of people still like / prefer credit cards (so trend is that direction, but slope isn't super high and it'll take a while). I'm also excited about the fraud benefit of this kind of solution for bigger orgs that deal with fraud.

Gotcha, didn't realize. We're several weeks away from fully working product (tried to be transparent on the page about timing), but have figured out the hardest part (generic OCR algo to read the numbers). Was hoping to get some feedback on the direction / interest level in advance of full completion, but this may not be the right forum.

Gotcha.

Unfortunately what we have isn't really sharable yet, but we're planning to update as soon as it is - but I get this isn't that helpful when you want to play around with it. We figured out the hard part (OCR algo is pulling the card info) and were hoping to get some feedback on the direction / interest level / use case before completing all the rest of it which will take us several more weeks. We'll journey on.

Hey HN, I loved the experience of card scan products, but found they don't work well with more recent card designs. We're re-implementing the OCR algorithms from the ground up to work on a much broader range of card types, and also doing some checks to make sure the cards are real (which will help a lot with fraud).

Would love to answer any questions and hear thoughts!