Live data from Hacker News

Candy Japan hit with credit card fraud

candyjapan.com

81–90 of 208 posts

Re: Candy Japan hit with credit card fraud

#82
post #73

Earlier quoted context omitted.

> is there a way to require someone to enter the pin that they use when they buy something in person A PIN can be required for "cardholder present" transactions in most of the world. Some combination of card issuer, transaction processor and merchant decide at what value transactions may proceed without a PIN — e.g. a train company's actual loss from a fraudulent ride is very small, so they might not want the delay o…

> It's almost 100% of transactions in much of Europe Unless the customer is using contactless payment card?

There's a (relatively low) transaction limit for contactless payments without additional verification. So, to buy a TV, you still need to enter a PIN.

Newer payment terminals can support device-based customer verification for contactless transactions, called CDCVM. The transaction limit doesn't apply if CDCVM is used. This is the mechanism used by Apple Pay, where you verify your identity using your fingerprint via Touch ID.

Re: Candy Japan hit with credit card fraud

#83

I commented this on yesterday's jsbin article, and I'll write it again. Don't implement the payment processing code yourself. (And using Stripe is _still_ implementing it yourself - they supply only one part of the process.) Writing this code will take time that you are not using to develop and market your product. (cf opportunity cost). Your code will be buggy. Your code will be weak. Your code will not support the…

Living in Holland, where everyone does online transactions with iDeal, I find it hard to understand why the rest of the world is using credit card payments at all, for anything. It is massively insecure, it's expensive for the merchant, and theft is ignored (when millions of stored creditcard records are stolen, those cards are not invalidated and replaced?). This is all at the cost of customers and other merchants.

I'll keep trying to avoid using a creditcard as much as possible and use other payment methods when I can, both online and offline.

And yes, when implementing payments on a website, use a service that does all of the complex things for you, and never store sensitive data yourself.

Re: Candy Japan hit with credit card fraud

#84

Earlier quoted context omitted.

3D Secure was mentioned in the other thread. Folks recommended avoiding 3D Secure / Verified By Visa because so many banks implement it insecurely, and the redirect model is easy for phishing scams to imitate: https://news.ycombinator.com/item?id=10235328 That redirect will kill conversion rates too, being redirected to a site you didn't expect claiming to be your bank but not matching its URL... of course it will fr…

These verification mechanisms don't freak people out once people are used to them. Pretty much anyone who uses credit cards to buy anything online in Europe will have encountered this system before and will be more suspicious if they don't see it! Using customers birthdate is indeed a very poor authentication mechanism, but even that is going to defeat the majority of fraudsters who are simply trying to bulk-authenti…

How do you use the collected birthdate to reduce fraud?

Re: Candy Japan hit with credit card fraud

#85
post #84

Earlier quoted context omitted.

These verification mechanisms don't freak people out once people are used to them. Pretty much anyone who uses credit cards to buy anything online in Europe will have encountered this system before and will be more suspicious if they don't see it! Using customers birthdate is indeed a very poor authentication mechanism, but even that is going to defeat the majority of fraudsters who are simply trying to bulk-authenti…

How do you use the collected birthdate to reduce fraud?

Nobody collects the birthdate. It would be validated by the card issuer against their account records. The merchant doesn't see anything that happens during the 3D-secure part of the transaction.

Re: Candy Japan hit with credit card fraud

#86
post #6

Interestingly enough I found this subthread from an HN Post earlier today to be very relevant: https://news.ycombinator.com/item?id=10234561 > Regarding his fraud issue, I found that my website was being used in the same way when I added a credit card payment form. I implemented a system that first does an "Auth". If that passes, then I pass details to MaxMind and get back a response with a "riskScore". If the score…

This issue is so costly and prevalent that I feel its a huge disservice for companies that offer credit card services to merchants to not either 1) mention this issue and recommend a fraud check service, or 2) include fraud protection in their service. I actually ran into an issue a little while ago in that I allowed my MaxMind account to run out of queries. Not realizing this, I saw a few days of higher than normal…

> My ideal credit card would be on where the physical card has e-paper on it with a 6-digit PIN that changes periodically, like 2-factor auth, and that PIN could be required for purchases to be authenticated. The new smart-chip cards don't help at all with online purchases, only point of sale.

You may be interested in the system I use with my bank in the Netherlands.

The old system worked like this: The bank gave me a device they called a "Random Reader". To make a payment, I had to insert my card into the device, enter my pin, enter a (random?) number that the payment site gave me, and enter the amount. It then gave me a number back that I had to give the website, which authenticated me.

These days I use a "Rabo Scanner", which works the same except instead of entering a code and the amount it has a camera on there that scans a kind of barcode on the screen that contains that information.

So it does use the smart-chip, and the (8-digit) pin changes every time you make a payment. You do have to take the device with you, but it isn't very big.

Re: Candy Japan hit with credit card fraud

#88
post #80

I commented this on yesterday's jsbin article, and I'll write it again. Don't implement the payment processing code yourself. (And using Stripe is _still_ implementing it yourself - they supply only one part of the process.) Writing this code will take time that you are not using to develop and market your product. (cf opportunity cost). Your code will be buggy. Your code will be weak. Your code will not support the…

This is true but in this case he's not directly integrated (he's using Recurly). Better fraud tools is something we are actively working on.

Would it be possible to give us a better ETA on when something is likely to be implemented?

I was thinking of using recurly and this has put me off somewhat.

Re: Candy Japan hit with credit card fraud

#89

Earlier quoted context omitted.

Thanks for the clarifications regarding documents. To be precise, my confusion was due to not finding the Smyte brand mentioned anywhere in there, although I did admittedly only skim-read them. >Happy to chat more about specific use cases over a medium that's better suited to it; mind shooting me an email? Well, I could do that; I'm just not sure why you'd invite questions on a public forum and then quickly switch to…

The main reason is I'm going to sleep now and want to remember to get back to this thread tomorrow :)

[deleted]

Re: Candy Japan hit with credit card fraud

#90

I commented this on yesterday's jsbin article, and I'll write it again. Don't implement the payment processing code yourself. (And using Stripe is _still_ implementing it yourself - they supply only one part of the process.) Writing this code will take time that you are not using to develop and market your product. (cf opportunity cost). Your code will be buggy. Your code will be weak. Your code will not support the…

Do you have an RSS feed or a link to where that post may show up? Thanks, highly interested!
Post reply on HN