Is Your CC System Batch or Real-Time?
August, 2006I know we have talked about credit card acceptance here before, and you all know this old dog has learned that new trick. There are many reasons for accepting credit cards.
First, of course, is the fact that if all your transactions were by credit card, it would make my audit much easier. I would merely ensure that the software you are using got all the transactions to the right place. I also would ensure that your staff understood what it meant to "back out" a transaction and knew all the intricacies of such a procedure. In addition, I would be certain they checked your bank statement to ensure that the bank hadn't "backed out" a transaction from your account.
Banks are funny - they take the money from the card holder almost immediately, but returning it is another matter. Sometimes it takes a few days, and a customer could be in dire straights (i.e., tough times, not the rock group), particularly if they are using a debit card.
Consider this scenario:
Parking in the garage costs $350 a month. You have debit cards on file and you hit the customer's account for $350 on the same day once a month. Remember, this is coming out of their checking account; it is not a credit transaction.
What happens if, for some reason, your system happens to hit an account a second time that month. (Let's say your manager resets the time/date and gets it wrong. The software thinks it's earlier than it is and calls the bank for the money a second time.)
You immediately discover the problem, but the customer, who is living month-to-month in his San Francisco walk-up, suddenly finds his rent check bouncing, as he has $350 less in his account than he thought he did. It may take the bank up to a week to get the money back in the account. In the meantime, Joe Parker has checks that look like basketballs during the Final Four.
What about the other side of the issue? Joe Customer had his car scratched and blames you. He calls his bank and has it reverse the credit card transaction that paid his monthly parking fee. Unless your manager is on the ball, he or she might not even know it happened.
If you take credit/debit cards and automatically charge monthly parking to them each month, you have to pay attention to detail.
But now let's talk credit cards. Credit cards taken for daily parking can be a problem. Here's how:
Should your system be "online real-time" or "batch?" Huh? You young pups might ask about the difference. Well, I'll tell you:
In batch processing, you collect the credit card numbers and then give them to the bank each night for processing in a single batch. This means you don't know whether or not the card is going to be rejected by the bank until the next day. The customer has come and gone, and if the card is rejected, you are basically screwed.
Online transactions complete the transaction then and there, while the customer is in the lane or in front of the pay-on-foot machine. If there is a problem with the card, you can deal with it and collect your money another way. (Can anyone say "cash?")
With the Internet today, most new systems are online. But you would be surprised at the number of systems that are not.
Some say the increased speed (instantaneous in batch mode versus four to eight seconds online) is worth the risk. I wonder?
Most banks charge more for batch processing as, in some cases, if you have a floor limit (i.e., the bank will pay no matter what if it's under, say, $20). After all, they aren't going to take the risk. If you are online, they have little or no risk. If the person is a deadbeat, they will have cut them off and all is right with the world.
But, you say, this happens so seldom that the risk is minimal to the garage operator. I beg to differ. I know of a couple of studies that have found the loss can be substantial. In one study, a garage that did $5 million a year had losses of about $100,000 due simply to batch processing and credit card rejection - and obviously not all their transactions were credit card.
So, you pay more per transaction and you have a potential for a rather large hit on your bottom line. Is it worth it to convert to a real-time system? I would think so.
This is a case of your having to know the answers before you ask the questions. Did you know there are revenue control systems out there that require the operator to "key in" the credit card data every night? Can you imagine the error problems? Do you know if your system is real-time or batch? Are you sure?
Some companies charge more for systems that are real-time - and owners don't want to pay the difference. Penny-wise, pound-foolish, I would think. Spend the money upfront; you will get it back in buckets later.
For those of you dozing in the sun, I will summarize:
Credit/debit card systems are extremely detail-driven. You must make sure you know what you are doing at all times. Also, there is a big difference between batch and real-time processing - and real-time is the way to go.