Hacker Newsnew | past | comments | ask | show | jobs | submit | more Pyramids's commentslogin

Are you considering offering paid plans by any chance? We'd be interested in using a service like this, but it would need to have a much lower interval to meet our needs.


Hi Pyramids,

please write me an email to hello@visualping.io and we can talk about this :-)


Contrary to what the article states, this is almost definitely not due to skimming of any kind. It is most likely related to a database leak or breach, whether it is documented or not is another question.

Also, typically these are not "actual" (card-present, pin entered) debit transactions. Starbucks, much like Amazon, authorizes some online purchases as pinless debit card transactions, due to the lower processing rate incurred by the merchant. This can all be done completely online, for example, via Starbucks Online Reload system.[1]

This is truly nothing new, Gift card fraud has been booming since 2006-2007, when companies (starting with Starbucks, followed by Subway, Walmart[2], Whole Foods, etc.) began offering reloads to existing cards. Unfortunately, most of these companies have laughably bad fraud detection.

For example, Whole Foods uses a platform formerly known as "Giftango", which was rebranded as "InComm" in the last couple weeks. They quite literally will let a credit card thief reload hundreds of dollars from an IP anywhere in the world, to any gift card powered by their platform. No fraud scoring, velocity checks, geolocation, etc. You can imagine how easy this would be just by taking a look at their default gift card management portal, used by Whole Foods.[3]

Conveniently for credit card theives, WalMart even offers an option to reload a spreadsheet, or a CSV list of cards off a single credit card, easy right?[4]

Overall, I think this problem is only going to grow, especially with Cardpool acquired by Safeway, and now offering instant cash for gift cards in stores. This is an extremely easy method to cash out these fraudulently created gift cards, conveniently located at your local grocery store.

[1] https://www.starbucks.com/card/reload/one-time

[2] http://www.walmart.com/cp/Reload-Gift-Card/1097444

[3] https://app.giftango.com/GiftCardPortal/WholeFoods/GiftCardP...

[4] http://www.walmart.com/cp/Reload-Gift-Cards/416242


You would think that pinless debit card transactions would carry higher fees since there is a higher risk of fraud. Any thoughts as to why it's the opposite?


It's not pinless debit versus regular debit, but rather pinless debit versus credit.


I wouldn't say there is any higher potential for fraud, as they're essentially verifying the same about of data. It may make it slightly more difficult to recover funds if your card is used without your permission, however.

The processing rate is typically lower because of agreements between issuing banks and debit processing networks, and is a somewhat hot topic at the moment as technically pinless online debit transactions are only intended for when the customers identity has been "confirmed", such as individuals with running accounts at a wireless carrier.

However, for whatever reason, some big companies are being allowed to use the MasterCard Debit/Maestro/Visa Debit/STAR/PULSE networks in this manner. In this case that company is Starbucks.

I'd estimate the rate paid by Amazon/Starbucks for processing pinless debit is 0.8% or less. Compare this with the 0.9 - 2.2% interchange fee (depending on card type) they'd incur if they processed these transactions as credit. It might not sound like a lot, but at that scale it probably ends up being millions per day saved.


Do you know if InComm/Giftango take on any of the burdens of fraud?

There already seems to be a big moral hazard problem with credit card companies and merchants, where the merchants have to cover the entire loss if I understand correctly.

I'm hoping competition from startup payment processors might put pressure on credit card companies, as this ends up costing businesses and consumers a lot of money.


As far as Giftango goes, they simply provide the platform, Whole Foods (or whomever is the actual gift card merchant) is responsible for any fraud which occurs due to abuse of the platform. Assuming the fraud was successful, Whole Foods will lose both their product and their money.


While I agree that it is not due to skimming, I dont think it is database leak or breach. If it was, thieves would probably go for smaller transactions (since they are harder to notice ) on large scale. My guess is that she either got phished or shopped on compromised website. That could also explain hosting purchase.


Phishing for credit card information alone is extremely rare, as it doesn't make any financial sense to people whom are committing fraud, if someone were phishing they'd be interested in login information and identity data instead.

In my experience, most database breaches result in data being sold, not used. It's more profitable and results in far less risk (Ex: 100k cards @ $2/ea via anonymous payment methods) vs attempting to use the cards.

As such, the people who end up actually creating the transactions are usually low level individuals whom are trying to figure out a way to "cash out"

Not to say there isn't a chance you're right, but card data is cheaply and readily available elsewhere, which is why I don't think this was related to a phishing attack. If there were other signs (ex: bank logins compromised, credit inquiries, etc.) then I'd be much more inclined to agree. Either way, it's hard to come to a certain conclusion based on the information provided in the article.


What makes you say it was from a database leak?

I had a fraud issue caught by a bank once. What's strange is they caught the test at a bar I had frequented. That made me assume that it was skimmed. (But perhaps they saw many others tested there?)


It's unlikely for a skimmed card to be used online in this fashion, because the thieves wouldn't typically have the CVV2, only the CVV1 which is included on the magnetic stripe track. Most merchants which offer gift card reloads will decline on an incorrect CVV2.

Additionally, cost benefit wise, card data sells for $2-3 max, while track data sells for much much more ($25-50), and typically someone capable of acquiring this data themselves would not be wasting their time with Starbucks card reloads.


Interesting. Thanks!


Wow. I can't believe the banks aren't bending their pet Congresscritters' ears, demanding new laws to regulate these practices.


The last thing banks want is any regulators looking into how easily they can launder money.

Who cares about gift card fraud when they are laundering billions for criminals, cartels etc.

If you get too much oversight, they might accidentally find all the other crap banks are upto.

If there is any institution you can be assured of fraud; it's banks.


But this particular fraud costs them money.


This would only work against very low level / amature phishing operations.

Most of these systems not only validate user login information (often in real time) but also place live authorizations on cards to make sure they are valid.

For example, the "credit card generator" you found probably just uses MOD10/Luhn to generate 'random' numbers, starting with 3/4/5 depending on the card type you select.

If you're looking to simply add friction to low level identitiy thieves, it'd probably work, but the real question is what is your motiviation?

Your time would be better spent contributing to existing phishing prevention projects, or attempting to coordinate with network providers to get these sites taken down more quickly, the majority of victimization occurs from large scale data theft or professional phishing / malware operations like IceIX/Citadel, not Joe Blow's Wells Fargo phishing page.


An easy to implement solution would be to use MaxMind's fraud API prior to capturing card data.

Although it's nowhere near fool proof it cuts out a good chunk of fraudulent orders. In our experience false positives have been very low (less than 2%) and detection has been fairly good (80%+)

I wouldn't deny orders completely based on MaxMind results, but if you have a human interpret the results / scoring or use it in conjunction with other methods, it's definitely a viable option.

Furthermore, you can use their call verification API, or even call card holders yourself whenever an order is placed to an alternate shipping address.

Fraud is just a fact of the business though, even with the best fraud detection and verification methods. Fraudulent orders may slip through, especially as you scale, and you should account for this as a cost of doing business.


What's the threshold (risk score) you use to consider a transaction as fraudulent?


Although we combine with internal scoring and manual review, as stated; If I was using MaxMind exclusively I'd consider 5.0 to 7.5 a good indicator of a possible fraudulent order.

This is based on their current riskScore system[1] (changing on January 1st, 2014) and 10 as an instant failure without review. Most orders will generate a non-0 score, however.

Another great tactic for preventing fraud is to never indicate an order has failed or a card hasn't been charged ('ghosting'), this is a tactic used heavily by Google for AdWords and other paid services.

Giving a clear indication of failure allows "carders" a way to easily figure out your detection algorithms by placing orders until one gets through, and share that information with others who will attempt to victimize your checkout process.

[1] http://www.maxmind.com/en/ccfd_formula


Any idea what the equivalent 'riskScore' would be? If we are starting using minfraud it doesn't make sense to use 'score'.

Thanks


riskScore is a combonation of hard coded scoring, along with what I'd equate to a bayesian filter.

In a way, riskScore simplifies the calculation, because it's a percentage instead of an arbitrary number. Depending on your business, I would consider starting at 30% for manual review, and 90%+ for auto refusal, making adjustments to the threshold from there.


Agreed, hoping Zapier implements something like this soon.

Basic transforms / Regex / Basic if statements applied to trigger inputs/outputs would be invaluable.


While I admire the effort and overall mission, the problem is that when an application promotes 'secure communications', there are people who actually may use it as such.

Mistakes are understandable, however I think in-depth code review and auditing in any environment involving cryptography is an absolute must. Potentially, peoples lives could be jeopardized (either legally or physically) if they believed their communications were secure, when in fact they were not.


I can appreciate your desire to drive business to your company, as any of us would, but don't you think it would be prudent to add a disclaimer, or at minimum refer to yourself in the first person?


Ok, insert "I am " in front of "Not". That should do.


Hello Alan,

I have a quick question for you which might be of interest to others as well:

Why isn't SpiderOak open source yet?

I've read your FAQ answer[1] on this, however it doesn't really give a concrete explanation, besides "soon" and "licencing concerns" which is definitely disappointing.

I currently use my own, EncFS based sync solution, however I'd love to be able to use SpiderOak, or a third party open source application which supported syncing with SpiderOak (if you'd ever consider exposing an API/Protocol which allowed such.)

This is the only reason I'm not using your service currently, however I love the concept and hope you'll take it into consideration. It's likely I'm not the only one with similar concerns.

[1]: https://spideroak.com/faq/questions/35/why_isnt_spideroak_op...


I don't think it's a matter of discrediting or condemning anyone. He's simply providing an alternate perspective on what might be going on, whether it is true or not is anyone's guess.

I personally don't think he has any PRC ties, however it does foster an interesting discussion, and isn't that what HN is all about?


To play devils advocate, if I had connections in Hong Kong and was attempting to gain footing there, I would not want to volunteer information regarding my connections where it would be widely published in the media.

I don't think that's the case here, however we really don't have any concrete evidence either way.

As far as law enforcement goes, you're spot on, physical distance is the least of anyone's concerns. The first consideration for law enforcement would probably be "How willingly will this jurisdiction work with us?"


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: