How Candy Japan got credit card fraud somewhat under control | Hacker News Reader

How Candy Japan got credit card fraud somewhat under control

candyjapan.com

229 pointsNickSharp125 comments

If you suspect an order is fraud, don't go out and say to the criminal "hey, I declined your super suspicious order!". Instead, play dead. Pretend they got you. Tell them "thank you for your order", behaving exactly the same way as if it really was a successful order.

The name of the game is to make things cost more for your enemies than they cost for you. Removing instant feedback is key. Instant feedback is great. Delayed feedback is costly.

This is in large part why most DRM and anti-cheat failures happened. Companies and developers need to think about the economics of what's going on. It's not the side with the trickiest mechanism that wins. It's the team with economics on their side.

(Amateurs: tactics, pros: logistics)

Yeah I was just talking to an employee of a CC fraud prevention company and that was my thought: they proudly talk about how they can identify fraud and refuse the transaction, when my question was, why not just look like you're approving the order and then follow it right to the fraudster?

Better to reliably catch the humans behind this and impose stringent legal penalties than allow them to keep guessing without a cost for being wrong.

> Yeah I was just talking to an employee of a CC fraud prevention company and that was my thought: they proudly talk about how they can identify fraud and refuse the transaction, when my question was, why not just look like you're approving the order and then follow it right to the fraudster?

You can get disposable physical addresses as well.

It is part of why some companies flag a mailing address I use as a fraudulent order. I primarily use it to avoid handing out my RL address on domains that don't allow whois protection.

This may work nicely for a subscription business where you have 2 weeks to identify problematic orders. But what about everyone else? Should we silently fail on orders where a customer accidentally mistyped their CC#? Imagine all the extra work involved when you could have had them fix it on the spot.

You can report "failed checksum" or "not a valid account" to people, although you should rate limit - the problem is data that is valid but stolen.

Mistyped card numbers can be identified client-side (CC numbers have a checksum digit). If the number is valid, but the transaction is declined, then fail silently (and possibly send a failure email after manual review of the transaction)

It could also be declined because of mistyped expiry date or address or name. Or simply declined because the customer is over their credit limit. In all of these cases, timely feedback is useful for genuine customers.

Which is why it says in the article that these countermeasures almost always come at a cost to customers as well. It is a trade off.

In some instances it is worth it to make the experience marginally worse for customers because the savings by preventing a percentage of fraud are so large.

Nonetheless, this doesn't contradict the "failing silently" for chargebacks. It's not fraud if they enter the data poorly or there's no credit left so the charge is never made.

This also applies to customer service. Nice customers get fast response times. Toxic entitled customers (especially of the free plan) wait 2-3+ days before getting a response.

I'm not disagreeing with your point, but I love it when I get great customer support as a free/low value customer, and it definitely increases my chances of conversion.

Maybe op was referring to free customers that are rude, and impose big costs to you (way above the average support ticket).

But agreed, if I get bad support as a free customer, how can I know that the support will get any better if I start paying (except for services that sell support). When I get an instant response to a question from a friendly support, I would say that I'm far more likely to upgrade to their paid server.

The point is that toxic customers tend to sap your bandwidth. If you impose a time cost on them it throttles their ability to do so.

One way or another the problem works itself out, which lets you focus on the paying (i.e. actual customers).

that why every social network does ghosting to trick spammers and trolls

Blue Byte did something along the lines of your suggestion with the copyright protection of Settlers III. When the game detected that the DRM was broken, iron smelters would only produce pigs instead of iron.

https://en.wikipedia.org/wiki/The_Settlers_III

reminds me of "Game Dev Tycoon", where if it detected it was cracked, the player had a hard time progressing because their virtual company kept getting ripped off by crackers.

http://gameological.com/2013/05/inventory-9-games-with-creat... (it is the first one)

More specifically, the player's simualated video game company goes bankrupt, "due to piracy", according to the game.

More details & discussion from Game Dev Tycoon's developer blog: http://www.greenheartgames.com/2013/04/29/what-happens-when-...

For a much older example, Sim City gave continual disasters after about 10 minutes if the version was detected as pirated. This was 1990 or so.

Not bad, but even that reads like a bit of an FU from the devs. ("Pig Iron?") The best thing to do is to make it definitely seem like it was a bug introduced by the crack. (Maybe James Bond villains giving their secret projects suggestive code names and telling their entire plan isn't unrealistic?)

Well, if you want to convert a pirate user into a sale, you need to convince them that the bug isn't present in the retail copy.

So you're balancing making it hard for crackers to detect, and easy enough for players to encounter that shift behavior.

So have a web search that finds people talking about the fake bug, then take appropriate action.

It's important not to disguise any anti-piracy measures as bugs, because pirates (or even reviewers playing pirated copies) will loudly proclaim that the game is buggy, and discourage legitimate buyers. This may have contributed to the closing of at least one development studio (Iron Lore, developer of Titan Quest)[1].

[1] http://www.quartertothree.com/game-talk/showthread.php?42663...

This must be specific to the games, because they do tend to be buggy on their own.

With non-gaming software the situation is completely different. When a cracked version craps out the prevailing sentiment is always that it was a bad crack. Always.

I'm wondering why there isn't a service that lets you search for people encountering your crack-penalty. A really sneaky company would disguise itself as a hacker group, then offer a copy of the game that doesn't have that "bug." (But has another one.)

Green Heart Games did basically that. http://www.greenheartgames.com/2013/04/29/what-happens-when-...

Bohemia Interactive have their games "degrade" if they detect they are pirated. Weapons become increasingly inaccurate and your character turns into a bird.

https://en.wikipedia.org/wiki/FADE

100% agree. They care about ROI also.

At my last company I build systems specifically designed around wasting the time of people that we "caught". We used to keep a dashboard with the top abusers on a wall in the office once they'd be caught to show how much of their time we were wasting. It was therapeutic.

Valve will sometimes delay banning CS:GO hackers to confuse them about just what triggered the ban.

What happens if you have a very small false positive rate for fraud, and end up stiffing the customer? You could easily land in deep trouble with consumer protection laws after falsely satisfying their order.

PM from a fraud detection company here. One thing I didn't see mentioned on this thread is Device ID, which is very common on fraud detection platforms. When a user comes to your website or mobile app, you have access to hundreds of signals from their device. Some like IP address are easy to spoof. Others like whether the user has changed their phone alarm from the default settings are often ignored by fraudsters but surprisingly telling signals (fraudsters don't bother to change from default settings). We wrote an article on some interesting findings recently here: https://simility.com/device-recon-results/. A good device ID product can not only tell if the same fraudster is accessing your app repeatedly while pretending to be different users, it can detect risky user profiles when they land on your app. Before they even make a payment.

Interesting ... If u have a device id running on ur site , how do u tie a 'suspicious user' it flags with the orders made by that user ? I read abit about ur product and it's not clear how a web shop like candy Japan would integrate quick and dirty with this

Normally an order on your back-end is linked to our device ID with a session ID. However our device ID can also accept user-generated data within fields on your website/mobile app. So if your customers enter their email address during your checkout process, that email will be tied to device ID and you can then look up suspicious orders by their email address.

Just a thought: have you ever considered that by publishing such red flags for fraud, fraudsters will adopt these "organic" behaviors in order to appear more legitimate? I understand that the idea is to make illicit transactions more difficult and that adopting these "organic" behaviors is more difficult, but automated fraud tools (ie - what most 'script-kiddies' use) also become more sophisticated over time. Regardless, I bet you don't publish ~all~ your fraud detection vectors for that exact reason.

I'd be surprised if all of the published vectors are genuine, too, for the same reason :)

> Device ID

It's incredibly easy to dupe and manipulate. If someone is determined enough, they can just edit the packet before it hits your server, or install another app/font/package/etc to change the fingerprint. "Well what about IMEI?" see reference to intercepting packets.

You can use Valve's browser fingerprinting library. Its good enough to detect basic guys who are jumping through proxies. Combine that with MaxMind's proxy detection service and its a decent starting block.

So it appears that a combination of (1) removing instant feedback (not alerting fraudsters as to the success/failure of their charge) and (2) giving a grace period to review and cancel charges has given Candy Japan some breathing room.

Though it does seem that this requires a manual step (2) before sending charges through, does anyone have experience using a fraud detection API, like Maxmind's minFraud [1] or any other, in an attempt to avoid having to review each charge?

[1] https://www.maxmind.com/en/minfraud-services

My friend runs a similar candy subscription box called https://boxfromjapan.com/ and reported having a good experience with Signifyd. I might try integrating something like that next.

This can be largely automated using something like minFraud, Signify, etc.

However, you still need to use the same basic process:

Step #1 - No instant feedback

Step #2 - Your antifraud SaaS provider / process / whatever

Step #3 - Reject anyone who fails step #2 after ~24 hours.

>does anyone have experience using a fraud detection API, like Maxmind's minFraud

We tried MaxMind, for our use case it was pretty useless. The feature that sort of worked which we considered using was the geo-location stuff. Our idea was to see how close a customer was to where the goods where to be sent. Sadly the countries we operate in are to small, and IP location is to inaccurate.

As a test we ran a couple of months worth of fraudulent order data through MaxMind, with a success rate of 100%.

The best solutions we found is: - Block cards not issued in the country where you operate. This shield us from poor credit card security in countries like the US. - Enabled 3D Secure. This blocks all the amateurs - Manually call customers ordering for large amounts.

Generally speaking it's very difficult to tell the difference between a fraudulent order and a first time customer.

> Block cards not issued in the country where you operate

Please, don't do this. It's so annoying.

> Enabled 3D Secure

Yes, this is a really good idea.

I currently use Maxmind's midfraud service. It is useful for identifying KNOWN fraudulent email addresses and proxy servers but not much else. It is just one of the signals that I currently use as a part of a fairly manual fraud review process.

I have evaluated a number of different options and I am about to start using Sift Science[1]. In addition to using standard ip address/email based information they also use social data and machine learning to identify fraud.

Their API/data model is the most well thought out and comprehensive one that I have come across and they allow you to back-fill up to 12 months of historical data for free to help improve your detection rates. They also have a console to assist with optional manual review workflows and store integration apis to allow full automation.

On top of all that they offer scalable pricing that works for both large and small business at 6c per transaction.

Obviously I can't vouch for their results yet, but what I have seen so far looks pretty good. If you have a fraud issue you should at least check them out.

[1]https://siftscience.com/

I'll say that I like Sift better than MaxMind, but it still doesn't cover a lot of things that it should. I won't go into details, as I'm in the middle of building a platform to solve this issue myself, but as someone who used to be on the other end of credit card fraud, it's really laughable how many things these companies don't see.

Hi Josh, Jason here, CEO of Sift Science. Would love to hear your feedback on what we could do better, whether publicly or privately - jason at siftscience dot com. We want to do better.

I'm guessing this has been asked before, but why not just use a credit card processor that handles all of that stuff for you. Seems like they are in the business of selling Japanese candy, not preventing CC fraud.

Am I being naive here?

Yes.

At $DayJob we have a similar process [e.g. Accept any card that passes the checksum, hand out rejections on a 24 hour delay after we've handled our fraud signals and processed the charge with the gateway]

The credit card processors aren't particularly interested in handling this for you and you [the merchant] pay the price if you gave the processor stolen card numbers.

Services like these:

https://www.signifyd.com/pricing/ [1% per transaction]

https://www.maxmind.com/en/minfraud-services [ $0.005 ]

would have no customers if you could get a reliable partner to handle this all for you for free-ish.

Completely agree with fweespee_ch. Major CC processors such as Authorize.net, Braintree, etc. offer fraud protection measures but in our experience they do very little to prevent even a remotely-capable fraudster. Typical features offered are IP Velocity & regional IP (useless when the fraudsters spin up thousands of amazon servers), # of transactions per hour (not too helpful when your business already does hundreds/thousands of transactions a day), CVV and AVS credit-card response codes (ends up blocking more legitimate orders than fakes and the fraudsters typically already have this information anyway), etc.

There seems to be a huge conflict of interest here: as card processors slap you with an extra chargeback fee for the fraudulent transactions (in addition to the amount they take back anyway) it's difficult to believe that they would work very hard to help you avoid this.

Why? They have a profit motive for you to get scammed.

They do, to a point, but since you are the one who bears the fee they do the amount they can cost effectively which is frankly marginally effective.

Is it just me or is 1% likely several orders of magnitude larger than $0.005 on a per-transaction basis? That pricing is bordering on offensive.

I'd love for someone to handle all this for me, but so far I haven't found the ideal partner.

Can you name a credit card processor that handles all of that stuff for you? Neither the old-school gateways (Authorize.net/etc) nor the new SaaSy stuff (Stripe/Braintree/etc) offer even risk scoring, let alone a comprehensive solution to fraud mitigation.

Stripe does offer fraud protection, based on machine learning algorithms using data from their customers.

https://stripe.com/docs/fraud

I'm working on a side project using Stripe and at least most comments on the internet are saying that the fraud prevention provided by Stripe is rather weak. Adding additional providers like SiftScience looks like a good idea.

Full Disclosure: Not based on first hand experience, as the project is not launched yet.

Stripe's fraud protection is HILARIOUSLY bad. I'm convinced they don't care about chargebacks; in fact, to get their fee for a chargeback, they need a $500 order.

They don't eat the loss; the card network does.

Actually of the old-school most credit card processors will sell you fraud detection. It's just very expensive, to expensive for small businesses. Normally they're just resell something like ReD Shield, or MaxMind though.

The best option is to get a PSP that will let you do selective fraud detection. Then you funnel large order and first time orders through the fraud detection, and skip it on repeat customers. Otherwise it can become an expensive service.

I have a website that processes a fairly small number of monthly credit card transactions, 1-4 per day. However, it didn't take long for the website to be used as a place for requests, mostly from Vietnam, to check the validity of CC numbers. It cost me a lot of money in chargeback fees.

I ended up implementing a system using Braintree to do 1) Request an AUTHORIZATION for the amount 2) If the AUTHORIZATION fails, return the error (sounds like I need to change this part, but how to do it without hurting legitimate users?) 3) Send information, including IP and email address, to minFraud 4) If the minFraud riskScore is >= 20, request a VOID on the authorization request 4b) If the riskScore is low, submit a REQUEST SETTLEMENT on the AUTHORIZATION

This has worked extremely well, but a few still slip through the minFraud check.

Even though Braintree offers it's own fraud checking, I still feel more comfortable with minFraud. I really wish that processors like Braintree would put more effort into fraud detection.

I NEVER have this issue with PayPal transactions. Even if it's fraud, they just reverse the transaction and there's no chargeback fee.

Why not just refuse to do business with Vietnam, Nigeria, Russia, and other fraud havens entirely?

For some simple companies, this may be the right answer. However this grows in complexity as your business scales so don't forget about that.

A simple situational cost/benefit analysis can answer that.

If combating CC fraud is leading to negative profits in those countries then cut them. If not, continue the war.

I am a native-born American citizen living in Russia.

The amount of grief that your solution causes me is significant. I'm a legitimate customer who does nothing fraudulent. However, whole swaths of the internet treat me as if I have leprosy just because my IP address is in Russia.

So use a VPN, buddy.

So, I use VPN, and order my stuff to arrive where? If someone doesn't ship to Russia, they don't ship to Russia, how can VPN help there?

Freight forwarders are how most of us outside of the US get stuff from companies that only ship to the US - There must be a market for such services that ship to Russia too.

Sure, but you've just made fraud cost them actual money.

As a seller, it is not your responsibility to compensate for the fraud issues impacting your customer's ability to participate in the marketplace without it being worth it.

I don't know exactly what causes Russia to be a fraud hot spot but Australia not to be, but the issue can only really be resolve inside Russia.

Couldn't you use VPN ? On the other hand so could the scammers if you could.

I don't know how to say this without coming off harsh, so I'll say it and ask you to use the principle of charity when reading it.

If the Russian state refuses to stamp out crime that is causing negative externalities, then people should rightly stop dealing with people inside Russia as a logical response.

Replace "Russian state" with "African American culture", and I think the problem with this attitude becomes more obvious.

Please point me to the representative "african american culture" government apparatus and you'll have a point.

Part of the role of a government apparatus is to enforce social norms. Culture plays a similar role. They aren't the same thing, but they do have similar attributes.

Please note that I am not criticizing any governments or culture; I merely wonder why we're OK with nationalism like this, but not racism.

> I merely wonder why we're OK with nationalism like this, but not racism.

I'm not appealing to nationalism? "Russia" could be a stand-in for any controlled territory.

For example many businesses that trade online in the US attempt to exclude people from the Eastern District of Texas in their terms and conditions. Why? Because the courts there are very friendly to plaintiffs in patent cases and they'd prefer not to get sued in that jurisdiction.

That district is causing a negative externality to people outside of it, so they refuse to do business with it.

Because it's trivial for Vietnamese carders to pretend to be from any country they need to be if you're checking? They don't even need to actually get your delivery to win, they're just tasting for validity.

We ran a fairly prominent online store for two years, and had huge amounts of fraud from the countries you mention.

We essentially stamped it out overnight by giving false positives. If we detected and order as fraudulent (and you can do it in a number of ways, that you seem to be doing) - we'd show a 'Successful Order' page and send them a success email.

The guys that were pre-testing cards had bad data, and the guys trying to fraud would have to wait .. weeks to find out nothing came in the mail, and then try again, unsure what got them caught in the first place.

Personally, I'd avoid trying to interract with their card. Authing / voiding is going to cost you money, and if it slips through, you'll get a chargeback.

We only ever had one 'false positive' (or false-negative..?) - the guy emailed us inquiring about his order, we took some extra steps to check his card, and the problem was solved.

I remember building a subscription system back around 2009-10. Very few of the tools available now existed back then, and things were much less efficient. Or at least that what it seems like looking back. The service targeted competitive gamers (teenagers, early 20s) and I've always suspected that we had to deal with a higher incident of attempted fraud than would be the case with other audiences.

If I never again have to deal with a situation where some kid 'borrowed' mommy or daddy's credit card, I'll die happy. No amount of fraud detection can prevent that situation.

Thanks for the insights.

I've been fighting this fight for over 17 years now. The landscape has changed a lot - mostly for the better IMHO. In particular, issuers are taking more responsibility for checking the validity of the cards but some of them are hopeless and there is still a way to go.

Criticise me all you like but I still have a blacklist of countries where I will never send physical goods to (unless they direct deposit the money, for one of my sites).

Not sure if it's relevant for "subscription" model businesses but Stripe and a couple of other providers have an option to charge the card immediately or just get authorisation for the amount. The authorisation is only held for seven days, but I have found that this has often been enough for the owner of the card to notice and cancel the authorisation before the charge happens. I haven't checked but this could also solve the "instant feedback" problem for providers that give it as "authorsied" is less conclusive than "charged" for the scammer.

When I worked on an e-commerce website shipping physical goods we would only ship to the customer's billing address for credit card payments. Anyone shipping to a different address needed to call their credit card company to add the address (every credit card company I've dealt with would allow customers to have multiple valid addresses on file), or use a different payment method. We never had big issues with fraud and I don't recall a customer ever complaining about it. I think in 3 years we had 2 chargebacks due to fraud.

You do know that some cards allow any billing address right?

If it's a source of fraud we never ran into it.

Eliminating immediate feedback about failed transactions makes things harder for everyone the fraud detection system identifies, both fraudsters and the many false-positives. And the false-positive rates seem very high, IME; it seems like I and everyone I know has encountered that problem multiple times.

Imagine that you place a legitimate order and they don't tell you it failed; how do you find out? Days later when the order never arrives? That would result in very angry customers.

There's nothing inherently bad about very angry customers. It's more about how you handle them and whether you are continuously looking for ways to decrease them in number.

In this case, the idea is these are people who tripped red flags for you, and upon investigation didn't give you any reason to believe they were legitimate orders.

If you're really worried, you can contact them and ask.

I really love how open Candy Japan has been with the business on HN, since the beginning. Thanks!

We exclusively use PayPal as they kindly cover all of our transaction fees. However, we still experience fraud which creates work for accounting and Customer Service.

A rules-based approach has helped, but we've also been playing around with SiftScience[1] and I've seen it do wonders for some sites, so we'll likely be implementing it. The key problem is keeping the false positive rate down, as we don't want to inadvertently block our legitimate users.

[1] https://siftscience.com/

In the article, PayPal it's often mentioned that PayPal is generally disliked.

As an international customer, I prefer PayPal over giving them my credit card details. When entering my CC, there is a big risk that my data gets stolen (is the data truly securely transmitted, stored, and processed?). I know I can request a refund that any time with my bank but that is a big hassle. I have to write them a physical letter, and wait for a couple of days. During that period, my CC is blocked and I they will likely issue me a new credit card (which costs 10€). When paying with PayPal, I can report a fraud online or call them and they have been really quickly in responding (I have once not gotten a product and they were very quick in issuing a refund). Also, I feel way more comfortable using PayPal because I can see that the site I'm entering my information to is actually PayPal, and I have two factor authentication. Before I didn't have a CC, PayPal was the best solution because they would just withdraw the money from my bank account and they merchant would get their money immediately.

I can understand why PayPal is not a good choice for sellers (I've heard stories where PayPal blocked merchant accounts for a few months without giving them their money they had on PayPal, and refusing any new transactions). So, can you explain to me why PayPal is a bad/unpopular choice as a customer.

Keep in mind that PayPal leaks lots of your personal information to the sellers, including full street address. Merchants don't even need to opt-in to get it, it's all provided by default for all purchases, even when there are no physical goods involved.

And yet 95% of all my purchases require a billing address, even if they we'll never ever send me a letter. Even better, some even check if the billing address is correct (they send it along with my CC# to my bank and my bank will decide what to do).

In Europe it's the law that you need to record the billing address (for 10 years) otherwise you can't obey the VAT laws.

My understanding is that Stripe is pretty much the de facto solution to get started with credit card payments on your site, and if you're relatively low volume you can review for fraud and manually reject it yourself.

I've set up stripe before, so I have a casual understanding of how it works, but I'm curious what an attacker would be able to do (worst case) if a server I have Stripe payments on gets rooted. Are they only able to charge legitimate customers' cards for the period of time that a payment token is active? Or I suppose they could re-direct the payment page to their own payment page. If they steal the Stripe secret key is there a way they can steal money using it? (other than just bulk testing if they can charge cards)

Is there no service that does CC processing and fraud detection already?

I would think it does not make sense for every ecommerce merchant out there to build their own solution.

Bemmu, you say you use PayPal - isn't PayPal also accepting Credit Cards? Don't they do the fraud detection in this case? I would expect them to have a huge advantage. You only see the IPs and other metadata from a few customers. They see millions and should be able to do way better fraud protection.

Yep, PayPal is awesome at this. I originally intended to go on a long tirade about how PayPal had dealt with this, but cut it out as the post was starting to get a bit long.

---

Peter Thiel on PayPal: "In mid-2000, we had survived the dot-com crash and we were growing fast, but we faced one huge problem: we were losing upwards of $10 million to credit card fraud every month. Since we were processing hundreds or even thousands of transactions per minute, we couldn't possibly review each one - no human quality control team could work that fast.

So we did what any group of engineers would do: we tried to automate a solution. First, Max Levchin assembled an elite team of mathematicians to study the fraudulent transfers in detail. Then we took what we learned and wrote software to automatically identify and cancel bogus transactions in real time. But it quickly became clear that this approach wouldn't work either: after an hour or two, the thieves would catch on and change their tactics. We were dealing with an adaptive enemy, and our software couldn't adapt in response."

They ended up going with a hybrid approach where their algorithm would flag suspicious transactions, which would then be manually reviewed.

I've heard Max Levchin describe Paypal as a "credit card fraud detection system that also accepts payments".

Also this quote from the book Zero to One: 'Max was able to boast, grandiously but truthfully, that he was "the Sherlock Holmes of the Internet Underground"'.

This is also where the majority of "PayPal sux!" type posts come from. People who get caught up in the hyper vigilant fraud detection stuff and get their account locked.

I have occasionally wondered how many of those foaming at the mouth tirades come from people who were actually scamming people and are angry that their take was locked away.

As someone who went through PayPal hell a few years ago, I'd say there is a lot they could do/have done to improve their customer service without impacting their fraud protection capability. I experienced issues like being bounced between different phone representatives offering different explanations for why my account was locked, a slow and duplicative process of uploading scans of identification documents, etc.. Just saying.

Most will sell to fraud detection for you, it's just expensive and typically not very good.

PayPal is an option, unless you have low margins, it's a very expensive way of accepting a credit card. It's also a terrible user experience for people in countries that aren't to familiar with PayPal.

You can use PayPal as a credit card processor, with the user having no idea they are involved.

Really? While still leaving all the input of credit card numbers to PayPal? I mean you'd still have to have some "landing page" with Paypal.

If you happen to have a link handy I would very much like see how they do it.

https://developer.paypal.com/docs/classic/products/payflow-g...

I didn't realize "leaving all the input of credit card numbers to PayPal" was a condition here. I don't know how to do that, although it may be possible. I'm thinking of their service where you host your own form but use them to process the payment. cc data flows through your server on its way to theirs, but isn't stored on your systems.

I'd be surpised if any online CC processor didn't do at least some fraud detection already. Stripe does, for instance.

What's the best way to do "no immediate feedback" when you're selling something that is instantly delivered? (Site paywalls, for instance.)

Do paywalls face as much fraud? My understanding is that industries that provide digital goods or services see a much lower rate of fraud because there's little resale value involved (and the cost of stolen/returned goods is much lower).

It sounds like the biggest problem that OP is talking about is people using his service to validate credit card numbers. They don't particularly care about the candy, they just want to know if a number has been cancelled yet.

He's not concerned about fraud where he is out goods, he's concerned about fraud where he's being used as a card verification tool. Checking the validity of credit cards is expensive and hard for carders; They need to do so fast and in bulk, but without setting off the fraud detection on the other side and killing the card.

Ah ok, that makes sense. A paywall would be perfect for that.

My initial solution would be a restricted trial that is mandatory and lifts when the scheduled subscription date hits and is successful.

The 'trial' period is advertising.

Depending on the specific nature of the content (news content comes to mind) you could even just grant access for 24 hours and revoke it if fraud detection fails. This solution wouldn't work well for all types of content where the feature could be abused to harvest static content.

Allow anything that passes basic validity checks, then send a nice email a few days later asking for updated payment info. This is easiest if you're a subscription service as you'll want to have a process for recovering customers with expired CCs anyway. This is assuming you're in the usual case where the paywall is to stop free riders and not to reduce your costs.

I wrote a similar system for an ecommerce site-

attached session data, "remora data", tracked IP's, (in fact trace routed all IP's looking for suspicious proxy flags like going through Ghana), browser meta data- etc etc. I'm proud of how robust it ended up being. Constantly recursively crunching shipping addresses, CC numbers, IPs, all that jazz and accounts- so if someone tried several different cards their account would be flag, which would flag their IP which would then trickle down the system.

Of course never letting an attempted scammer know the system was on to them- in fact encourage them to keep using more cards and try different combinations so the flagging system would grow over time. Sure we got some false positives, but drastically cut down on repeat scammers. :)

In which case we just encouraged a phone call and solid proof of information for an account override.

It was war! Good article!

Not sure if the author tried this, but there are many experts on carding around the internet (the most famous being Brian Krebs) who might give advice for free on credit card fraud countermeasures. The simplest way to find them is to google for presentations at hacker conferences about carding, cyber criminals, credit card theft, etc.

What if a real users mistypes their credit card number... your order was successful.

You check the card number via the Luhn algorithm, and tell them about it? That's not giving any data to fraudsters.

If you at any point have access to the customers credit card number, then your doing something horribly wrong. Unless you're the payment processor.

You can do that client-side, easy.

Luhn algorithm can be done client-side - all it needs is the number.

Letting a customer enter a credit card and then parsing it on to the credit card processor means that you would need to be some level PCI complainant. You really really don't want to be close enough to the credit card numbers to do something with them, especially client side.

Having the credit card field, where you can access it, means that you become a target for people wanting to inject javascript into your site. Perhaps you're safe, but what about all the third party javascript libraries or tracking/remarketing/tracking script most sites have?

Sorry, it's a really bad idea. Let you credit card processor deal with the that hassle.

Luhn doesn't catch everything. (It will not detect transposition of the two-digit sequence 09 to 90 (or vice versa) - Wikipedia).

But, ok, what about an innocent CCV typo.

You need to give real users errors when they make mistakes.

The last digit of a credit card number is a checksum, so it can catch most of those errors.

See https://en.wikipedia.org/wiki/Luhn_algorithm for details

Typing the wrong credit card number would be a legitimate error, not evidence of fraud. You can show that error. It won't affect how you deal with the actual fraud.

Hey bemmu, your presentation last year at Hacker News Kansai was really interesting, and I learned a lot. Thanks for putting the time into following up!

This article does not solve anything. Only thing I have found working is 3D security request for VISA cards.

I use chargebee so much better and cheaper than recurly

the problem is credit cards. the should be depricated

http://d.pr/i/x0JD+ vs http://d.pr/i/16wJh+

Not sure what the rules are, but I thought it might help.

Reply on news.ycombinator.com