Credit Card System Flaws and the Online Merchant


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 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.

Abandoned basket reminders finished

Finally some significant progress on the AbleCommerce Job Scheduler project.  All it took was the fear of 12 inches of snow and the obvious result of 12 inches of snow.  The phones have been quiet all day, so I made some huge progress.

 Basket reminders are written.  I'll be testing those this evening and tomorrow locally, then pushing to live for the usual sorry-my-site-sent-you-27-emails-sir testing.  Now if I could just get the Visual Studio debugger to cooperate this evening, I'd be a happy puppy.

Here are some screenshots of the final module pages – had to break everything up into 3 pages as the new features were making for quite the bloated one-page configuration.   

scheduler-image1.jpg (162.70 kb)

scheduler-image2.jpg (168.01 kb)

scheduler-image3.jpg (194.28 kb)

How to make Windows XP automatically log in

Windows XP Automatic Logon

Why it's so hidden is a (yet another) Microsoft mystery.  But here is how to make your Windows XP startup automatically go straight to the desktop without prompting to log in.

  1. Boot your Windows XP to your desktop
  2. Click the Start menu and choose Run…
  3. In the run window, type control userpasswords2 and press enter

A window like this will appear:


Uncheck the Users must enter…..  checkbox.

 When you click OK, Windows XP will prompt you for a default username and password. 

Now, set the User name and both password fields to match what you had been using to log onto your computer.

Click OK and you'll be returned to your desktop.  Reboot your PC to test/verify the change worked.

Getting closer

Finished subscription reminders for the Job Scheduler tonight.  It's not live-tested, but I've walked through the code enough times that it looks solid.  It shouldn't take long to work out any minor bugs that appear – the code isn't all that complex just "bulky".  I could rewrite it twice more and probably still not be happy with it – always a good sign it's time to move on.

Now for abandoned basket reminders.  The design model is probably going to be very similar.  Give the site admin the opportunity to schedule a specific number of generic reminders with a single final reminder.  The icing on the cake will be the ability to assign a coupon code to the whole process so that if/when the final message is sent, the user is automatically added to a security group and the coupon code goes into effect.  This'll allow the site admin to toss a hail-mary teaser coupon to save the basket sale.  Hopefully the coupon code will work out to be anything coupon-able i.e. discount, free shipping or whatever.

The configuration page is getting too large – going to have to break it up into multiple pages (not ideal) or clean it up.  More options mean more flexibility but coding for all this stuff is slowing down everything.  I'll have a better product in the end, but it's difficult to see the end with so much extra coding involved.  Guess time will tell.

NexTag feed format support in Feed Builder

According to the tech documents from NexTag, they support both and file formats.  As a result, there is no need to write a specific NexTag format given Feed Builder already generates both of these formats.

Alternative to Server.MapPath in a class file

The Server.MapPath function a very useful, but it requires an HTTP Context or a Null exception error is thrown.

In situations where you don't have an HTTP context like a property in a class file, a slightly different approach is required.  I had to do some digging but I found this and it worked perfectly for me.  Let's say you have a String property on a class and you want a separate READONLY property to represent the full Server.MapPath equivalent.  Instead of using Server.MapPath("~/"+Me.OutFile), just use this:

System.Web.Hosting.HostingEnvironment.MapPath("~\" + Me.OutFile)

QuickBooks remove old company files from Open Company window

QuickBooks has a handy feature showing you the most recent company files you've opened.

 Unfortunately, once you've move a company file to a new location and open it, you'll now see the same company listed twice in the Open Company dialog box.  Not to worry, this is easy to fix altough a bit buried.

First, open any company file.  Once the company file is open, then select the File menu, choose Open Previous Company and you'll see an extra menu option Set Number of Previous Companies…

Set this option to 1.  Now quit QuickBooks and reload it.  Now you'll see only the company you just opened.  The list is now cleaned up.

Got more than one company file?  No problem.  Just leave the previous companies setting to 1 and open each other company one-at-a-time.  Be sure to quit QuickBooks after you open each one.

On the last company file, change the previous companies value to however many companies you have.  Now the list will show only the ones you've recently opened.  Since these are your valid company files, you're done!

I recall there being an easier way to do this, something with a file in the C:\Windows folder.  But I couldn't find it, so I suspect that involved older versions of QB.  QB has to be storing it somewhere though, so there's gotta be an easier way.

Job Scheduler almost ready

Well I gave Job Scheduler the longer-than-usual testing period.  I've had too many bugs crop up in some recent software modules and that's not good for my mood or customer perception.  This always equates to insufficient testing time on the development side.

With job scheduler, I decided to force myself into a two-week process.  Of course this time, no bugs showed up after a serious two-week run through.  Figures Smile

Regardless, it was necessary.  Granted the software releases later than I want but at least I know my customer sites won't be throwing exceptions left-and-right.

I'm still on the fence with how to handle Feed Builder.  The Job Scheduler is an enormous benefit with Feed Builder as you can fully automate the CPC marketing feed generation.  However, my original thinking was that they would be separate products.  Well I can't exactly make references to another product without actually including the product – the compiler will refuse to compile the module.

So it seems, at least right now, if I want to automate feed builder generation then I'll have no choice but to combine the two products.  Guess it's not a major deal, but I would like to still keep prices reasonable yet feel some sense of financial reward for my efforts. 

Next step is to redesign feed builder so that it will work with job scheduler.  Then do some documentation, package it up and test-deploy to since it's a clean AC7 install.  Revise the documentation, clean up any little details and then set a release date.  Whew!  Software releases aren't easy at all.

SOAPException error Maximum Request Length Exceeded

Came across an interesting issue this week.  A customer encountered an unexpected error with the QuickBooks Web Connector after functioning just fine for months.  Based on the Log files, the system was throwing an exception when it tried to read the customers from QuickBooks and transfer the list to the AC7 web service.

After some really deep digging, the exception message was noted and revealed a curious limitation.  By default, SOAP commands/responses are limited to 4Mb in size.  Anything larger will throw an exception on the site.   This could easily happen on larger QB company files with a big customer or product list.

The solution is pretty simple: 

  2. Modify the Web.config file in the root of the site
  3. Find the <system.web> section and add a new line below it.
  4. Insert the command <httpRuntime maxRequestLength="8192" />
  5. Save the web.config file

The 8192 value represents an 8Mb limitation.  If this isn't enough, simply make it large enough to handle your particular needs.