Forum Moderators: buckworks
For those of you doing it, what are the biggest issues you've faced?
Here are some of my fears:
Fraudulant order attempts slipping through the automated system (then having to be refunded, while, of course, still costing us the card fees).
Customers that make obvious goofball mistakes (quantities ordered), etc.
LOSING customers because they get AVS failures, etc. - I know that probably 20% of our customers simply ignore (or don't understand the difference) between a billing and shipping address - ...(their PO Box is their billing address, but order has to be shipped UPS, so that' the only address they submit, or they are buying on their company card and shipping to their home, etc.)
I know that probably 20% of our customers simply ignore (or don't understand the difference) between a billing and shipping address
Would be interested to hear what landmines others here have stepped in (or avoided) with realtime processing.
Fraudulant order attempts slipping through the automated system (then having to be refunded, while, of course, still costing us the card fees).
Pre-authorisation solves this. The card is processed live and then you (at a later date) can choose to accept of refuse.
LOSING customers because they get AVS failures
Most don't fail on AVS or CVV not matching - they give you the information to decide but still accept the card.
Its one thing to be aware, and to take steps to prevent, another to allow fear to govern you - visit any "payPal hate site" for examples of hysteria.
Jump on in, here's something else to think about: every day you don't, you're missing an opportunity. :-)
Take appropriate steps in security, use common sense, use a reputable processor, you should be fine.
For those of you doing it, what are the biggest issues you've faced?
1) Getting over the "why" of cart abandonment. This will drive you bonkers if you let it.
2) I don't know how to word this . . . but #2 is figuring out how to make something that seems so obvious anyone can get it, more obvious, because people aren't getting it. I have a system in place on one site that CHECKS for stock disposition. If any item is out of stock, they **have** to get past a screen that tells them, "this is out of stock, what do you want to do?" They **have** to make a selection. But they still call to see if it's in stock. Related to #1, sometimes you're doing fine and obsess over the fact that you're missing something, and you're not.
3) Not as difficult for me, because I'm a programmer/coder, but for the "average site owner," a big one would be the security and reliability of the software interfacing with your processor. It may work, but how secure is it, and if it goes wonky, how will you know?
4) The whole "cost of doing business" thing. I have seen customers go through heaven and hell to use something like payPal, and when you stop to add up the things that go wrong and what it really costs you to save a few dollars, it winds up being more costly than "doing it right" with a full online merchant account. You can't hang a cost on "doing it right" and at least attempting to "look professional" versus a home grown, low bucks approach. By saving those few dollars, you cost yourself hundreds, or more.
5) Managing shipping. Too often people try to "keep it simple" and shoot their foot, or their developer does, in the process. Figure out an open ended method of handling this far in advance. There are API's for major shippers, and they are FREE (for now!) Set up your site, connect to them, use them, too few sites do this.
6) Understand PCI compliance and your role in it.
But they still call to see if it's in stock
Off the top of my head, the only time I could imagine NOT doing it is if the site was a really low volume site and that may not warrant the fees. In the early years, we manually keyed a lot of orders... probably for too long in hind-sight, but wouldn't dream of going back.
Landmines:
- Coupons. We have run into lots of issues with them. Think it through to the largest degree that you can. Any problem that can go wrong with coupons - will go wrong.
- Test your code to death. Make it bullet proof. Test and retest and retest.
- Reduce complexity where ever possible. Every step in checkout costs you a percentage of vistors. The lower the cost per item, the fewer the steps you have to have to checkout.
- Assume your system will be tested by hackers/fraudsters.
- It helps to repeat the following: I am not Amazon.
It helps to repeat the following: I am not Amazon.
What is always ongoing is balancing the right amount of security measures. Recommend you get this right from the start.
If its made too easy then you will get lots of orders, but fraudulent orders too - which will cost you money. If its too hard, then you will shut out too many potential good customers.
In the end, I coded in most of the security measures myself. I recommend you:
1) Database which customers you can trust, and which customers you cant.
2) Dont log card numbers (as in most cases, is against the law), but do log everything else including IPs, user-agent info etc as this will help you out lots when you do get a fraudulent order.
also second Bretts advice, test over and over, and assume that you will get hackers.
[edited by: Seb7 at 7:38 pm (utc) on Jan. 8, 2010]
Payment Gateway, Merchant Accounts and/or Online Credit Card Processing Services, this might add to costs, but leverage your burder from additional problems :)
LOSING customers because they get AVS failures, etc.
That's why I implemented real-time DECLINE ORDER NOTIFICATION.
Couple of things you quickly see:
a) if someone is trying to hack a CC you'll see the amount of purchase vary per attempt on each declined notification
b) if someone is just failing to order, you'll have captured a copy of the failed order and you can call them and help process the credit card manually in the event they give up
At a minimum, to avoid someone automating an attack to run up your bank fees (had this happen to a client), you'll probably want to limit them to 10 attempts. After 10 attempts which cost $0.20 per attempt, decline or approved on my gateway, it tells them that the site owner has been notified there is a problem and we'll call you direct to process the order.
Additionally, offering PayPal helps because people are pre-registered at PayPal so as a last recourse you can make this an easy option for those being frustrated by random AVS nonsense.
Pre-authorisation solves this. The card is processed live and then you (at a later date) can choose to accept of refuse.
I agree with this one. I've been processing ecommerce transactions for about 12-13 years now and doing a pre-auth at the time of sale (to make sure the funds are there) and then finalizing the charge once I ship the product really cuts down on fraud orders and chargebacks.
After the order comes through, then you have time to do your own fraud checks, look for red flags, make sure the stock is there, address is correct, then ship out the item.
Test your code to death. Make it bullet proof. Test and retest and retest.
And to further Brett's point, have regular smaller scpe testing done regularly. Some bigger businesses can / do afford to do this once a day.
We charge in realtime and it has significantly streamlined the order/payment process, but, every once in a while, will get an order on a stolen card that looks pretty innocuous (do a lot of b2b, so not uncommon for billing/shipping addresses to be different). My major concern is going past our cc merchant's chargeback threshold.
If someone is set on credit card fraud online it's unwise to have MORE sites available as entry points. The net just isn't secure, people can still surf without worry of repercussion even if big brother is watching.
Does anyone know what happens in the following scenario with pre-auth'ed cards?
1. Enduser makes (fraudulent) purchase, pre-auth transaction
You can ignore or cancel the transaction. Most providers don't charge you any fees until you accept the transaction, but this is not universal, a few do charge small amounts for each attempt.
2. CC owner reports card as stolen / 3. When attempt to settle the charge ... is it declined?
A pre-auth card is checked at the time the order is placed. When you accept the card, it is checked again and if the card has been stolen in the meantime (or at least reported!), it will come back as a rejected payment.
