14 ms·

Candy Japan hit with credit card fraud

293 points by bemmu 11y ago

scurvy 11y ago
The one-time card numbers generated by the old AMEX Blue system were great for shopping on sites you didn't trust. Too bad that they dumped that and the card reader system around 2002-2003? I really liked it and felt much more confident using it. Seems like it would have cut down on fraud a lot more than many systems in use. That said, I really don't know why anyone would want to try and write their own payment integration gateways nowadays. There are so many good alternatives out there. Why not use them? You should focus on what you love, not payment processing. If you're just selling simple goods, you can easily setup a store on Shopify, Weebly, WIX, etc. Let them handle the fraud stuff. Sure, you might be on the hook for a few bad charges here and there, but at least you didn't waste hours writing payment code.
- caffeinewriter 11y ago
  I just started using Blur by Abine, which allows something similar. (Basically, you can fund prepaid cards to use on sites rather than giving out your real card) not an outright endorsement. I haven't used them for long enough to give a definitive answer on if they're good, but it costs $40/year plus $2 for each "masked card". So far it's worked for me. I definitely agree no Dev should write their own gateway. There are great ones out there who are developed by people who are paid to do nothing but that.
- ars 11y ago
  They still exist, Bank of America has it. https://en.wikipedia.org/wiki/Controlled_payment_number https://en.wikipedia.org/wiki/Controlled_payment_number
scurvy 11y ago
One other tip: Block all TOR exit node IP's. You'll find mostly fraud and spam coming from them. Deep down, I would love to support TOR in principle. I know there are people living in oppressive regimes that need access to information. I want to support that side of TOR. In reality it's still the transport tunnel of choice for scammers and criminals. The costs just don't outweigh the benefits. Considering the CDNs that block TOR (Akamai, Cloudflare, Incapsula, etc), you wouldn't be the only one blocking TOR. I'd also throw in EC2, GCE, Azure, and Rackspace IP's too.
- jandrese 11y ago
  Hopefully nobody is living in a regime so strict they can't order candy delivery without fearing for their life.
  - scurvy 11y ago
    Never underestimate how far San Francisco will go to impose its will.
dandare 11y ago
TIL Stripe does not come up with built in fraud protection.
chadscira 11y ago
One thing you can do is make the account creation process more difficult, maybe require phone verification, or social auth. It would tie a fixed value to each bad attempt for the fraudster.
kweks 11y ago
We ran an online store selling merchandise for a very large mobile-game vendor, so naturally we experienced these types of fraud attempts. For us, there's one killer technique. Detect fraud however you want to / can (this can be a mix of heuristic data from your stats, third party, or whatever you want) - but when you detect it - don't decline the user. Send them to a fake purchase confirmation page. Suddenly they'll be getting 100% success from your site, and they'll drop you immediately. On the backend, put the transaction to manual approval, so if it IS a legitimate client, when they email you, you can manually approve the order. Over the years, as others have pointed out, detection methods change, but using the above technique invalidates their reasons test with your site. (very similar to Mailinator's technique for people scraping their site.. http://mailinator.blogspot.fr/2011/05/how-to-get-gmailcom-banned-not-that-i.html http://mailinator.blogspot.fr/2011/05/how-to-get-gmailcom-ba... )
- cobrabyte 11y ago
  I think Amazon does this. Regardless of whether the payment goes through or not, you'll always reach an 'order confirmed' page. Looks like they've adopted the same technique for curbing fraudulent purchases.
ubersync 11y ago
Unjustified credit card fees and the financial/psychological burden of chargebacks (resulting from uncontrollable credit card fraud) are the main reasons why I want the Bitcoin experiment to succeed. Lets give Bitcoin some love where it deserves.
hias 11y ago
Sorry that you have to deal with fraud and loose money! Could you start shipping biscuits or chocolate candy again, I am a bit disappointed with the stuff you currently include in your packages :-(
- bemmu 11y ago
  Thanks for the feedback. Chocolates are not so good to send in this weather (melt risk), will start including those again during colder months.
imaginenore 11y ago
That's why the whole credit card system is insane. 1) It's a pull instead of a push. Anybody with your CC details can attempt to charge it. Bitcoin model is much more sane. 2) There's not even a "approve the charge" option. 3) The cartels controlling the credit card systems charge insane amounts of money for transactions, attempted or real. I really want Bitcoin or some other alternative to succeed.
- ubersync 11y ago
  Exactly. I hope we will see a world soon, where Bitcoin (or another cryptocurrency) is as ubiquitous as credit cards now. Transaction fees for a failed credit card payment? Its more than insane.
nchelluri 11y ago
Interestingly enough I found this subthread from an HN Post earlier today to be very relevant: https://news.ycombinator.com/item?id=10234561 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 is too high, I void the auth and decline the transaction. This has saved me a lot of chargeback fees, though it's still not perfect. I prefer PayPal because a "not authorized" just reverses the transaction; there is no chargeback fee. - Osiris (HN user) IMO, there's more worth reading in that subthread. It's an interesting topic, at least to me. I feel sympathy for any merchant that has to go through this kind of pain.
- Osiris 11y ago
  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 sales but just assumed it was a good day. When the first chargeback came through, I immediately noticed the problem, bought more credits, then began to go through each transaction one and a time and noticed a pattern in the email addresses (all two words followed by 3 numbers @hotmail.com) and individually refunded each and every one of them. I still got chargebacks but I was able to dispute them by showing that the transaction had already been refunded. 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. On a side note, I found that nearly all of my fraudulent purchases came from Vietnam to the point that at one time I put in an IPTABLES rule to block the entire country.
  - bemmu 11y ago
    All of mine seemed to come from Mexico. Either IP being in Mexico or the shipping address being there. Still many orders originating from Mexico seemed like they might be genuine, as the customers had filled in the questionnaire with their favorite animes etc. valid looking answers, so I didn't want to block the entire country. My theory is that there really was some kind of media mention there, which resulted in some real orders but also some fraudster happened to hear about the service that way as well. it seemed possible that I had been mentioned in some local
quaunaut 11y ago
Second article in one day mentioning how bad credit card fraud can be to handle, especially for smaller sites. I wonder if there might be an opportunity there? Or if the solutions have to be so custom that it'd be impossible to work out.
- foota 11y ago
  From the article, it sounds like they are working in using an existing fraud detection service, would be interesting to see what goes into that sort of service.
  - Reason077 11y ago
    Presumably, it would at least involve implementing "Verified by Visa", which protects online transactions by requiring a password or PIN. Mastercard and Amex have equivalent services, and these are all widely implemented by websites and card issuers in Europe and other countries. I suppose they are not so widely deployed in the USA or Japan, but at the very least, you'd protect yourself against fraud involving cards issued in countries that do use it. http://www.visaeurope.com/making-payments/verified-by-visa/ http://www.visaeurope.com/making-payments/verified-by-visa/
    - foota 11y ago
      I'm obviously not an expert, but is there a way to require someone to enter the pin that they use when they buy something in person? (I also found the following FAQ from the link you gave amusing "Why do we need Verified by Visa? Hasn’t Visa been taking my security seriously before?")
      - Reason077 11y ago
        The actual authentication mechanism is left up to the card issuer. But using the card's PIN would be considered insecure due to the risk of malware/key-loggers intercepting it. My bank asks for three random characters from my online banking password (the same mechanism used to log in to my online banking) which provides enough security without risk of revealing the full password to key-loggers.
maaaats 11y ago
Shouldn't the credit card companies be the ones to handle the loss?
- jib 11y ago
  You would wish so:). But no. Merchants are on the hook for all costs, including penalties for incoveniencing the cc companies (either a set fee per fraudulent transaction, or high fees if exceeding thresholds of fraud if you are a larger guy).
byron_fast 11y ago
Clearly, card companies are going to have to adjust their policies for failed transactions. It's not like it costs real money to decline a fraud attempt; stop punishing merchants.
- stevoski 11y ago
  Alternatively, small companies started by developers should stop thinking they can implement the payment and order handling code themselves, and learn that instead they should use a service that does this for them.
- angusb 11y ago
  Yeah, I agree. I guess their argument is that it's difficult to catch every single fraud attempt, and in this case the behaviour was just not picked up by the processor's inbuilt fraud detection systems. Still, it should be the processor's responsibility. GoCardless (Direct Debit, EU only at the moment) is one company that doesn't charge a fee for chargebacks. They take on all the risk themselves.
- byron_fast 11y ago
  My experience with card company fraud detection systems is that they were bafflingly useless. Maybe they've gotten better recently. But even Stripe seems to let through things that are obvious fraud, stuff that wouldn't pass a basic spam filter. It's almost like they want to charge you those fees!
markgavalda 11y ago
Currently we're integrating Sift Science to avoid this otherwise serious and annoying issue. I think it happens to everyone who's directly accepting credit cards online. Does anyone have experience with Sift Science or similar services? (I know MaxMind has one but that, to me, seems inferior to SS's.)
- beilabs 11y ago
  Came here to recommend a sift science type solution. I've previously integrated fraud systems like Cybersource (clunky interface, wouldn't recommend)
  - jasontan 11y ago
    Thank you for the recommendation!
- jasontan 11y ago
  Hi Mark, CEO of Sift Science here. Thanks for giving us a shot. Please don't hesitate to ping me if you need any help or we're not delivering to your expectations. jason at siftscience dot com
_Codemonkeyism 11y ago
From my experience running eCommerce sites, the author is right, beside fraud 'noise', fraud happens in waves.
- bemmu 11y ago
  That was my mistake, assuming that since I was OK with the noise, everything is fine. Didn't know about the fraud tsunamis.
  - _Codemonkeyism 11y ago
    Was stunned two when hit the first time by such a tsunami. Your blog post is great, don't think this is common knowledge.
dubrocks 11y ago
Would verifying zip codes mitigate this issue, or do the carders have access to that too?
- frgewut 11y ago
  ZIP codes seem to be a US-specific thing.
  - vacri 11y ago
    ZIP codes are just a funny name for post codes, and most places have postcodes.
    - junto 11y ago
      Damn you Ireland and your "no postcodes" hell.
      - jib 11y ago
        We have postcodes now! Or well, eircodes. Which are totally not postcodes, but rather unique house identifiers that happen to look as postcodes. And that noone will use. http://www.eircode.ie/ http://www.eircode.ie/
    - germanier 11y ago
      While many places have postcodes, most don't have postcode validation for credit card transactions. And it wouldn't really help to combat fraud anyway.
- deleted 11y ago
  [deleted]
- PeterisP 11y ago
  Sometimes they do also have address information, sometimes they don't. As with everything, it will reduce the amount a fraud a bit but not eliminate it.
alpb 11y ago
I wonder would that still be the case if Candy Japan was using something like Stripe or Balanced, what happens in that situation? Would you be still responsible for 15 EUR chargeback fee? What did Recurly do in this case?
- huhtenberg 11y ago
  With Stripe you are still responsible for the chargeback fee, but they do not charge you for transactions that don't go through. They also have some fraud protection, but it did pass some obvious fraud in our case.
- bhelx 11y ago
  This depends on the gateway you use. Recurly can't do much but refer you to the gateway in this case.
veb 11y ago
Damn shame to hear about this Bemmu -- would've felt like a massive punch to your guts! Maybe you should set yourself up some email alerts when things seem 'off'. i.e. no referral, and the user/bot spends no time filling out the form and hitting submit. What's your glue code like? I'm rootin' for ya. :-)
- bemmu 11y ago
  Hey veb, This fraud would have been easy to detect if there had been any kind of detection system in place. But I had no fraud checking, captcha or 3-D secure, as I hadn't expected there to such a "fraud wave". Those payments didn't feel like necessarily coming from a bot, as there were time delays and for many purchases they even filled in the questionnaire. It felt more like someone had a pile of numbers they were entering manually. My form made that easy to do, as I had tried to eliminate any field which wasn't absolutely necessary.
  - unclebucknasty 11y ago
    >...they were entering manually Definitely wouldn't discount that possibility. Unrelated to CC processing, but we used a service that gave us a device ID on signups to detect people signing up multiple times (a tipoff that fraud was likely to come). We later found fraudsters were using Amazon's Mechanical Turk to get real people to register manually, thus getting around our device detection.
peterhunt 11y ago
This is something we (www.smyte.com) can help out with -- send me an email at pete at smyte dot com if interested. Also happy to answer any questions about general mitigation techniques.
- sdrothrock 11y ago
  I tried to go to your site but am getting a 500 error. Edit: Interestingly enough, www.smyte.com is fine, but smyte.com yields the 500 error.
  - peterhunt 11y ago
    Yes, odd issue with our dns, link corrected.
- mootothemax 11y ago
  Your site appears to be down right now, otherwise I'd hunt for info there :) What's the difference between you and Sift, and what advantages do you offer over them? Edit: your T&Cs and privacy policy pages referring to a different site entirely don't exactly fill me with confidence :-/
  - peterhunt 11y ago
    All the docs refer to the legal entity, not the brand, which may be causing some confusion. Happy to chat more about specific use cases over a medium that's better suited to it; mind shooting me an email? pete at smyte dot com
    - mootothemax 11y ago
      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 email :-)
sjwhitworth 11y ago
We at Ravelin (https://www.ravelin.com https://www.ravelin.com) are building solutions to stop this. Still surprises me how many people think banks/schemes are responsible for CC fraud, when it's actually the merchant that gets punished. And yeah, fraudsters operate like locusts.
- jbombadil 11y ago
  I don't understand why does the merchant have to pay the 15 fee. It sounds to me the entity that should handle the loss of fraud is the bank.
  - sjwhitworth 11y ago
    Blame the lack of competition in the international payments system I guess.
Animats 11y ago
But why? Ordering periodic shipments of candy from Japan? Most credit card fraud involves something that can be resold. This service gets you a small envelope of candy. It's not like getting cases of Pocky.
- hkmurakami 11y ago
  " The stolen cards originate from credit card security breaches, resulting in a big list of card numbers. These are later sold online in packs filtered to working card numbers only, which can be purchased for about $10 per valid card. To be able to compile and sell these packs, the carders need to know which ones are valid. To do this, they will use an online store or service to place an order for the sole purpose of seeing if the charge goes through or not.
- lordnacho 11y ago
  Test on one site, buy something substantial on another?
stanleydrew 11y ago
This sucks and can often be a crippling blow for a small business if it's not caught early. I remember we used to deal with a lot of this at Twilio, except the carders would then also try to cash out the credit card into Twilio credit. The pattern was try to spend $10 on a card, then one minute later try to spend $1000 once the first charge went through. But it's a lot less costly than toll fraud, which I learned the hard way working on our auth system at https://charge.co https://charge.co.
sapereaude 11y ago
Did you considered to accept Bitcoin payments? This way you wouldn't have to worry about chargebacks.
- eljamon 11y ago
  Bitcoin is not the best thing for recurring payment. But it would be great to pay a year in advance with Bitcoin - and yes that solves chargebacks or fraud issues.
- joosters 11y ago
  To avoid the credit card fraud, they'd have to only offer Bitcoin as a payment option. And that would be financial suicide.
lordnacho 11y ago
I don't understand the search conversion statistic. If a guy is testing a bunch of cards, wouldn't he just find your site once and try them all sequentially? If a bunch of people had bought these packs of stolen cards, wouldn't they be spreading out over a bunch of different sites?
- PeterisP 11y ago
  The automated scripts that the criminals use will try to simulate a real customer signup and transaction, otherwise it's too trivial to filter them out. This is also why fraud detection is a big industry, you basically need full time staff to analyze the current types of fraudulent transactions and update your filters as fast as the criminals update their systems.
hieudang9 11y ago
Even PayPal or Google faced up to fraud. You can try Maxmind or manual check every order. Contact me to more solutions.
marme 11y ago
i simple solution to cut down on this is never allow more than 2 or 3 failed card attempt from a single ip address. You have to link it by ip because they will just make a new account if you do it by account. Carder will move on to another site if running cards is not simple and fast
stevoski 11y ago
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 various alternative payment options popular in, say, Holland. (Yes, this is a thing, and it is called iDEAL.) Your code will sooner or later be exposed to a campaign of fraudulent transactions. Use FastSpring, or your alternative of choice. Yes, it costs more, if you don't put value on your weeks of time to create and support an alternative, and if are comfortable having a weak fraud detection, if any. When your business becomes successful, when the fees to FastSpring start to dwarf the costs of implementing a payment system yourself, then - perhaps - consider re-doing it yourself. There are indeed weaknesses in using FastSpring, which after seven years are becoming a pain for me. I'll be writing about that soon. But this is not an issue for a one-person endeavor getting started.
- nulltype 11y ago
  How is FastSpring different from using Stripe.js or Checkout? Both claim "automatic fraud detection".
- bhelx 11y ago
  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.
  - djm_ 11y ago
    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.
    - bhelx 11y ago
      I'm an engineer so I can't really give you an ETA in public. You could certainly talk to one of our sales or product people about it. The thing you need to remember is that you do have options. If you choose a gateway with good fraud tools, or a gateway that integrates with them, we upstream that information to you. Traditionally Recurly has left fraud up to the gateway because they are much better at dealing with it, but we are now seeing the need to offer some more professional fraud tools by default at the Recurly level. Feel free to email me if you want to have a discussion about it: ben@recurly.com
jasontan 11y ago
We at Sift Science (http://siftscience.com http://siftscience.com) might be able to help. Feel free to email me at jason at siftscience dot com Even if you don't use us, we published some articles to help merchants new to dealing with fraud: * https://siftscience.com/sift-edu/fraud-basics https://siftscience.com/sift-edu/fraud-basics * https://siftscience.com/sift-edu/prevent-fraud https://siftscience.com/sift-edu/prevent-fraud
- adrianmacneil 11y ago
  Sift Science is a great service, I would highly recommend testing it out.
  - jasontan 11y ago
    Thanks for the kind words.
jasonkester 11y ago
I had something similar happen with one of my services. I have an "Update your Payment Details" page for paid subscribers that lets them enter new card details when their old card expires or they just want to switch the card they're using with us. It normally gets used a few times a month, and anywhere from zero to one time over the lifetime of a customer. But then the bad guys found it. And individual users started updating their card details dozens of times each day. This went on for several days before I noticed it in the logs. It was easy enough to fix: users now get one update per year, unless they email me and ask what's wrong with that card update page. The bad guys moved on to greener pastures and life went back to normal.
2muchcoffeeman 11y ago
Couldn't you do a preauth on the cards and then completion when you are ready to ship? At least then you don't get hit with chargebacks.
- nulltype 11y ago
  Last time I talked with a credit card company, they wouldn't even let me file a chargeback until 30 days after the transaction. How would this stop chargebacks?
  - 2muchcoffeeman 11y ago
    A preauth on a card reserves the credit without actually completing the transaction. The credit is still there but not available for use. You can complete the transaction by sending a 'completion' request, at which point the credit is gone. The preauth also has an expiry. If the preauth expires, the funds are released with no transaction taking place. So when a user signs up, take a preauth. If you have any reporting on your sales, like this guy, you can check for any anomalies before fulfilling orders. Anything that looks odd, don't complete the order.
watchdogtimer 11y ago
Braintree offers "advanced fraud protection" if you pass device information along with the transaction request [1]. Has anyone tried using this, and if so, is it effective at stopping this problem? [1] https://articles.braintreepayments.com/guides/fraud-tools/overview#fraud-tool-comparison https://articles.braintreepayments.com/guides/fraud-tools/ov...
ck2 11y ago
What about services like maxmind-fraud and the like that authenticate buyers? Are they too expensive per purchase?
fredleblanc 11y ago
I also had something like this happen on a site I built for my wife's work's site, a Boys & Girls Club[0]. I had a donation button that let people make an open donation to the club. It's such a tiny site with little traffic, but apparently the SEO must be decent because somehow it got targeted by people appearing to come through Brazil and Poland. Suddenly one day, hundreds of donation attempts. Checking the failed transactions, the script was trying $1, then $2, etc up to $22 then starting over, each time with a different number. About $200 in successful donations came through before I caught it. So I just shut it all down for now. I'm not really sure how best to fix it. The club has no money and already complain about the transaction fees they get charged per swipe (and those are all pretty standard rates in the U.S.). Being a non-profit, they expect a lot of stuff for free, and unfortunately won't consider paying for an anti-fraud service. Even PayPal takes too big a cut. Realizing that this wasn't a helpful comment, just a "me too." It sucks. Oh well. [0]: https://salembgc.org https://salembgc.org
- imjk 11y ago
  How can they not be willing to pay a transaction fee from even PayPal for donations? Seems their options right now is to take donations via a service like Paypal with a transaction fee, or just take no donation.
  - pc86 11y ago
    You would be surprised at how unreasonable people can be once you start talking about taking a percentage of money they get (be it donations or business revenue or something else). It's the financial equivalent of having a tumor that will kill you and refusing the surgery because the doctor says you have a chance of dying on the table.
  - fredleblanc 11y ago
    I don't want to speak for them or go into their financials, but in a literal sense, every dollar counts. When we were talking about taking donations and registrations online, they were frazzled about the transaction fees, and I suggested working them into the costs. (It was only, say a $3 increase in membership price.) The truth of the matter is that some people don't have that much to spare. Of course, that conversation happened way before the site was used as a credit card validator. Trying to explain to them the bad side of charge backs and why this is a big deal is an on-going challenge. The last time I discussed it with them, they kept asking me if they were going to get stuck with all the transaction fees. And, being a developer, my first gut instinct is stepping back and saying "you're wasting money here and here and here and here, cut down these inefficiencies and it'll all balance out." However, it's not as simple as that. Everyone needs to be on board, and the people in charge of these things are already overworked and not highly paid. A catch-22, I suppose. I try to stay out of it as best I can. I made them the site for free in exchange for our two kids to use the club's stuff for free, and with those inefficiencies I hinted at, I can't afford to get caught in being the role of business consultant too.
ryanlol 11y ago
Unless there's some bug in your transaction processing system causing it to leak excessive amounts of data on why the transaction was denied it makes no sense for checkers to use it over their own merchant accounts. (And typical checker traffic is more like thousands of transactions rather than tens) It seems much much more likely that someone was just trying to card some candy.
bemmu 11y ago
I just added in an anecdote that I forgot to mention at first. Encounter with a police officer. Starts from "After starting to deal with this..."
umziehennachbar 11y ago
1. How many sales would you lose if you required everyone to use PayPal everytime? 2. (What about Google cash? or Square cash?)
- bemmu 11y ago
  It's difficult to test, because by not having credit cards a lot of fake orders are now excluded, lowering the conversion ratio that way. So if I did a test of showing only PayPal to half of customers and PayPal + credit cards to half, the one with CC could win just because of the fake sales.
  - umziehennachbar 11y ago
    I guess what I mean is, "do people really need the credit card option? If you just demand they use PayPal and they want your unique service, then they'll find a way to pay".
meshr 11y ago
As I can see all solutions listed in this thread is to protect yourself better and let fraud happens for less protected merchants. The real solution is to fight back against fraud. All fraud attempts must be recorded in the public space, for example http://fraudrecord.com/ http://fraudrecord.com/ . The best solution is to have something like open blockchain Grossbuch for fraud. What are current best solution for FIGHTING BACK AGAINST FRAUD?
umziehennachbar 11y ago
What about using the Twitter "buy" button now? Is it vulnerable to the same type of fraud? See this example https://twitter.com/mperham/status/643480319870369792 https://twitter.com/mperham/status/643480319870369792
ChuckMcM 11y ago
Another interesting problem is that recent breaches have put so many cards in the carding market that clearing them seems to have become a bottleneck. If we could some how work with the banks to perhaps create honeypots for these people it might help us clean up the mess.
slv77 11y ago
Been working in e-commerce fraud for ten years... The credit card security model is broken as designed with the exception of chip and pin and chip and signature. Uptake for 3D Secure is uneven around the globe. Some places it is mandatory and others unheard of. For example not using it will negatively impact close rates in India but using it in the U.S. will negatively impact close rates. With 3D Secure each issuing bank was responsible for how they implemented the process and it varies widely in both ease of use and security between issuing banks. Some banks may use simple passwords that can be fished while others may use one time pins sent by SMS to your mobile. When a merchant uses 3D Secure fraud liability shifts to the issuing bank and the merchant gets a discount on the interchange. This is also true when the bank hasn't implemented 3D Secure or has done so poorly. Because of this when 3D Secure was launched some banks put out systems that were non-functional simply to avoid the liability shift (i.e. it would prompt for a password but there was no functionality to create one). Issuing banks have gotten their act together in the last decade but it's still uneven. Even when a merchant implement 3D Secure the merchant still needs to manage fraud levels to card association rules even though the merchant does not have liability for the fraud. This is the "we have to assume the risk but we don't have to do business with you clause." Individual issuing banks may chose to decline all of a merchants transactions if loss rates are unacceptable and the merchant may still lose their merchant account if overall loss rates are too high. However because the charge back shifts to the banks the merchant may not even know which transactions are fraudulent. Recently rules have been changed so that banks aren't required to prompt for authentication in all cases. This is called risk-based-3D secure. So even if Candy Japan had implemented it he still may have seen the attack because the banks may not prompt for that low of an amount. He wouldn't be out the money but still may be in trouble with the association if he didn't do something to stop the attack. When looking at automation there are two fundamental risk that any solution needs to address. The first one is class separation which in the industry is known as scoring or out-sorting. In this area machine learning algorithms are well understood and there are a few companies on the market that will rent merchants a model such as Sift Science or MaxMind. The second one is anomaly detection and in the industry this is know as velocity control. The problem is similar to detecting a hacker once they have penetrated the network, detecting a bio-terror attack based on hospitalization data or detecting insiders who have flipped. These types of things have generated a lot of military interest and a lot of DARPA funding but little of it has made it into the commercial market due to the high rate of false positives. Card testing is one example of a 'high velocity' attack and are usually the work of professionals. High velocity fraud has been more common with digital goods but more recently we've seen more high velocity attacks where an attacker will upload a merchants products on a site like Amazon or eBay. When the attacker gets a sales they will use stolen credit cards to get the trageted merchant to fulfill the order. Since these are professionals they generally will have tested the merchants fraud systems to understand what is considered low risk by the merchants fraud models and unless the merchant has some monitoring losses can be very high by the time the charge backs start coming in. Currently there is no automated, fool-proof method for managing these high velocity attacks that I'm aware of. Merchants initially started putting limits around the number of times that a single card could be used and the attackers responded with SQL injection attacks to get card in mass. Merchants responded with limits on email addresses or other data points and the attackers responded by mass registering emails on free email providers and registering their own domains. Merchants responded with limits on IP addresses and used of geo-ip location services and attackers responded with open proxies and VPNs. Merchants responded with limits on orders from co-location facilities and VPN providers and attackers responded by compromising end-user machines en-masse. Merchants responded with proxy detection and device fingerprinting and attackers responded with using RDP to end-user machines to launch attacks. And it continues.

293 points by bemmu 11y ago

The one-time card numbers generated by the old AMEX Blue system were great for shopping on sites you didn't trust. Too bad that they dumped that and the card reader system around 2002-2003? I really liked it and felt much more confident using it. Seems like it would have cut down on fraud a lot more than many systems in use. That said, I really don't know why anyone would want to try and write their own payment integration gateways nowadays. There are so many good alternatives out there. Why not use them? You should focus on what you love, not payment processing. If you're just selling simple goods, you can easily setup a store on Shopify, Weebly, WIX, etc. Let them handle the fraud stuff. Sure, you might be on the hook for a few bad charges here and there, but at least you didn't waste hours writing payment code.

caffeinewriter 11y ago
I just started using Blur by Abine, which allows something similar. (Basically, you can fund prepaid cards to use on sites rather than giving out your real card) not an outright endorsement. I haven't used them for long enough to give a definitive answer on if they're good, but it costs $40/year plus $2 for each "masked card". So far it's worked for me. I definitely agree no Dev should write their own gateway. There are great ones out there who are developed by people who are paid to do nothing but that.
ars 11y ago
They still exist, Bank of America has it. https://en.wikipedia.org/wiki/Controlled_payment_number https://en.wikipedia.org/wiki/Controlled_payment_number

scurvy 11y ago

One other tip: Block all TOR exit node IP's. You'll find mostly fraud and spam coming from them. Deep down, I would love to support TOR in principle. I know there are people living in oppressive regimes that need access to information. I want to support that side of TOR. In reality it's still the transport tunnel of choice for scammers and criminals. The costs just don't outweigh the benefits. Considering the CDNs that block TOR (Akamai, Cloudflare, Incapsula, etc), you wouldn't be the only one blocking TOR. I'd also throw in EC2, GCE, Azure, and Rackspace IP's too.

jandrese 11y ago
Hopefully nobody is living in a regime so strict they can't order candy delivery without fearing for their life.
- scurvy 11y ago
  Never underestimate how far San Francisco will go to impose its will.

dandare 11y ago

TIL Stripe does not come up with built in fraud protection.

chadscira 11y ago

One thing you can do is make the account creation process more difficult, maybe require phone verification, or social auth. It would tie a fixed value to each bad attempt for the fraudster.

kweks 11y ago

We ran an online store selling merchandise for a very large mobile-game vendor, so naturally we experienced these types of fraud attempts. For us, there's one killer technique. Detect fraud however you want to / can (this can be a mix of heuristic data from your stats, third party, or whatever you want) - but when you detect it - don't decline the user. Send them to a fake purchase confirmation page. Suddenly they'll be getting 100% success from your site, and they'll drop you immediately. On the backend, put the transaction to manual approval, so if it IS a legitimate client, when they email you, you can manually approve the order. Over the years, as others have pointed out, detection methods change, but using the above technique invalidates their reasons test with your site. (very similar to Mailinator's technique for people scraping their site.. http://mailinator.blogspot.fr/2011/05/how-to-get-gmailcom-banned-not-that-i.html http://mailinator.blogspot.fr/2011/05/how-to-get-gmailcom-ba... )

cobrabyte 11y ago
I think Amazon does this. Regardless of whether the payment goes through or not, you'll always reach an 'order confirmed' page. Looks like they've adopted the same technique for curbing fraudulent purchases.

ubersync 11y ago

Unjustified credit card fees and the financial/psychological burden of chargebacks (resulting from uncontrollable credit card fraud) are the main reasons why I want the Bitcoin experiment to succeed. Lets give Bitcoin some love where it deserves.

hias 11y ago

Sorry that you have to deal with fraud and loose money! Could you start shipping biscuits or chocolate candy again, I am a bit disappointed with the stuff you currently include in your packages :-(

bemmu 11y ago
Thanks for the feedback. Chocolates are not so good to send in this weather (melt risk), will start including those again during colder months.

imaginenore 11y ago

That's why the whole credit card system is insane. 1) It's a pull instead of a push. Anybody with your CC details can attempt to charge it. Bitcoin model is much more sane. 2) There's not even a "approve the charge" option. 3) The cartels controlling the credit card systems charge insane amounts of money for transactions, attempted or real. I really want Bitcoin or some other alternative to succeed.

ubersync 11y ago
Exactly. I hope we will see a world soon, where Bitcoin (or another cryptocurrency) is as ubiquitous as credit cards now. Transaction fees for a failed credit card payment? Its more than insane.

nchelluri 11y ago

Interestingly enough I found this subthread from an HN Post earlier today to be very relevant: https://news.ycombinator.com/item?id=10234561 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 is too high, I void the auth and decline the transaction. This has saved me a lot of chargeback fees, though it's still not perfect. I prefer PayPal because a "not authorized" just reverses the transaction; there is no chargeback fee. - Osiris (HN user) IMO, there's more worth reading in that subthread. It's an interesting topic, at least to me. I feel sympathy for any merchant that has to go through this kind of pain.

Osiris 11y ago
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 sales but just assumed it was a good day. When the first chargeback came through, I immediately noticed the problem, bought more credits, then began to go through each transaction one and a time and noticed a pattern in the email addresses (all two words followed by 3 numbers @hotmail.com) and individually refunded each and every one of them. I still got chargebacks but I was able to dispute them by showing that the transaction had already been refunded. 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. On a side note, I found that nearly all of my fraudulent purchases came from Vietnam to the point that at one time I put in an IPTABLES rule to block the entire country.
- bemmu 11y ago
  All of mine seemed to come from Mexico. Either IP being in Mexico or the shipping address being there. Still many orders originating from Mexico seemed like they might be genuine, as the customers had filled in the questionnaire with their favorite animes etc. valid looking answers, so I didn't want to block the entire country. My theory is that there really was some kind of media mention there, which resulted in some real orders but also some fraudster happened to hear about the service that way as well. it seemed possible that I had been mentioned in some local

quaunaut 11y ago

Second article in one day mentioning how bad credit card fraud can be to handle, especially for smaller sites. I wonder if there might be an opportunity there? Or if the solutions have to be so custom that it'd be impossible to work out.

foota 11y ago
From the article, it sounds like they are working in using an existing fraud detection service, would be interesting to see what goes into that sort of service.
- Reason077 11y ago
  Presumably, it would at least involve implementing "Verified by Visa", which protects online transactions by requiring a password or PIN. Mastercard and Amex have equivalent services, and these are all widely implemented by websites and card issuers in Europe and other countries. I suppose they are not so widely deployed in the USA or Japan, but at the very least, you'd protect yourself against fraud involving cards issued in countries that do use it. http://www.visaeurope.com/making-payments/verified-by-visa/ http://www.visaeurope.com/making-payments/verified-by-visa/
  - foota 11y ago
    I'm obviously not an expert, but is there a way to require someone to enter the pin that they use when they buy something in person? (I also found the following FAQ from the link you gave amusing "Why do we need Verified by Visa? Hasn’t Visa been taking my security seriously before?")
    - Reason077 11y ago
      The actual authentication mechanism is left up to the card issuer. But using the card's PIN would be considered insecure due to the risk of malware/key-loggers intercepting it. My bank asks for three random characters from my online banking password (the same mechanism used to log in to my online banking) which provides enough security without risk of revealing the full password to key-loggers.

maaaats 11y ago

Shouldn't the credit card companies be the ones to handle the loss?

jib 11y ago
You would wish so:). But no. Merchants are on the hook for all costs, including penalties for incoveniencing the cc companies (either a set fee per fraudulent transaction, or high fees if exceeding thresholds of fraud if you are a larger guy).

byron_fast 11y ago

Clearly, card companies are going to have to adjust their policies for failed transactions. It's not like it costs real money to decline a fraud attempt; stop punishing merchants.

stevoski 11y ago
Alternatively, small companies started by developers should stop thinking they can implement the payment and order handling code themselves, and learn that instead they should use a service that does this for them.
angusb 11y ago
Yeah, I agree. I guess their argument is that it's difficult to catch every single fraud attempt, and in this case the behaviour was just not picked up by the processor's inbuilt fraud detection systems. Still, it should be the processor's responsibility. GoCardless (Direct Debit, EU only at the moment) is one company that doesn't charge a fee for chargebacks. They take on all the risk themselves.
byron_fast 11y ago
My experience with card company fraud detection systems is that they were bafflingly useless. Maybe they've gotten better recently. But even Stripe seems to let through things that are obvious fraud, stuff that wouldn't pass a basic spam filter. It's almost like they want to charge you those fees!

markgavalda 11y ago

Currently we're integrating Sift Science to avoid this otherwise serious and annoying issue. I think it happens to everyone who's directly accepting credit cards online. Does anyone have experience with Sift Science or similar services? (I know MaxMind has one but that, to me, seems inferior to SS's.)

beilabs 11y ago
Came here to recommend a sift science type solution. I've previously integrated fraud systems like Cybersource (clunky interface, wouldn't recommend)
- jasontan 11y ago
  Thank you for the recommendation!
jasontan 11y ago
Hi Mark, CEO of Sift Science here. Thanks for giving us a shot. Please don't hesitate to ping me if you need any help or we're not delivering to your expectations. jason at siftscience dot com

_Codemonkeyism 11y ago

From my experience running eCommerce sites, the author is right, beside fraud 'noise', fraud happens in waves.

bemmu 11y ago
That was my mistake, assuming that since I was OK with the noise, everything is fine. Didn't know about the fraud tsunamis.
- _Codemonkeyism 11y ago
  Was stunned two when hit the first time by such a tsunami. Your blog post is great, don't think this is common knowledge.

dubrocks 11y ago

Would verifying zip codes mitigate this issue, or do the carders have access to that too?

frgewut 11y ago
ZIP codes seem to be a US-specific thing.
- vacri 11y ago
  ZIP codes are just a funny name for post codes, and most places have postcodes.
  - junto 11y ago
    Damn you Ireland and your "no postcodes" hell.
    - jib 11y ago
      We have postcodes now! Or well, eircodes. Which are totally not postcodes, but rather unique house identifiers that happen to look as postcodes. And that noone will use. http://www.eircode.ie/ http://www.eircode.ie/
  - germanier 11y ago
    While many places have postcodes, most don't have postcode validation for credit card transactions. And it wouldn't really help to combat fraud anyway.
deleted 11y ago
[deleted]
PeterisP 11y ago
Sometimes they do also have address information, sometimes they don't. As with everything, it will reduce the amount a fraud a bit but not eliminate it.

alpb 11y ago

I wonder would that still be the case if Candy Japan was using something like Stripe or Balanced, what happens in that situation? Would you be still responsible for 15 EUR chargeback fee? What did Recurly do in this case?

huhtenberg 11y ago
With Stripe you are still responsible for the chargeback fee, but they do not charge you for transactions that don't go through. They also have some fraud protection, but it did pass some obvious fraud in our case.
bhelx 11y ago
This depends on the gateway you use. Recurly can't do much but refer you to the gateway in this case.

veb 11y ago

Damn shame to hear about this Bemmu -- would've felt like a massive punch to your guts! Maybe you should set yourself up some email alerts when things seem 'off'. i.e. no referral, and the user/bot spends no time filling out the form and hitting submit. What's your glue code like? I'm rootin' for ya. :-)

bemmu 11y ago
Hey veb, This fraud would have been easy to detect if there had been any kind of detection system in place. But I had no fraud checking, captcha or 3-D secure, as I hadn't expected there to such a "fraud wave". Those payments didn't feel like necessarily coming from a bot, as there were time delays and for many purchases they even filled in the questionnaire. It felt more like someone had a pile of numbers they were entering manually. My form made that easy to do, as I had tried to eliminate any field which wasn't absolutely necessary.
- unclebucknasty 11y ago
  >...they were entering manually Definitely wouldn't discount that possibility. Unrelated to CC processing, but we used a service that gave us a device ID on signups to detect people signing up multiple times (a tipoff that fraud was likely to come). We later found fraudsters were using Amazon's Mechanical Turk to get real people to register manually, thus getting around our device detection.

peterhunt 11y ago

This is something we (www.smyte.com) can help out with -- send me an email at pete at smyte dot com if interested. Also happy to answer any questions about general mitigation techniques.

sdrothrock 11y ago
I tried to go to your site but am getting a 500 error. Edit: Interestingly enough, www.smyte.com is fine, but smyte.com yields the 500 error.
- peterhunt 11y ago
  Yes, odd issue with our dns, link corrected.
mootothemax 11y ago
Your site appears to be down right now, otherwise I'd hunt for info there :) What's the difference between you and Sift, and what advantages do you offer over them? Edit: your T&Cs and privacy policy pages referring to a different site entirely don't exactly fill me with confidence :-/
- peterhunt 11y ago
  All the docs refer to the legal entity, not the brand, which may be causing some confusion. Happy to chat more about specific use cases over a medium that's better suited to it; mind shooting me an email? pete at smyte dot com
  - mootothemax 11y ago
    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 email :-)

sjwhitworth 11y ago

We at Ravelin (https://www.ravelin.com https://www.ravelin.com) are building solutions to stop this. Still surprises me how many people think banks/schemes are responsible for CC fraud, when it's actually the merchant that gets punished. And yeah, fraudsters operate like locusts.

jbombadil 11y ago
I don't understand why does the merchant have to pay the 15 fee. It sounds to me the entity that should handle the loss of fraud is the bank.
- sjwhitworth 11y ago
  Blame the lack of competition in the international payments system I guess.

Animats 11y ago

But why? Ordering periodic shipments of candy from Japan? Most credit card fraud involves something that can be resold. This service gets you a small envelope of candy. It's not like getting cases of Pocky.

hkmurakami 11y ago
" The stolen cards originate from credit card security breaches, resulting in a big list of card numbers. These are later sold online in packs filtered to working card numbers only, which can be purchased for about $10 per valid card. To be able to compile and sell these packs, the carders need to know which ones are valid. To do this, they will use an online store or service to place an order for the sole purpose of seeing if the charge goes through or not.
lordnacho 11y ago
Test on one site, buy something substantial on another?

stanleydrew 11y ago

This sucks and can often be a crippling blow for a small business if it's not caught early. I remember we used to deal with a lot of this at Twilio, except the carders would then also try to cash out the credit card into Twilio credit. The pattern was try to spend $10 on a card, then one minute later try to spend $1000 once the first charge went through. But it's a lot less costly than toll fraud, which I learned the hard way working on our auth system at https://charge.co https://charge.co.

sapereaude 11y ago

Did you considered to accept Bitcoin payments? This way you wouldn't have to worry about chargebacks.

eljamon 11y ago
Bitcoin is not the best thing for recurring payment. But it would be great to pay a year in advance with Bitcoin - and yes that solves chargebacks or fraud issues.
joosters 11y ago
To avoid the credit card fraud, they'd have to only offer Bitcoin as a payment option. And that would be financial suicide.

lordnacho 11y ago

I don't understand the search conversion statistic. If a guy is testing a bunch of cards, wouldn't he just find your site once and try them all sequentially? If a bunch of people had bought these packs of stolen cards, wouldn't they be spreading out over a bunch of different sites?

PeterisP 11y ago
The automated scripts that the criminals use will try to simulate a real customer signup and transaction, otherwise it's too trivial to filter them out. This is also why fraud detection is a big industry, you basically need full time staff to analyze the current types of fraudulent transactions and update your filters as fast as the criminals update their systems.

hieudang9 11y ago

Even PayPal or Google faced up to fraud. You can try Maxmind or manual check every order. Contact me to more solutions.

marme 11y ago

i simple solution to cut down on this is never allow more than 2 or 3 failed card attempt from a single ip address. You have to link it by ip because they will just make a new account if you do it by account. Carder will move on to another site if running cards is not simple and fast

stevoski 11y ago

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 various alternative payment options popular in, say, Holland. (Yes, this is a thing, and it is called iDEAL.) Your code will sooner or later be exposed to a campaign of fraudulent transactions. Use FastSpring, or your alternative of choice. Yes, it costs more, if you don't put value on your weeks of time to create and support an alternative, and if are comfortable having a weak fraud detection, if any. When your business becomes successful, when the fees to FastSpring start to dwarf the costs of implementing a payment system yourself, then - perhaps - consider re-doing it yourself. There are indeed weaknesses in using FastSpring, which after seven years are becoming a pain for me. I'll be writing about that soon. But this is not an issue for a one-person endeavor getting started.

nulltype 11y ago
How is FastSpring different from using Stripe.js or Checkout? Both claim "automatic fraud detection".
bhelx 11y ago
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.
- djm_ 11y ago
  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.
  - bhelx 11y ago
    I'm an engineer so I can't really give you an ETA in public. You could certainly talk to one of our sales or product people about it. The thing you need to remember is that you do have options. If you choose a gateway with good fraud tools, or a gateway that integrates with them, we upstream that information to you. Traditionally Recurly has left fraud up to the gateway because they are much better at dealing with it, but we are now seeing the need to offer some more professional fraud tools by default at the Recurly level. Feel free to email me if you want to have a discussion about it: ben@recurly.com

jasontan 11y ago

We at Sift Science (http://siftscience.com http://siftscience.com) might be able to help. Feel free to email me at jason at siftscience dot com Even if you don't use us, we published some articles to help merchants new to dealing with fraud: * https://siftscience.com/sift-edu/fraud-basics https://siftscience.com/sift-edu/fraud-basics * https://siftscience.com/sift-edu/prevent-fraud https://siftscience.com/sift-edu/prevent-fraud

adrianmacneil 11y ago
Sift Science is a great service, I would highly recommend testing it out.
- jasontan 11y ago
  Thanks for the kind words.

jasonkester 11y ago

I had something similar happen with one of my services. I have an "Update your Payment Details" page for paid subscribers that lets them enter new card details when their old card expires or they just want to switch the card they're using with us. It normally gets used a few times a month, and anywhere from zero to one time over the lifetime of a customer. But then the bad guys found it. And individual users started updating their card details dozens of times each day. This went on for several days before I noticed it in the logs. It was easy enough to fix: users now get one update per year, unless they email me and ask what's wrong with that card update page. The bad guys moved on to greener pastures and life went back to normal.

2muchcoffeeman 11y ago

Couldn't you do a preauth on the cards and then completion when you are ready to ship? At least then you don't get hit with chargebacks.

nulltype 11y ago
Last time I talked with a credit card company, they wouldn't even let me file a chargeback until 30 days after the transaction. How would this stop chargebacks?
- 2muchcoffeeman 11y ago
  A preauth on a card reserves the credit without actually completing the transaction. The credit is still there but not available for use. You can complete the transaction by sending a 'completion' request, at which point the credit is gone. The preauth also has an expiry. If the preauth expires, the funds are released with no transaction taking place. So when a user signs up, take a preauth. If you have any reporting on your sales, like this guy, you can check for any anomalies before fulfilling orders. Anything that looks odd, don't complete the order.

watchdogtimer 11y ago

Braintree offers "advanced fraud protection" if you pass device information along with the transaction request [1]. Has anyone tried using this, and if so, is it effective at stopping this problem? [1] https://articles.braintreepayments.com/guides/fraud-tools/overview#fraud-tool-comparison https://articles.braintreepayments.com/guides/fraud-tools/ov...

ck2 11y ago

What about services like maxmind-fraud and the like that authenticate buyers? Are they too expensive per purchase?

fredleblanc 11y ago

I also had something like this happen on a site I built for my wife's work's site, a Boys & Girls Club[0]. I had a donation button that let people make an open donation to the club. It's such a tiny site with little traffic, but apparently the SEO must be decent because somehow it got targeted by people appearing to come through Brazil and Poland. Suddenly one day, hundreds of donation attempts. Checking the failed transactions, the script was trying $1, then $2, etc up to $22 then starting over, each time with a different number. About $200 in successful donations came through before I caught it. So I just shut it all down for now. I'm not really sure how best to fix it. The club has no money and already complain about the transaction fees they get charged per swipe (and those are all pretty standard rates in the U.S.). Being a non-profit, they expect a lot of stuff for free, and unfortunately won't consider paying for an anti-fraud service. Even PayPal takes too big a cut. Realizing that this wasn't a helpful comment, just a "me too." It sucks. Oh well. [0]: https://salembgc.org https://salembgc.org

imjk 11y ago
How can they not be willing to pay a transaction fee from even PayPal for donations? Seems their options right now is to take donations via a service like Paypal with a transaction fee, or just take no donation.
- pc86 11y ago
  You would be surprised at how unreasonable people can be once you start talking about taking a percentage of money they get (be it donations or business revenue or something else). It's the financial equivalent of having a tumor that will kill you and refusing the surgery because the doctor says you have a chance of dying on the table.
- fredleblanc 11y ago
  I don't want to speak for them or go into their financials, but in a literal sense, every dollar counts. When we were talking about taking donations and registrations online, they were frazzled about the transaction fees, and I suggested working them into the costs. (It was only, say a $3 increase in membership price.) The truth of the matter is that some people don't have that much to spare. Of course, that conversation happened way before the site was used as a credit card validator. Trying to explain to them the bad side of charge backs and why this is a big deal is an on-going challenge. The last time I discussed it with them, they kept asking me if they were going to get stuck with all the transaction fees. And, being a developer, my first gut instinct is stepping back and saying "you're wasting money here and here and here and here, cut down these inefficiencies and it'll all balance out." However, it's not as simple as that. Everyone needs to be on board, and the people in charge of these things are already overworked and not highly paid. A catch-22, I suppose. I try to stay out of it as best I can. I made them the site for free in exchange for our two kids to use the club's stuff for free, and with those inefficiencies I hinted at, I can't afford to get caught in being the role of business consultant too.

ryanlol 11y ago

Unless there's some bug in your transaction processing system causing it to leak excessive amounts of data on why the transaction was denied it makes no sense for checkers to use it over their own merchant accounts. (And typical checker traffic is more like thousands of transactions rather than tens) It seems much much more likely that someone was just trying to card some candy.

bemmu 11y ago

I just added in an anecdote that I forgot to mention at first. Encounter with a police officer. Starts from "After starting to deal with this..."

umziehennachbar 11y ago

1. How many sales would you lose if you required everyone to use PayPal everytime? 2. (What about Google cash? or Square cash?)

bemmu 11y ago
It's difficult to test, because by not having credit cards a lot of fake orders are now excluded, lowering the conversion ratio that way. So if I did a test of showing only PayPal to half of customers and PayPal + credit cards to half, the one with CC could win just because of the fake sales.
- umziehennachbar 11y ago
  I guess what I mean is, "do people really need the credit card option? If you just demand they use PayPal and they want your unique service, then they'll find a way to pay".

meshr 11y ago

As I can see all solutions listed in this thread is to protect yourself better and let fraud happens for less protected merchants. The real solution is to fight back against fraud. All fraud attempts must be recorded in the public space, for example http://fraudrecord.com/ http://fraudrecord.com/ . The best solution is to have something like open blockchain Grossbuch for fraud. What are current best solution for FIGHTING BACK AGAINST FRAUD?

umziehennachbar 11y ago

What about using the Twitter "buy" button now? Is it vulnerable to the same type of fraud? See this example https://twitter.com/mperham/status/643480319870369792 https://twitter.com/mperham/status/643480319870369792

ChuckMcM 11y ago

Another interesting problem is that recent breaches have put so many cards in the carding market that clearing them seems to have become a bottleneck. If we could some how work with the banks to perhaps create honeypots for these people it might help us clean up the mess.

slv77 11y ago

Been working in e-commerce fraud for ten years... The credit card security model is broken as designed with the exception of chip and pin and chip and signature. Uptake for 3D Secure is uneven around the globe. Some places it is mandatory and others unheard of. For example not using it will negatively impact close rates in India but using it in the U.S. will negatively impact close rates. With 3D Secure each issuing bank was responsible for how they implemented the process and it varies widely in both ease of use and security between issuing banks. Some banks may use simple passwords that can be fished while others may use one time pins sent by SMS to your mobile. When a merchant uses 3D Secure fraud liability shifts to the issuing bank and the merchant gets a discount on the interchange. This is also true when the bank hasn't implemented 3D Secure or has done so poorly. Because of this when 3D Secure was launched some banks put out systems that were non-functional simply to avoid the liability shift (i.e. it would prompt for a password but there was no functionality to create one). Issuing banks have gotten their act together in the last decade but it's still uneven. Even when a merchant implement 3D Secure the merchant still needs to manage fraud levels to card association rules even though the merchant does not have liability for the fraud. This is the "we have to assume the risk but we don't have to do business with you clause." Individual issuing banks may chose to decline all of a merchants transactions if loss rates are unacceptable and the merchant may still lose their merchant account if overall loss rates are too high. However because the charge back shifts to the banks the merchant may not even know which transactions are fraudulent. Recently rules have been changed so that banks aren't required to prompt for authentication in all cases. This is called risk-based-3D secure. So even if Candy Japan had implemented it he still may have seen the attack because the banks may not prompt for that low of an amount. He wouldn't be out the money but still may be in trouble with the association if he didn't do something to stop the attack. When looking at automation there are two fundamental risk that any solution needs to address. The first one is class separation which in the industry is known as scoring or out-sorting. In this area machine learning algorithms are well understood and there are a few companies on the market that will rent merchants a model such as Sift Science or MaxMind. The second one is anomaly detection and in the industry this is know as velocity control. The problem is similar to detecting a hacker once they have penetrated the network, detecting a bio-terror attack based on hospitalization data or detecting insiders who have flipped. These types of things have generated a lot of military interest and a lot of DARPA funding but little of it has made it into the commercial market due to the high rate of false positives. Card testing is one example of a 'high velocity' attack and are usually the work of professionals. High velocity fraud has been more common with digital goods but more recently we've seen more high velocity attacks where an attacker will upload a merchants products on a site like Amazon or eBay. When the attacker gets a sales they will use stolen credit cards to get the trageted merchant to fulfill the order. Since these are professionals they generally will have tested the merchants fraud systems to understand what is considered low risk by the merchants fraud models and unless the merchant has some monitoring losses can be very high by the time the charge backs start coming in. Currently there is no automated, fool-proof method for managing these high velocity attacks that I'm aware of. Merchants initially started putting limits around the number of times that a single card could be used and the attackers responded with SQL injection attacks to get card in mass. Merchants responded with limits on email addresses or other data points and the attackers responded by mass registering emails on free email providers and registering their own domains. Merchants responded with limits on IP addresses and used of geo-ip location services and attackers responded with open proxies and VPNs. Merchants responded with limits on orders from co-location facilities and VPN providers and attackers responded by compromising end-user machines en-masse. Merchants responded with proxy detection and device fingerprinting and attackers responded with using RDP to end-user machines to launch attacks. And it continues.