Possible mystery shopper scam with ShopperSystems

by Joe Payne 30. June 2010 14:05

Ok, you're gonna love this one....so make some coffee and enjoy the saga.

My fiance found this ad in a local job listing website for "Mystery Shoppers Needed".  The ad included a bunch of additional keywords not normally associated with a standard job posting.  This surely improved SEO but didn't lend a lot of credibility for being a "real" job listing.

Excited at the possiblity of having found a job, my fiance beamed as she relayed the details to me.  For a mere $ 2.95 "testing fee", she could quickly become qualified to be a mystery shopper in the Indianapolis area.  In fact, she was told there are several jobs available right now !  All that was needed was a credit/debit card to pay for the $ 2.95.

Being the caution one I am, I handed her the smallest debit card I had - maybe $ 100 in the account so no major deal if it's a scam.

Together we made the call to provide the credit card info.  The answering woman was professional and quickly told my fiance she could make up to $ 50 per mystery shopper job.  Then she immediately wanted to confirm my fiance has a valid credit/debit card.  It sounded pretty scripted to me.
My suspicions were aroused further at the background sounds on the other end of the line - definitely a high volume call center and not the quiet, relaxed office enviroment I expected.  The lady quickly confirmed that no additional charges would be made to the card and proceeded to establish my fiances login information to www.shoppersystems.com.    The really weird part was when we waited on hold no less than 35 minutes for a "4 digit security confirmation for our credit card transaction".  I'm still not sure what that was all about but eventually a recorded voice came back stating the transaction was approved.  We hung up at that point.

Having listened to the entire experience first hand myself, I didnt have the warm-fuzzy from a place that charges money to accept an application for employment.  Once the call ended I decided to Google this shoppersystems company and see what comes up.  Sure enough, post after post of scam alerts and warnings came up.  According to most of the posts I saw, there's a $ 49.95 fee that shows up a week or so after the $ 2.95.  Then it becomes very difficult if not impossible to reach someone to cancel/discuss the unknown charge.

Obviously after reading so many other negative experiences and not a single positive one, I called my bank and cancelled the card.  The $ 2.95 charge had already hit the account.  Fortunately the card is now dead and no further monies can be drawn from the account.

Who knows if this was completely legit or not, but I have to stand by the idea that if it sounds too good to be true, it probably is.

We both found it an amazing coincidence that the VERY NEXT DAY my fiance receives a call stating she had won a sweepstakes and wanted to confirm she had a valid debit/credit card.  Sound familiar?  Yeah, we thought the same thing ourselves - SCAM ! :)



Yay got tickets to Jeff Dunham at the last minute!

by Joe Payne 28. February 2009 09:18

I was so bummed a few weeks ago when I realized how expensive tickets to the Jeff Dunham tour were. 

So as a long shot, I checked Craigslist every day or so and sure enough, the day before the show some really, really great floor seats came up for sale and I snagged 'em!



Credit Card System Flaws and the Online Merchant

by Joe Payne 29. January 2009 09:14


As an online merchant, it's very important to understand where the burden of financial responsibility lies with regards to accepting credit card payment online.  This article is not a rant nor is it a bitter documentary of lost chargeback disputes.  The purpose of this document is to clearly explain how you, the online merchant, will be left holding the financial "bag" with all chargebacks that are demanded against your merchant account.

Anatomy of a Chargeback

First, let's review all the parties involved with a chargeback.  Once we know everyone involved, we'll get into exactly how each of these parties is involved in the chargeback process.  Every chargeback involves the following entities:

  1. Cardholder:  Person to whom the credit card was issued.  For this article, we'll call him John Doe.
  2. Issuing Bank:  The financial institution that issued the card to the cardholder.  Examples include Chase Bank, Wachovia and even your local bank.
  3. Processor:  Also a financial institute but not necessarily a bank with retail outlets.  Some processors are "commercial banking" facilities that do not operate "public" banking facilities.  The processor can also be the same bank you already do business with.  Regardless, the processor is just a middle man pushing financial transactions back and forth between your bank and the issuing bank.  They follow a very specific set of rules and rarely deviate from these rules.
  4. Online Merchant:  You.  The guy who's going to get stiffed by all of the above parties when a chargeback hits your account.  You run an online store called Widgets.com selling nice electronic gizmos to Latte-drinking big city folks.
  5. Visa/Mastercard:  These are real companies, not just a brand label for a credit card.  These guys hold all the cards no pun intended.

What exactly is a "chargeback"?  Put quite simply, a chargeback is a refusal by the issuing bank to accept financial responsibility for a given purchase.  In most cases, the issuing banks refusal is based on the cardholders signed statement of refusal.  At any time while the cardholder account is active, the cardholder has the option to refuse specific charges against their credit card.  Once this refusal by the cardholder is submitted in writing, the chargeback is born.

Chargeback Flow

There are almost as many interpretations of the flow of the chargeback as there are financial institutes issuing them.  Here's how it really works:

John Doe gets his credit card statement in the mail (or a phone call if his bank really cares) and learns a bunch of stuff he didn't order has been charged to his account.  In fact, he doesn't even remember opening this account in the first place.  John responds that he didn't authorize these charges or make these purchases.  His bank fires off the usual paperwork and John fills out form after form detailing the charges he says are fraudulent.  The paperwork is signed by John and returned to his bank.
There are time limits involved here as well.  So John can very well expect the bank to advise him of how much time he has and how much time they have to submit his claims.  Miss those deadlines and the bank (and John) lose the window of opportunity to submit a chargeback.

John's bank, the Issuing Bank, now researches the electronic data associated with each fraudulent charge.  The bank determines the originating processor and merchant involved with each transaction.  Johns bank fires off a series of electronic demands-for-payment against each merchant involved to each merchants assigned processor.  This is where the fun begins.  According to the rules of the game, the issuing bank can and will demand funds be withdrawn from your account at any time.  They aren't required to give any warning or notice to you as the merchant.

So as you truck along your merry way running your business, you must always keep that point in mind.  At any given time, without any warning whatsoever, the issuing bank of a cardholder can demand your processor return the funds to them for the transactions involved.  Since the processor is just a middle-man shoveling transactions back-and-forth, they do precisely what the rules say and electronically remove the funds from your account.  Whether your processor notifies you is completely dependent on the policies of that processor.  This is something incredibly important to keep in mind as you shop for a processor - the bank you normally do business with may not necessarily be the best choice as your processor.

Now let's move to the online merchant side of the equation.  You log into your online banking account one day to find your business checking is OVERDRAWN!  But wait, you haven't written any checks so how could this be?  Was the account compromised and the money stolen?  Well, you're half-right.  The money was stolen, it just happened to be stolen by someone you gave permission to do so.  You agreed to allow any issuing bank to withdraw money from your account when you signed the long and hard-to-read contract with the processor to get your online merchant account.  Welcome to Stiffing-the-Merchant 101.

When you opened your merchant account with processor, you of course had to sign some forms.  Buried deep in those forms is the clause that authorizes the processor to withdraw funds from your account at any time.  It gets better: you don't have to be notified and there is no arbitration process with the processor.  They're just the middle-man and they're just doing what they're told.  Well who in the world would make such a rule that favors the banks and leaves the merchant high-and-dry?  The banks started Visa and Mastercard.  These companies were started by a conglomerate of over 21,000 financial institutions around the world as a way of implementing a common form of payment.  So you as the merchant are forced to play poker with the deck stacked against you.

Back to our saga:  Your bank account is overdrawn and you're in a panic.  Orders from distributors are going to bounce.  Overdraft fees (from the same bank that over-drafted you!) are racking up.  Fingers fly as you dial the merchant support services number on your phone......

Disputing the Chargeback

The Merchant Services (aka Merchant Support) department at your processor is your next step.  Your task now is to "dispute" the chargeback.  You've made every attempt possible to validate the identity of the online purchase.  You used the processors Address Verification Service (AVS).  You used their CVV2 service.  Everything came back a full match.  Heck, you even shipped the order signature required.

Well, start printing.  Print everything about the order you can because you're going to have to submit all of this information as part of your chargeback dispute.  Order details, payment transaction logs, shipment tracking logs etc.  Put it all together, and then print some more because the processor will have some forms you have to fill out too.  Get everything together, fax it to the processor and they will submit the dispute on your behalf.  And you better hurry - there's a time limit on how long you can wait before the opportunity to dispute a chargeback disappears.

Don't forget:  the funds have already been taken from your account.

Wait a minute.  On your behalf??  That's right.  You don't get to directly dispute the chargeback.  You have to go through that middle-man the processor.  Another fine rule made by the banks - they didn't want you ignorant (and probably angry) merchants calling them directly.  They hide behind the processor by requiring disputes be filed via proxy.  You submit the details to your processor, and your processor handles submitting the dispute to the issuing bank.

Finally some decent news.  Most processors, if not all, will return the disputed funds while the dispute is in progress.  Nice if you needed the money, but darn confusing from a bookkeeping standpoint.  Plus, you have no guarantee the funds will remain there (pending the outcome of the dispute) so you could easily wake up 3 days from now to see your account overdrawn again!  Having fun yet?

Once the dispute is filed, you wait.  And wait.  And wait so more.  Because there's still no requirement to notify you as to the result of the dispute.  Good or bad news, nobody has to call you to advise the status or result of the dispute.  Eventually you'll learn the results of the dispute - probably only by calling Merchant Services (again) and asking someone.

Re-presents and Your Processor

So you lost the chargeback dispute.  Swell.  You just had real cash money stolen from you and you've joined the ranks of hundreds of thousands of other lucky online merchants.  Is there anything more you can do?  Well, that all depends on how aggressive you want to be.  In some cases, the processor can be "encouraged" to re-present the dispute to the issuing bank.  Hopefully this will be done with some new information like a letter from you bank stating all efforts were made to authenticate the charge.  However your chances of success here are completely up-in-the-air.  There's no way to tell as every bank and situation is different.  A good processor will work hard for you to get that money back.  A bad one will throw your contract up in your face by suggesting you read the terms of said contract.

At this point, the chargeback process is pretty much done.  Have you noticed the issuing bank did not have to pay for the charge?  They seem to be no-worse-for-wear in this situation.  What about the fees charged by Visa/Mastercard?  Nope, they still have your money too.  How about those processor transaction fees?  Gone.  In case this isn't clear enough, here's who still got paid:

  • Your distributor:  for the product purchased in the disputed transaction.  Kiss that money goodbye.
  • The Issuing Bank:  They didn't really get paid but they sure as heck aren't out any cash.  That's what they have you for.
  • Visa/Mastercard:  that lovely 2.6% is theirs to keep.
  • The processor:  Every transaction has a fee, doesn't matter if it's good or bad.
  • The payment gateway:  a silent player in the game - they handled getting everything from your storefront to the processor and they aren't planning on giving it back any time soon.

Notice how "The Merchant" seems to be missing from that list?  Do everything right and you'll still wind up stiffed.  Read on to see how....

How to Protect Yourself from Chargebacks

You can't.  Period.  Plain and simple.  The sooner you accept that answer, the sooner you can decide if online merchant is what you want to be.  You can reduce the likelihood of a chargeback, but you as the merchant have no protection.

The official Visa/Mastercard stand is:  "By choosing to offer the service of credit card payment in a card-not-present environment such as online transactions, the merchant assumes the financial risk inherit to such activity."

The only safety net you can build is a physical imprint of the card itself.  Yeah, sure - you'll get right on that with your internet-based online storefront!  The banks don't have to be realistic - they're making the rules.

Improving Chargeback Dispute Success

Here are some tips to help improve your dispute success.  Nothing is going to guarantee it, but at least you can cry about it knowing you did everything you could:

  • Never ship to any address other than the bill-to address
  • Ship everything signature-required and use shippers with good tracking abilities like UPS, FedEx etc.  Don't even bother with USPS if you ever want to use tracking info in a dispute.
  • Use a storefront that documents the payment processing transactions in detail.
  • Contact the issuing bank and request they contact the card holder for charge verification.  Specifically document who you spoke with at the issuing bank, when you called and what their response was.  If the issuing bank is too lazy to perform such a simple step, you've got the evidence that you cared and they didn't.
  • Ask to speak with the manager of your processors merchant services department.  Often they will have unique insight and experience that can help you.


As you've seen, the entire credit card system is designed to place the financial burden of responsibility on the merchant.  As an online merchant, you must prepare yourself and your business for the financial losses that will occur.  You cannot assume you'll win any chargeback disputes.  You can do AVS and still lose.  You can do CVV2 and still lose.  You can ship every order to the bill-to address and still lose.   A payment system designed by the banks, for the banks.  That's what you're up against.  The sooner you plan for that mentality, the better.

Tags: ,


Lessons learned from a heavily modified AC7 site

by Joe Payne 6. October 2008 10:33
It was exactly 1 year ago this week when I started making changes to my AbleCommerce 7 install. The version was Beta 1. You read that right. That was before Final SR1, before Final, before RC3, before RC2, before RC1 and before Beta 2. I was a complete noob to eCommerce - AC7 was my first storefront product. Solunar.com was my first effort at an online business. It was also my first full .Net application. I had maybe 6 months of (incredibly simple) .Net programming experience. I knew nothing about HTML, XML, data classes or namespaces.

With the help of Able staff, forum members and your friend Google, my knowledge and experience grew every single day. I made the decision to go live with Beta 2. In hindsight, that was probably the best thing I could do from an educational perspective although it was painful. Not so much because of Beta 2 but moreso my lack of experience with the whole go-live thing in general.
Since those days of blissful ignorance, I've learned a great many things. I thought I would take some time to share some of my experience with the forum members. I'll also post a copy to my blog at http://www.AbleMods.com/Blog/.

Modifications to Existing AC7 Files
Every modification to an existing AC7 file comes with a price. You must consider that the file(s) modified will get updated in a future AC7 upgrade. This leaves you with the task of re-incorporating those modifications into new files. While this may not seem a major task, imagine a full 12 months worth of tweaks, changes and major improvements. Now the magnitude of effort to upgrade directly impacts your decision of WHEN to upgrade. You're trapped.
I currently have 24 separate, existing AC7 files that are modified. Some of these will take only a few minutes. Others will take days. This doesn't even take into account the 12+ for-sale modules I have on AbleMods.com. So just imagine 36+ separate modifications, spread across 12 months of time and all at varying degrees of complexity and skill. Some of the changes involve code I haven't looked at in 6 months, so re-educating myself will burn up some time.
When you are considering the decision to modify an existing AC7 file, I strongly reccomend you not make the decision in haste. Take the time to consider the impact on your future upgrade needs. Able might release something incredibly useful to you - now you're feeling the pressure to upgrade even more.

Modification Design Considerations
To Tweak or Make New. That's the very first question I ask myself when considering any modification. A tweak involves changing an existing AC7 file. Making new is just as it sounds, I make a completely new file named separately from all others.
A lot of this decision comes from the complexity of the change involved. Adding a single button to an ASPX page involves far less effort than making the minibasket show product images for variants.
My second question is always: How many files do I have to change if I make a completely new file? The reason I ask myself this question is critical to the upgrade process. Imagine modifying the ~/ConLib/Utility/ProductPrice.ascx control. That control is used in a variety of other user controls. If I make a completely new file, I'm going to have to find and modify every single one. If I miss any one file, the site is bugged and I probably won't even know it.
So sometimes it's better from a modification-management standpoint to simply change the original file.
But what about the upgrade process? Let's say I do make a brand new ProductPrice file and modify all the controls that use it. I install the next upgrade and it blows away all those control changes I made. But, my specially-named ProductPrice file did not get erased. It's still there and probably still works. All I need to do to re-activate it is simply change one line in each of the user controls again.
The point? Sometimes it's easier to make 6 little 2-minute changes to the user controls than re-integrate 8 hours of work into a single ProductPrice file.

I make 3 different efforts to document every programming modification I make to Solunar.com.
The first is in the code files - I preface each modification with a comment like "// BEGIN MOD: Solunar 10-6-08" so it can be easily found with a search function. I usually end the mod with "// END MOD: Solunar" just so it's more clear exactly where the mod starts and ends.
Second, I keep a separate folder on the live site call "Customized Pages". Every time I upload a changed file, I upload it twice. Once to the location from which it will run, and a second copy goes in this special folder. The folder has the same folder structure as the existing site. That way I can easily tell ~/Admin/Orders/Default.aspx was modified and WHERE it should go within the storefront app.
Third, I keep a Word document that is sort of my diary for programming changes. Since I already have a desktop folder on my development PC for all my developer tools, it's easy to keep this document close to where the work is done. It's helpful because I can spell out what I was trying to accomplish, when I did it etc - makes a nice reminder when I have to go back to that code and look through it again.

User Controls Are Your Friend
The ConLib design of AC7 was ingenius. It gives you the flexibility to modular-ize your efforts into reusable components. But it also gives you the ability to incorporate modifications without affecting your upgrade options down the road.
When I know a user control is going to require modification, I copy/rename that control into the ~/Conlib/Custom folder. So if I'm modifying ~/ConLib/BuyProductDialog.ascx, it'll become ~/ConLib/Custom/Mod_BuyProductDialog.ascx.
This technique benefits me in a variety of ways. First, it keeps my changes separate from default AC7 files so an upgrade doesn't overwrite my work. Second, because I included the original control name I know exactly what the original file was and thus the intended purpose of the modified control.
Once the modifications are done, I simply change the customer scriptlets to reference the modified control instead of the default AC7 version. Not only does this make installation painless, it makes going back just as easy in the event the modified file did not perform as expected. Incredibly helpful when working on live sites.
The vast majority of the time, an upgrade doesn't break your existing code. It can still happen, but it's fairly rare in my experience. So any time I can keep my modifications separate means there will be one less thing to break when the upgrade is installed.

Making modifications to an existing storefront system should never be taken lightly. There are significant ramifications and responsibilities that come with those changes. As a developer and a consultant, I make a specific effort to notify each of my clients of the foreseeable impact their requested changes will have on future upgrades. It's my duty to advise them but not dictate to them. Should they choose to modify themselves into an "upgrade corner", well that's their choice. My job is to make sure they make an informed choice.


AC7 Articles | Personal

Figured out webparts today

by Joe Payne 14. September 2008 00:08

Well I needed a break from all the projects this weekend, so I took the challenge of learning how webparts work in .Net.  Kind of weird with how they're initially configured, so I skipped all that (isn't life fun when you can do that?) and went straight for making a new webpart.

 It's pretty slick - basically you can make any user control into a webpart by using an XML reference file to describe the webpart.  The tricky part was finding a useful example of one as it's not included with AC7.  Finally some digging through Google turned up some reasonable samples and I was able to get it working.

Now I can create useful admin Dashboard features that are both easy to resell and easy to install.  Can't get much better than that.  I made a nice article in the AC7 forums here and included a free pie chart web control in case you're interested.

Tags: ,

AC7 Articles | Personal

Month List