61–70 of 208 posts
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
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.
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.
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.
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 :-/
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.
It's almost like they want to charge you those fees!
Earlier quoted context omitted.
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 :-/
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
>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 :-)
From my experience running eCommerce sites, the author is right, beside fraud 'noise', fraud happens in waves.
That was my mistake, assuming that since I was OK with the noise, everything is fine. Didn't know about the fraud tsunamis.
Earlier quoted context omitted.
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
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…
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.
Earlier quoted context omitted.
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…
>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 can never work this out; it seems that scammers from different countries (or using hacked servers / proxies?) are attracted to different sites or types of ecommerce sites. For example: - One of my sites has huge fraud from Ukraine and Russia - Another from Indonesia - Another's prob…
Earlier quoted context omitted.
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…
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?")
A PIN can be required for "cardholder present" transactions in most of the world. Some combination of card issuer, transaction processor and merchant decide at what value transactions may proceed without a PIN — e.g. a train company's actual loss from a fraudulent ride is very small, so they might not want the delay of asking for a PIN on a ticket machine. Similarly for McDonalds. But if you're buying a TV, you will need to use a PIN.
It's almost 100% of transactions in much of Europe, over 80% in Africa and South America, lower in the old Soviet Union and Asia: https://www.emvco.com/about_emvco.aspx?id=202