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.
Living in Holland, where everyone does online transactions with iDeal, I find it hard to understand why the rest of the world is using credit card payments at all, for anything. It is massively insecure, it's expensive for the merchant, and theft is ignored (when millions of stored creditcard records are stolen, those cards are not invalidated and replaced?). This is all at the cost of customers and other merchants.
I'll keep trying to avoid using a creditcard as much as possible and use other payment methods when I can, both online and offline.
And yes, when implementing payments on a website, use a service that does all of the complex things for you, and never store sensitive data yourself.
Just for the record, as a Dutch person, Holland refers to the two provinces North and South Holland and there is more to the country than just that. The Netherlands would be more accurate.
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-ba... )
> 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.
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.
I was using VeriSign for years. Then my site got hit with a "carding" [1] attack. VeriSign was simply not interested in helping with it, the merchant bank I had coupled it with was not interested either.
So I cancelled VeriSign and the merchant account, and use paypal and Amazon Payments instead.
I did make the rounds of a few banks, all were eager to set me up with a new merchant account. All gave me blank stares when I asked if they had any means of preventing carding attacks or other frauds.
[1] A carding attack is when there's an attempt to buy something for $0.00, just to see if it is rejected or not. I was getting one every minute or so. I got charged for every one of those, and so soon had racked up a grand in charges.
Osiris' info was useful. I really also need to put in some fraud detection like that. But there are so many companies providing that service, I'm not sure which one to go with. How involved is it to integrate these?
It's not my idea of fun to try look at these transactions manually, so until I get a motivation boost to go through with the integration it'll probably be PayPal-only.
Something like a simple proxy / VPN IP detection should be used because I assume most of the "carders" don't use their home IPs. There are decent free solutions online like W I T C H and GetIPIntel.
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.
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.
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.
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.)
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
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.
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.
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.
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.
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!
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.
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.
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.
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/ . The best solution is to have something like open blockchain Grossbuch for fraud. What are current best solution for FIGHTING BACK AGAINST FRAUD?
We at Ravelin (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.
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.
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.
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?
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.
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?
[+] [-] stevoski|10 years ago|reply
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.
[+] [-] Maarten88|10 years ago|reply
I'll keep trying to avoid using a creditcard as much as possible and use other payment methods when I can, both online and offline.
And yes, when implementing payments on a website, use a service that does all of the complex things for you, and never store sensitive data yourself.
[+] [-] bhelx|10 years ago|reply
[+] [-] tokenizerrr|10 years ago|reply
[+] [-] nulltype|10 years ago|reply
[+] [-] moron4hire|10 years ago|reply
[+] [-] josinalvo|10 years ago|reply
Why would using FastSpring be safer than using Stripe?
[+] [-] djm_|10 years ago|reply
[+] [-] kweks|10 years ago|reply
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-ba... )
[+] [-] nchelluri|10 years ago|reply
> 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|10 years ago|reply
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.
[+] [-] WalterBright|10 years ago|reply
So I cancelled VeriSign and the merchant account, and use paypal and Amazon Payments instead.
I did make the rounds of a few banks, all were eager to set me up with a new merchant account. All gave me blank stares when I asked if they had any means of preventing carding attacks or other frauds.
[1] A carding attack is when there's an attempt to buy something for $0.00, just to see if it is rejected or not. I was getting one every minute or so. I got charged for every one of those, and so soon had racked up a grand in charges.
[+] [-] bemmu|10 years ago|reply
It's not my idea of fun to try look at these transactions manually, so until I get a motivation boost to go through with the integration it'll probably be PayPal-only.
[+] [-] blackice|10 years ago|reply
[+] [-] fredleblanc|10 years ago|reply
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
[+] [-] smcl|10 years ago|reply
[+] [-] driverdan|10 years ago|reply
[+] [-] imjk|10 years ago|reply
[+] [-] StavrosK|10 years ago|reply
[+] [-] jasontan|10 years ago|reply
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/prevent-fraud
[+] [-] adrianmacneil|10 years ago|reply
[+] [-] scurvy|10 years ago|reply
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.
[+] [-] markgavalda|10 years ago|reply
[+] [-] beilabs|10 years ago|reply
[+] [-] jasontan|10 years ago|reply
[+] [-] quaunaut|10 years ago|reply
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.
[+] [-] jasonkester|10 years ago|reply
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.
[+] [-] stanleydrew|10 years ago|reply
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.
[+] [-] sapereaude|10 years ago|reply
[+] [-] eljamon|10 years ago|reply
[+] [-] joosters|10 years ago|reply
[+] [-] byron_fast|10 years ago|reply
[+] [-] byron_fast|10 years ago|reply
It's almost like they want to charge you those fees!
[+] [-] angusb|10 years ago|reply
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.
[+] [-] stevoski|10 years ago|reply
[+] [-] ChuckMcM|10 years ago|reply
[+] [-] meshr|10 years ago|reply
[+] [-] peterhunt|10 years ago|reply
Also happy to answer any questions about general mitigation techniques.
[+] [-] sdrothrock|10 years ago|reply
Edit: Interestingly enough, www.smyte.com is fine, but smyte.com yields the 500 error.
[+] [-] mootothemax|10 years ago|reply
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 :-/
[+] [-] sjwhitworth|10 years ago|reply
[+] [-] jbombadil|10 years ago|reply
[+] [-] scurvy|10 years ago|reply
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|10 years ago|reply
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|10 years ago|reply
https://en.wikipedia.org/wiki/Controlled_payment_number
[+] [-] alpb|10 years ago|reply
[+] [-] huhtenberg|10 years ago|reply
[+] [-] bhelx|10 years ago|reply
[+] [-] maaaats|10 years ago|reply
[+] [-] watchdogtimer|10 years ago|reply
[1] https://articles.braintreepayments.com/guides/fraud-tools/ov...