|Realtime Credit Card Processing|
| 7:52 am on Dec 11, 2009 (gmt 0)|
I've avoided this for a dozen years, but I'm considering making the plunge.
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.)
| 10:33 am on Dec 11, 2009 (gmt 0)|
I know that probably 20% of our customers simply ignore (or don't understand the difference) between a billing and shipping address
I agree but they probably know that the address on their credit card bill is different to the address where they want the goods delivered. Either avoid or qualify jargon terms on your web site.
| 11:00 pm on Dec 12, 2009 (gmt 0)|
Valid point, and I also think for a lot of them it's that they don't want to type out TWO addresses (heck, maybe the can't even 'type').
Would be interested to hear what landmines others here have stepped in (or avoided) with realtime processing.
| 11:20 pm on Dec 12, 2009 (gmt 0)|
|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.
| 11:21 pm on Dec 12, 2009 (gmt 0)|
|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.
| 12:38 am on Dec 14, 2009 (gmt 0)|
Reading these boards can produce a lot of fear. Fortunately, my clients have escaped them all so far (knock knock.) I've seen maybe five legitimate fraud attempts, so obvious it was funny.
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.
| 4:23 pm on Dec 14, 2009 (gmt 0)|
But they still call to see if it's in stock
My mother's birthday present was "out of stock", it arrived 48 hours after ordering well in time for her birthday.
Too many sites do not give real time stock figures and people will quickly learn to distrust them, even on the sites that do it right.
| 10:32 pm on Dec 14, 2009 (gmt 0)|
I believe once you go real-time, you'll never look back and wonder what took you so long to take the leap. Most of the up-front concerns (for us anyway) are nullified by the time and even frustration savings that you'll have by elmininating communications with customers over things that arise from no real-time error-checking and authorizations. It's soooooo nice to say bye-bye to having to engage them about declines, typos in the numbers, resubmitting the info, etc.
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.
| 2:36 am on Dec 28, 2009 (gmt 0)|
I think alot of the issues will depend on volumn of sales and the value of each sale. Issues we face processing transactions for conferences in the hundreds (if not thousands) of dollars is vastly different from someone selling small dollar retail items online.
- 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.
| 5:39 pm on Jan 5, 2010 (gmt 0)|
Rocknbill and Brett are right on the money, especially - ROFL
|It helps to repeat the following: I am not Amazon. |
| 7:29 pm on Jan 8, 2010 (gmt 0)|
Its quite a challenge, took me a month to implement, as its quite a technical challenge.
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]
| 7:38 pm on Jan 8, 2010 (gmt 0)|
Since this is a first stage for your credit card dealing via website, I will recommend that you first try:
Payment Gateway, Merchant Accounts and/or Online Credit Card Processing Services, this might add to costs, but leverage your burder from additional problems :)
| 8:39 pm on Jan 8, 2010 (gmt 0)|
|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.
| 1:24 am on Jan 9, 2010 (gmt 0)|
|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.
| 2:15 am on Jan 9, 2010 (gmt 0)|
|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.
| 2:38 pm on Jan 9, 2010 (gmt 0)|
do you know any "real time" credit card processor ? How to allow this ?
| 2:28 pm on Jan 11, 2010 (gmt 0)|
Does anyone know what happens in the following scenario with pre-auth'ed cards?
1. Enduser makes (fraudulent) purchase, pre-auth transaction
2. CC owner reports card as stolen
3. When attempt to settle the charge ... is it declined?
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.
| 9:50 am on Jan 18, 2010 (gmt 0)|
No no no, unless you have very deep pockets and can take 10%+ loses from fraud don't even consider real time CC payments.
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.
| 11:01 am on Jan 18, 2010 (gmt 0)|
|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.