Would you turn off security features to save an order?

by Neil Moncrief on April 28, 2009

One of my larger e-commerce clients called the other day. This merchant has been with me for about a year. The owner originally signed with me not because of the savings (and yes, there were savings), but because of the experience I had as a prior Internet business owner. Because this merchant sells high-value items, she enlisted my help with fraud prevention, and over the past year, we implemented a series of safeguards to cut down on fraudulent orders and the resulting chargebacks.

When I answered the call, it wasn’t the business owner on the phone. It was one of her newer employees. The young man (a CSR) had spent the better part of the day trying to complete a $4,000 order for a customer. Authorize.net had rejected the customer’s card numerous times, despite the card issuing bank’s insistence that it had authorized every transaction. The CSR was confused and wanted to know if I would help him “force the order through.”

After a few minutes of Q&A, the rest of the story unfolded. This customer had first contacted my client via phone, but he delayed placing his order for several days. Now that his card was being rejected, the customer insisted that the CSR keep trying, using a different variation of the address each time. The customer was also insistent that his order be delivered faster than the website’s estimated normal delivery time. So… the customer was casual at first, but now he was in a rush? My “uh-oh alarm” began to beep.

I answered the CSR’s question about “forcing the transaction” by asking a question of my own: Would the CSR accept responsibility if the transaction turned out to be fraudulent? Of course, he answered “no.” I explained how the website’s security measures worked, and why his boss wanted them in place. I told him that although it was possible to turn the features off long enough for the card to be approved, I couldn’t recommend it. I also pointed out that it can be a sign of trouble when customers are impatient or make unreasonable shipping demands.

Drawing from my own past experiences, I named several things that can cause similar problems. For instance, if the AVS match requirements are set too high, the gateway can mistake good orders for bad. Also, some card issuing banks will update a cardholder’s change of address just enough to get their statements delivered, but then leave the old address visible in other fields used by AVS. I explained to him how he could rule out those possibilities. Other than that, I reminded him that the security features were there for a reason, and I suggested that he allow them to do their job.

In the end, the customer turned out to be legitimate. When the CSR explained the situation, the customer wired the funds to the merchant. We never found out exactly why Authorize.net had blocked the authorization. Regardless, the security features continue to work 99% of the time. And the merchant remains confident in her safeguards, even it they do complicate an order from time to time. At least problems like this don’t result in chargebacks.

I’m happy to provide this information free of charge.  If you found it helpful, please subscribe to my RSS feed so you’ll be notified of future posts.  You can also follow me on Twitter, where I regularly post short tips.  I promise to never spam you or pressure you.  Please forward this to your friends in business, and feel free to rate my post or leave a comment so I’ll know how to improve. Thanks!

Leave a Comment

Previous post:

Next post: