Hacker News Reader

Looking at the docs (https://docs.bolt.com/v1/docs/step-2-load-bolt-checkout) it instructs the reader: "The onSuccess method will be called when Bolt successfully processes a transaction. This can be used as a way to create the order (...)". This opens up a massive security hole if the merchant is making decisions based on this method being called client-side, right? What prevents a malicious actor from calling that method directly and thus simulating an order as far as the merchant is concerned?

Thanks for pointing this out. It was a shortcut for some very early beta testers. We've since removed it from the docs.

We have a server-based webhooks to create orders which is how we do secure order creation. Bolt provides a webhook (Bolt server -> merchant server) and REST APIs (merchant server -> Bolt server) to exchange data (including transaction details) through a secure channel.

Appreciate it again.

> This opens up a massive security hole

Have you considered that discussing API design decisions regarding security in a public forum is a bad decision of your own?

After literally 10 seconds on the site, I found this: https://bolt.com/security

Nah, his post is what Hacker News is for; if the company and their CEO is announcing coming out of stealth mode and answering responses, it's worth that guy vocalizing that potential vulnerability.

Your post tried to chastise him for calling out a vulnerability, and then tried to shame him for not quietly emailing their security team. Chances are if someone were a bad actor they would have: A) seen that themselves outside of his message, or B) Found out through sheer luck and brute force

If anything, the poster mentioning it invites the team to fix it before someone exploits it. It's worse to blunder on a hole someone told you was 1.5km down the road, so hopefully they either address it or fix it

"Security hole" may have been poor word choice on my part. "Potentially unsafe process recommendation" would probably be a more apt description.

My concern is not a security issue or vulnerability on their site or service. I am concerned that a processes they are recommending may not be safe, and if I am incorrect (I still feel that I may be missing something), I feel that a response may be insightful to others.

I imagine there is an HMAC or similar that can be verified?

What happens if you're flagged for fraud? e.g. on a recent talk by a different company, the presenter said that buying Pepsi implies a slightly higher percentage of fraud than buying Coca Cola. What happens if I, a legitimate customer with a real, non-expired, not-overcharged credit card cannot make a purchase because your system flags my transaction as fraud?

I believe part of your question was answered here[0].

In short: on this platform merchants have the ability to process a transaction that Bolt suggests is likely to be fraudulent (in effect ignoring the warning).

In a general sense, all merchants have to balance their false positive rates with their false negative rates in a way that makes sense for the products/services they sell.

[0]: https://news.ycombinator.com/item?id=16217020

So, you're providing fraud protection to merchants the same way Amex/Discover/Master Card/Visa does to consumers?

That's correct. Today, merchants are on the line for any fraud that they incur. When you call your bank to report fraudulent activity, the merchant is out the goods + has to pay fees/fines + has to return the money + deals with paperwork overhead. Bolt completely eliminates all of that. We're taking a stand to end fraud and take on all the liability for our clients.

If I buy a product from a website using Bolt, and for whatever legitimate reason I do a chargeback, let's say the product never arrived and the company refused to acknowledge this, will the anti fraud ban me from buying from any of your clients ever again?

I once had a tracked package marked as delivered, despite the entire neighborhood being cordoned off by police with nobody but residents being allowed in. Despite proof of this, the merchant refused to accept the package was not and could never have been delivered.

Nope, you'll only be black-marked if you actually committed fraud. Any time there is a customer dispute, we're able to act as a middle ground often times. If a merchant is a bad-actor, we'll give them some time to fix their customer service. Or, we'd have to part ways with them.

Thanks for the reply.

> However, the fraud that ends up making it through the pipeline is so minimal that we cover it fully.

You're contradicting yourself when you also say that you charge $20 for chargebacks.

Because chargebacks aren't fraud. They can be fraudulent but then I assume it would be part of the 'not covered' portion of the sentence you left out.

Say, I got myself a credit card number of someone from Toronto, Canada and I am checking out through your system using a botnet-based Toronto exit node.

Similar scenario, but this time I am an actual owner of that Canadian credit card, but I'm using Tor (or VPN) with an exit in Romania.

Can you elaborate how your 200+ variables will be able to block first and allow second purchase?

I don't think this is the type of thing they can really elaborate on for obvious reasons.

But the genuine holder is probably going to be blocked when they start throwing flags like that, and that's probably just standard everywhere with any type of automated fraud protection.

Well, it's a pretty basic question.

In both cases the vast majority of their 200 variables will look the same. The only differences will be in the IP and latency data and, possibly, the time zone/locale information if a fraudster is not being careful.

Point being is that differentiating these two cases comes down to analyzing just few bits of data, so I'm not sure why they are using "200 points" as a selling point.

I can't imagine many e-commerce checkouts work well through tor. I can barely use google over tor without getting constant captchas.

I also wouldn't expect them to detail all their fraud prevention techniques in a public forum.

IMO this is a really interesting idea! Since they are also the payment processor, they have access to more data for fraud prevention, so much so that fraud "insurance" is basically baked into the rate.

Increased efficiency through data analysis, and they are passing the savings on to yoooouuuu!

This could be a paradigm shift. Very cool. The docs look good, AND it works in Canada!?! Thank you! Canada is rarely a priority for US fintec companies. Even amazon DevPay doesn't work here last i checked. Sign me up!

Most fraud detection systems rely on blocking rules. So they'd detect a VPN/Tor and combined with an international order, it'd be an almost guaranteed block.

We'd factor this in, and it may be negative, but if the other 198 variables match up, you'll be in good shape with Bolt given your purchase behavior, on-page event patters, order details, and many other factors that are much better predictors of fraud than VPN/Country/etc.

> other 198 variables match up

With what exactly? 198 variables will be the same between two cases I described.

The follow up question is what your false-positive rates are. As I said in another reply - there is a set of simple and common cases when both fraud and legit purchases look the same, so by having a zero fraud rate you will be driving the false-positive rate up - and that is bad. People won't be able to pay even though they are already with a wallet in hand.

This in turn means that merchants will need to implement a fallback option to cover this risk... which is going to be PayPal, probably.

All of this is why Stripe Radar implements _provisional_ blocking. They let purchases through, but flag them for a human review. I am going to make a bold prediction and say that you will converge to the same approach sooner rather later. There's no magic recipe.

We never auto-reject, and we already do human review. Forgot to mention that.

At the bottom of https://bolt.com/fraud

"MACHINE POWERED, HUMAN REVIEWED"

"Everything we do at Bolt is tailored to maximize your order approval rates. Purely algorithmic systems falsely reject good customers. Every suspicious order goes through an extra layer of human review to ensure the best results."

> Can you elaborate how your 200+ variables will be able to block first and allow second purchase

A Bolt employee already replied[1] with a section about false positives vs. false negatives.

I can't imagine any legitimate financial industry company cares much about supporting Tor users. If your financial accounts are based in Canada but your IP traffic appears to be coming from Romania (whether through Tor or VPN or other similar reasons), you probably are much more likely to be involved in fraud from their perspective.

If you have Canadian accounts and are travelling in Romania, that's a different story.

[1] https://news.ycombinator.com/item?id=16217020

Tor is an extreme example, but VPNs are now commonplace. From the top of my head, we have a double-digit percentage of purchases coming from the UK done that way. Zero fraud.

You mean if you aren’t automatically blocked because you are coming from a TOR exit node and that user has never done that before?

I can't parse your question, sorry.

Have a public list of clients anywhere?

Is it always the case that more variables are necessary better? After some sweet spot, with more variables false correlations increase exponentially.

I believe that scaling would be quadratic; but yes, more features (variables) isn't always better.

However, you can't know which features carry information until you collect and analyze them. For a problem like fraud -- where "expert" input probably would not allow you to figure out which features you need ahead of time -- it was almost certainly more reasonable to gather all the data and then, after the fact, perform feature selection[1].

[1] https://en.wikipedia.org/wiki/Feature_selection

++ exactly right

- Collect as much as possible

- Figure out what features are worthwhile

- Focus on those features

Our competitors have an extremely narrow lens into all the data around a transaction. We've found things that they'll never find or even have access to in the first place. Blog posts to come here as well.