Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

But wait, what about Stripe Radar?

If card issuers are "often able to detect that a transaction is fraudulent before it is disputed" (presumably because of transaction history) then why can't Radar block the transaction from ever taking place? Maybe there's more to it than transaction history? Can you clarify?



Here's a stylized example which may help:

Monday: credit card does a transaction at a particular business.

Thursday: user calls bank to report card stolen as of previous Sunday. This kicks off a TC40 on all transactions on or after Sunday.

Friday: bank staff and/or user walk through the transactions which were post-theft, figure out which ones were still authorized (e.g. the recurring Netflix bill), and file disputes on all the other ones.

Since there is no way to send the TC40 back in time to Monday, it can't influence the fraud scoring run at the time of the transaction. But there is, in this stylized example, a window between the TC40 and the dispute for the business to proactively investigate and possibly refund.


> But there is, in this stylized example, a window between the TC40 and the dispute for the business to proactively investigate and possibly refund.

There is also a perfect opportunity for the IPSP to flag the transaction and reverse the transaction before it becomes a problem for the merchant.


Isn't this what Ethoca and Verifi do?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: