Debit or Credit?
I probably should also mention that, just as there are credit cards that cannot function as ATM cards, there are ATM cards that cannot function as credit cards.
Either way, Visa and MasterCard charge far less for debit cards being used as credit cards than they do for credit cards! The argument (made several years ago by Wal*Mart and a judge) is this: If the payment is coming directly from a customer’s checking account, and the transaction is authorized based on whether the money is there or not, why should this transaction be as expensive as a credit card’s? Compare “they either have the money or they don’t” to the risk involved with a credit card’s “they promise to pay us later” approach.
For an example comparing the costs I’ll use a retail processing environment and assume the customer is using Visa. Whatever your rate is for a regular consumer card where you got a signed receipt, subtract 0.51% and add $0.05 for the same transaction done with a debit card. That should be your cost.
0.51%! That’s a huge discount. And yet, many processors don’t inform their merchants that Visa charges so much less for debit cards. Let’s face it, 0.51% makes a fantastic addition to a processor’s profit margin if you’re not getting straight pass through.
But Wait! There’s More!
Now, as if that isn’t enough, being able to act like an ATM can create even greater savings! Now, the cost to the processors varies a little from debit network to debit network, and all processors will want to take some profit from these transactions. That being said, check out the following example:
You carry a $100 widget. Three customers come in to buy one widget apiece. Customer A will use a regular consumer credit card, Customer B a debit card that he signs for, and Customer C a debit card that he’ll use with his PIN number (as if at an ATM).
Customer A = $2.04 (1.89% * $100 + $0.15)
Customer B = $1.58 ((1.89%-0.51%) * $100 + $0.15 + $0.05)
Customer C = $0.45 (flat per item fee)
The difference between A and B would be a 23% savings if A actually had a check card and your processor wasn’t giving you straight pass through. But the difference between A and C would be 78% if A had a check card and you had him enter his PIN!
However, you may want to consider your ticket sizes. Take the following example, where we’re changing the widget’s cost to $8.
Customer A = $0.30 (1.89% + $0.15)
Customer B = $0.31 (1.38% + $0.20)
Customer C = $0.45 (D’oh!)
If you sell almost exclusively very small ticket items, you may wish to ignore PIN-based transactions. However, as most merchants are doing $15 and up, depending on what pricing you’ve gotten, PIN-based is the way to go. If you’re a large merchant doing thousands of transactions a month, it may be worth getting sophisticated equipment that you can program to automatically ask for PIN numbers when tickets are larger and automatically ask for signatures when tickets are small. Which leads us to:
Getting the Most Bang
I used to have clients voice concern that customers would say “credit” when asked “Debit or credit?” Here’s an easy fix: Don’t ask. All you readers out there who’ve been to Target or Best Buy or wherever have experienced the little machine that, when we slide our debit cards through, instantly ask for our PIN. By not asking, you’re doing the verbal version of what Target does. (They, by the way, have a variation of those systems I mentioned above.)
Here’s the caveat: It’s against the rules to force a customer to use their PIN instead of their signature. The brilliance of the “don’t ask” method is that it puts the onus on the customer to request the other payment form. Most customers (myself included) figure, “Whatever—It’s coming out of my checking account either way,” and happily punch in that PIN number.
DO CASH REFUNDS FOR PIN TRANSACTIONS!!!
I can’t emphasize the above enough. It’s very rare, but every now and then an employee gets taught how to run transactions, PIN-based or signature-based, but isn’t told that he needs to refund cash for PIN-based transactions. And this can cause headaches. Here’s the background:
When you run a credit card transaction, the request for an authorization goes from you to the acquiring bank (the bank that’s in charge of giving you your money, then goes and “acquires” that money from the customer’s bank) who then forwards it to the customer’s bank (“Hey, does your cardholder have enough credit?”) Assuming your customer has credit, his bank will place a hold on that amount of credit and tell the acquirer to authorize the transaction. The acquirer then issues you that authorization.
This is also the procedure when a customer uses a debit card like a credit card, except that the hold is placed on actual funds. In either case, the money, whether actual funds or funds on credit, stay where they are until the transactions are captured—that is, you’ve settled a batch. At that time the acquirer will start the process of giving you your money and collecting its money from your customer’s bank.
Now, debit transactions function differently. When your customer enters that PIN, the request for an authorization goes to the acquirer and on to the card-issuing bank. Then the issuing bank withdraws the funds!!! and sends it to the acquirer, who then holds the funds and waits for the batch settlement.
What?
Yup, your customer’s account is debited immediately, as if they did an ATM transaction. In fact, an ATM transaction is basically what happened. (I’m sure you’ve been prompted for “cash back.”)
But you won’t get your money until the acquirer gets that batch. This is where the refund can become an issue.
Because the transaction is essentially a debit withdrawal, you can’t just reverse debit transactions that are being refunded. If you or an employee attempts to do so, that transaction is considered corrupted and will prevent you from settling any batch with that transaction in it.
The headache is that you’ll likely need to clear your terminal and “offline” (hand-enter and accept the price downgrade) all the credit card transactions for all days you haven’t batched.
However, debit transactions cannot be entered offline—this would double charge the customers as money was immediately withdrawn from their accounts—and you will be unable to capture those transactions to release the funds from the acquirer. (To do so would require knowing your customers’ PINs, and you don’t want that.)
Your fix here is to contact your processor and ask what the process is to get those PIN-based transactions “captured” so that the acquirer will release those funds to you. Have receipts and your batch reports clearly marking which transactions were PIN and which were not. You may also need to include a letter explaining what happened and what you need done.
Better yet, make sure employees know to give those PIN-based refunds in cash, rather than through the customers’ cards! (Remember, you’ll want to have enough cash on hand to cover any big-ticket returns!)
Still, taking PIN numbers for card-present transactions is one of the easiest and best ways to reduce your fees. The risks are far outweighed by the positives, and are easy to avoid. And due to so many people attempting to avoid increasing credit card debt, and the avoidance of carrying cash, debit cards use is rising.
So if you can, take those cards, get them at cost, and start saving a bundle!
(John Robinson is one of Robb’s compadres at US Merchant Services. He has previously been published in a letter to Inc. Magazine (”Shedding Tiers”) referring to an article on reading merchant statements. If you wish to reach him, just click here, or call 714-827-7000 x220.)
Like this post? Then subscribe by RSS | Email
Print This Post
|
Email This Post
Related Posts







Leave a Comments »
Trackback | RSS 2.0
no comments yet - be the first?