Preventing online payment fraud
binpress.comThis article is amazingly worth your time. Endorsement out of the way I have one quibble and some elaboration:
I don't exactly love conflating buyer's remorse with payment fraud, since buyer's remorse is a psychological phenomenon and happens independently of fraudulent intent. Then again that's a bit hairsplitting.
So, you're a digital goods business. What can you do to reduce the odds that a customer requests a transaction get reversed, given that the customer initially did authorize the transaction?
1) Do nothing. Treat this as a cost of doing business. This works astounding well for many client populations, which have naturally low refund rates. (I'll give you a refund for any reason whatsoever, and I give out substantially less than 2%. Not worth optimizing.)
But maybe you've made the decision to target poor customers, startups, infovores (they buy more books/videos/etc on X than they can consume or make effective use of, and have disproportionately high refund rates), or an audience demographically dissimilar to American housewives. OK, we still have options:
2) Add value to the one-time download by, e.g., providing a support channel gated on having an account in good standing. Note that this also lets you do fantastically lucrative things like e.g. the club model for digital goods (recurring payment for one-time downloads), which e.g. put WooThemes on the map.
3) For infovore-heavy niches, many people will suggest forcing delayed gratification on the customer. For example, let's say you have just sold someone 5 videos / ebooks / etc with expected consumption time of 2 hours each. Rather than hitting them with 10 hours of video all at once, you drip them out to the user at 2 hours per week for 5 weeks. This can be timed such that they don't get the final video until after your money-back guarantee expires. That's totally optional, though. The theory is that a) you avoid overwhelming people and b) getting in their inbox 5 times with announcements of even more value they got from you helps to prevent a common problem of "Oh, didn't actually have enough time to read/watch/act on that because I totally forgot to make that time, guess I should return it."
4) A lot of savvier folks in this space have customer communities where a) the interaction between customers adds value on top of the product, b) desire to maintain the interaction incentivizes people to not leave, and c) customers will (for their own reasons) do significant amounts of boring work for free, such that you don't have to add a not-so-lucrative "Infinite free support" sideline to a lucrative digital goods business.
5) Too late for you now, but for the benefit of everyone else, a great way to avoid getting emails by someone whining about getting a refund for the $8 they spent on your ebook is to never ever ever ever ever do business with people at the $8 price point. SearchHN [patio11 pathological customers] for more on this.
Fantastic and informative comment, as usual. That said:
"a great way to avoid getting emails by someone whining about getting a refund for the $8 they spent on your ebook is to never ever ever ever ever do business with people at the $8 price point."
I have one of those "yes, if," or "no, but" reactions to this statement. If you're doing business at the $8 price point, you should be doing it in the volume business. The scale business. A gazillion tiny purchases at $8 apiece, wherein the userbase is large and fairly undemanding. If the userbase is demanding about anything in this space, you want it to be demanding about price alone, and you want your $8 to be an insanely competitive price.
You should NOT do business at $8 per transaction if your good or service involves a lot of transaction costs -- whether in post-sale servicing, a salesforce of any kind, high-touch / personal presales, high return rates, or, generally speaking, any sort of customization that can't be automated to scale. In very simplistic terms, low prices should not be paired with high costs -- be they high COGS in the traditional sense, or high intensity of time and effort. In the case of most ebooks, I would agree with you here: a low unit cost like $8 [1], positioned to a very demanding niche audience, is a recipe for nightmares.
[1] Temporarily leaving aside, for the sake of everyone's collective sanity, any tangential philosophical debate about whether $8 is a "low" price.
[1] Temporarily leaving aside, for the sake of everyone's collective sanity, any tangential philosophical debate about whether $8 is a "low" price.
Here's a question: we all know about reducing the price point to garner more sales, and therefore more profit; has anyone done similar studies on what price point elicits the least number of refunds (especially due to buyer's remorse)? $8 seems "low" to me, but only for some items; I suspect that most eBooks wouldn't meet this criteria (although I have payed an order of magnitude more for eBooks and still have a minimal Safari subscription). An eBook at $0.99 I wouldn't see the point in getting a refund, no matter how easy it would be to get it. If it was a really bad book, I might go after the refund just to make a point, however.
I have no idea how this is working with the app store but I know that on the Android play store to request refund was not simple. Now you'll have to get out of your comfort zone for let's say $0.99-3.99 - something you wouldn't even consider (your time is more valuable). Disputing that charge is even much more a time sink than asking for a refund as you would have to probably sign on several forms and fax them back to your credit card company, then you always have the possible cost of the chargeback being denied (I know my CC impose a penalty of $10).
I would say anything beyond $10-20 would be worth figthing. Of course it depends on where you are located (I would imagine someone in a poor country more likely to fight for a $5 refund than in a rich country), and your socioeconomic class (as I would imagine that a 18 unemployed year old would more likely ask for a refund than a 45 year old professor at Standford).
Just my 2 cents.
I am the author of the article - thanks for the positive overall comment. I agree with you to a point regarding "buyer's remorse" - perhaps I didn't word it strongly enough.
For some products, what you say makes perfect sense, but for us, since what we sell are code licenses, you can't 'undo' what you learned by using the code. Regardless, we offer 14-day money-back guarantee, and people still sometimes choose to take this approach - issuing a chargeback on their transaction, when it's obviously not regular fraud.
We usually try to communicate with the buyer to understand why he issued a chargeback, and in a few cases we managed to resolve it (so I would never suggest going with your first approach - always try and contact them first). Otherwise we just "eat" the cost and get on with it.
Loved the write-up. If you expand outside paypal/ccs into other methods like direct debits (common for Germany) I would be curious to hear similar stories. Accidental chargeback rates are way up on direct debits so any stories for dealing with that efficiently would be very interesting.
One thing I didn't really see was "previous successful purchase" - that should be a strong indicator of "not fraud". Even if other details look dodgy.
Not sure if "previous successful purchase" is enough of an indicator. If someone can hijack a Paypal account or obtain sensitive credit-card details, you should assume he can also hijack an account on your service.
Glad you liked it, we had to learn most of this stuff the hard way :)
Yeah they for sure can. They just don't tend to bother I think. Hijacking an account and the payment method used to pay on that account to go with it is a lot of work to do something you can do with less work.
May be business dependent tho. I guess selling source code means the people interested in defrauding you are fairly tech savvy too.
And yes, really liked it :)
If you expand outside paypal/ccs into other methods like direct debits (common for Germany) I would be curious to hear similar stories. Accidental chargeback rates are way up on direct debits so any stories for dealing with that efficiently would be very interesting.
Would you mind expanding on this, please? We're looking at different payment possibilities for a start-up and direct debits is one method that we are considering. This is the first time I've heard of a much higher chargeback rate on such transactions, though.
If you are using direct debits you have no way of pulling the money directly from the account - you will always have some serious lag (day or two at least, often more). In that time you don't have a hold or similar on the funds, so either you delay giving product to customer or you have a few days where you trust him to actually have the funds available when your claim hits his bank. If he doesn't actually have funds at that time you effectively have a chargeback (no funds were actually available to take in the first place). Usually these are honest mistakes, especially if you do recurring billing that the customer may forget, but it's costly and time consuming to explain what happened and have the customers pay you again for something they actually want.
Thanks, that makes a lot of sense. Innocent mistakes we can deal with. I was more worried about a high rate of formal disputes where customers might claim we took money fraudulently. It sounds like a track record full of that sort of thing can make it harder to get good terms in the future, and I didn't see why that should be significantly higher with one form of payment than another.
This article has great advice. I work on fraud detection, and a lot of companies start off by building basic checks like AVS, CVV, proxies, IP-billing location mismatch, etc. What usually happens afterward is that the fraudsters get more clever. For example, we've seen sites implement SMS verification, but then the fraudsters will set up Twilio phone numbers to fool it. The sites block IPs, but then fraudsters go through an internet cafe or proxy. Sites shut down one account, and the fraudsters rent a bot net and run scripts to create a thousand more. It's a cat and mouse game.
Companies where payments are central (e.g., PayPal, Square) end up building some combination of machine learning, investigation tools, a dedicated operations team to review/verify suspicious transactions, and custom logic to look at all sorts of signals correlated with fraud. Often they'll have dozens or hundreds of people working on this.
For everybody else, I'd echo Eran's advice to just outsource this. There are plenty of vendors out there. Here's one list: https://www.merchantriskcouncil.org/index.cfm?pageId=702
If anybody out there is dealing with fraud or chargebacks, my company (Sift Science) provides an API to do exactly the checks Eran's article suggests and a lot more. Even if our technology doesn't apply, I'm happy to just give advice and point people in the right direction. My e-mail is brandon@siftscience.com.
Given that my startup is heading towards an area with a historically high rate of chargebacks and I was facing the nightmare of fraud detection, this particular article is like a nugget of solid gold that has descended from the clouds with a heavenly host providing choral music.
Thankyou.
Online fraud is expected to grow substantially in the near future, as e-commerce and CNP (card not present) transactions are expected to grow exponentially in relation to offline (or Card present).
With card issuers planning to issue Chip cards (to stay in compliance with Visa's EMV Mandate), fraud will shift from retail to Online (where Chip offers no additional protection), as it has already happened in Europe with the EMV shift there.
It's a good article. I'd like to add two other things you should consider when handling credit cards.
The first is 3DSecure (or VbV). They are the most secure ways to accept credit cards, though they aren't as easy for users to use. However, they do go a long way to protecting the merchant. If your handling b2b transactions that are high risk, you might consider enforcing this. Again, it's not a solution to wield lightly, but it is a solution.
Also, you can require out-of-band authentication. Generally, this is in the way of making a telephone call, and requiring the user to input a 4-digit pin. This, combined with everything else, will help hinder potential fraud. More importantly, it helps to protect against friendly fraud.
Of the two, telephone authentication is easiest to implement, but do not discount 3DS for higher priced purchases.
Counterpoint: the only businesses that force VbV etc. I will deal with are airlines (because they all do), which meant the last time I flew transatlantic I took 800 euro out of my bank account and _walked_ to Air France's bank rather than use it. In _any_ other industry? They've just given my business to a competitor.
It is not in my interest to use a service _designed_ to lessen my protection from fraud.
(see http://www.lightbluetouchpaper.org/2010/01/26/how-online-car...)
I know it's been a few days, but, just wanted to add that this is a good point, and a part of what I meant with not using VbV lightly. There are valid reasons to use it, but frankly, it should be close to the last thing you implement.
The only times I've used it where when offering a b2b product/service where fraud was a real fraud.
The Minfraud service I mention in the article has an automatic phone verification system. You can use it when the risk score crosses a certain threshold
Take a look at realtime device identification and shared reputation services. This allows you to uniquely identify the end user devices accessing your site and assess their reputation and fraud history across a shared network of intelligence. Services like http://www.iovation.com are massively effective at fighting fraud.
Good collection of advice- very help.
I use Cybersource for payment processing on an e-commerce site. I've been really happy with their fraud screening service- automated rules, similar to the list in this post, flag certain orders for manual review. These automated rules have been able to catch orders that, otherwise, might have gone unnoticed and saved a lot of time in the process.
Very relevant. I was listening on Mixergy about how BrandStack shut down because of credit card fraud. For anyone contemplating building a marketplace, for heaven's sake, outsource this.
For digital sites like BinPress, an automated capture of a photo via a web cam might be sufficient to deter fraudsters. Anyone care to build something like this?
Well, I am thinking of selling goods in the future. It'll be bank transfers or bitcoins. Simple.
add: if someone worries about if I have the goods or will ship, I'll offer to take a photo of me holding them next to that day's newspaper and have some testimonials up on the site. Simple.
Some bank transfers can be reversed.
Well, I think having proof of shipping to show bank, customer or police would help too if one is notified of a dispute - that itself should be a deterrent for pathological customers.