Ecommerce Stuff Nobody Tells You

Well, we’ve solved our latest credit card validation problem and it seems like a good time to give a quick recap of the lessons we’ve learned during this whole sordid process. Things that nobody bothers to tell you, not even the people you’re paying to do just that. This is 2008, but credit card processing is a technological throwback to the Dark Ages.

Things nobody bothers to tell you, version 1:
  1. The web sites for credit card processors & merchant account services are completely useless. Do not try to use them, not even the big fish that everybody respects (e.g. Authorize.net). You will only waste your time. Instead, call their tech support. We’ve found their human support to be unfailingly friendly and helpful, at least when it comes to answering direct questions rather than making suggestions (hence the Stuff Nobody Tells You). The hold music’s so beyond awful it enters into laughable, though.
  2. If you want to process AmEx, you have to call them directly, set up an account with them, and then talk to your merchant account service. Just because your CC processor’s interface shows you that AmEx is active, and your merchant account people tell you that everything is systems go, doesn’t mean there aren’t hidden things you have to do to, you know, actually process cards. Or that the errors will be helpful.
  3. Address verification (AVS) is voodoo. Not real science. AVS is inclined to reject real, valid cards all the time, even when you don’t count “user errors” (e.g. your bill says Apt 4 and you put #4). D’oh.
  4. Test charges are pretty much unavoidable. So, since AVS essentially doesn’t work, the way to verify a card is to make a tiny charge on it and then void the transaction. It’s not a charge you’ll ever collect on, but it’s not exactly a hold either. To us, it’s a bit squicky to think that this is the only way to verify a credit card number in this, the 21st century.
  5. Some banks will reject small test charges. About 10% of cards used to sign up were declined. Thanks to Stuff item #6, we couldn’t tell why from the error reports. Nobody could tell us why, either. We called Auth.net and they had no suggestions. We only found out as fast as we did because one would-be customer, our friend (& tasty designer) Johnny Bilotta, called his own bank to ask if there was a problem. Trying to be considerate internet citizens, we had set our test charge to $.01. His bank told him they reject small test charges under $1.00, but our credit card processor never thought about it. Even though it’s their business. Useless buggers.
  6. Errors are incomprehensible and your credit card processor is useless at helping you solve validation issues. The error you’ll get in most cases is General error. In other cases, you may get Declined, but there’s no way to tell why. Calling your CC processor won’t help you, either, because in many cases, they can’t get more information than you’ve already got. In other cases the phone reps just aren’t trained in spotting what must be common problems (e.g. the low test charge).
  7. When you ask why stuff doesn’t work, even due to Stuff Nobody Told You, they think you’re kinda dumb. Despite the support being, as we said, unfailingly friendly, there are always these awkward pauses when we’ve asked about Stuff Nobody Told Us. For example, when we called and said “So our account says we can accept AmEx but they’re all being rejected. Can you help us?” The nice lady asked, “Well, are you set up for AmEx with your merchant services provide?” and I said “No, what do you mean?” Awkward pause ensues. The lady assumes she is speaking with a polite nitwit and then the rest of the conversation takes twice as long as it would have if she hadn’t thought I had a room temperature IQ. Which is too bad, because there’s no documentation or on-ramping process that tells you this, and nobody thought to mention it, either, when I asked if I made the calls to both Auth.net & the merch acct people to ask “Hey, we’re going to live. Do we have everything in place?” last week.
That’s all for now, but I’m sure there will be more.
For more real-life depictions of Ecommerce Surprise, & more harrowing stories of our adventures in setting up a paid web service: Subscribe. You know you want to.

23 Responses to “Ecommerce Stuff Nobody Tells You”

  1. thomas Says:

    What I personally find most disturbing is that credit card processors and banks are expecting you to know their lingo. When they even themselves don’t know.

    Oh, and when the help links open with a 404.

  2. warpedvisions.org » Blog Archive » Tips on setting up eCommerce Says:

    [...] 3rd, 2008 in Links The Freckle guys tell us about eCommerce stuff nobody tells you. They’re right too, it’s a [...]

  3. Derek Says:

    Interesting problems your having. Are you going with Auth.net?

    I have to say, as a developer, I love trustcommerce.com. They have API’s for every language (including Ruby/Rails), automation for billing, and gasp a developer API…with documentation and code examples!

    They also have test card numbers they provide you so you can verify all the different validation cases through their system, with documented error codes.

    Maybe you should check them out? I’ve never had to call them.

    …oh they also support AmEx out of the box, never had any issues with that myself :/

    …and I don’t work for trustcommerce, just a happy customer :)

  4. amy Says:

    Derek, where were you 3 months ago!?! ;)

    Seriously, “TrustCommerce doesn’t publish pricing because we understand the market and the products.”

    Tell me how you got onboard with these people without calling them. Their web site’s incomprehensible and they tell you don’t need to worry your sweet little head about pricing because they understand the products.

    I’d consider trying them out if I hear more rave reviews. And yes, we’re using Authorize.net, which is not really a move I could recommend without reservations.

  5. Devan Says:

    Wow! we must have been lucky to find eWay here in Australia (www.eway.com.au). They set up all the links to our bank merchant accounts, even set up Amex card acceptance for us with minimal hassle (on our part at least). Now they are assisting us with direct bank debits for some of our customers as well.

    They even have a rebill facility for ongoing charges which works really smoothly.

    Their developer API is so simple I thought there was something wrong at first!

    Unfortunately, I think they only support Australian banks I believe (and I say that with just a slight veneer of smugness after being rejected by many other ecommerce gateways with “Sorry, US banks only”!!) :)

    Anyhow, congrats on getting Freckle up - it looks great.

    Cheers,
    Devan

  6. Lakshan Says:

    Hi Amy,

    I think you did Freckle with Ruby on Rails. Are you using Active Merchant to interface with Authorize.net?

  7. Roger Says:

    Here’s another vote for TrustCommerce - especially for subscription processing.

    We’ve intgrated with their API and have been using them for a few months - no hiccups and so far all is well.

  8. jakehow Says:

    Here are a couple of other tips:

    Your processor account is set up specifically for the gateway you chose
    This means that if you switch gateways there is likely a config flag in the bowels of one system or another that no one on either side of the equation is ever going to remember until you go live and charges start disappearing into the aether. Oh, but by the way the awesome part of this ‘feature’ is that all these charges returned approved, and you just never actually get paid :) The only way to deal with this is to be eagle eyed about it if you are going to switch gateways on the same account, and call the merchant bank (the guys above the internet gateway you chose) and confirm everything 10 times.

    Merchant bank employees will do scary things
    After one support call, an employee of a merchant bank emailed me in plain text a list of all the charges that were failing, including full card details.

    Regarding TrustCommerce, they are great once you get an account. Good luck with that though, you basically have to set up a bear trap outside of their office, and hope you snag an account rep. See Robby Russell on this issue: http://www.robbyonrails.com/articles/2008/04/16/review-braintree

    There is also Braintree(http://www.braintreepaymentsolutions.com/) that he is reviewing in comparison, which seems a lot like TrustCommerce from a feature perspective, except they answer the phone when you call and have told me they can setup test accounts in a few minutes. They recently decided they only want to deal with customers doing US$1mil/year or more, however they have also said they like the Rails community and will make exceptions for us.

    Here is the message from the rails-business list with that offer: http://groups.google.com/group/rails-business/msg/53da3705df6063a2

    I am using TrustCommerce and their support is very good once you are up and running. Part of the reason for this is that the products are solid and once you have it set, you can leave it alone completely, so you do not actually need the support all that often. I think this is a pattern across the industry, finding the provider with the smoothest setup is the challenge.

  9. jakehow Says:

    And by the way congrats on the launch the product is very cool and the github integration is awesome!

  10. mattly Says:

    wrt AVS:

    for US addresses at least, in my experience it only cares about the first number in the address line. This is usually the street address. If the customer’s billing address is “342 NW 3rd Ave Apt 56″ it only cares about “342″. This gets trickier with rural Utah-style addresses such as “Oak Tree, 123 S 45 W”, where sometimes it wants “123″ or sometimes “12345″.

    Hell, for a while I had a billing address that had a “1/2″ in it, such as “1234 1/2 Crowded St”, and sometimes AVS wanted “1234″, sometimes it wanted “123412″ and sometimes it wanted “12341″.

    I have yet to figure out a pattern for non-US AVS, it seems to vary by country.

    Also, don’t get me started on how the entire premise of credit card transactions is based on “we are taking money from you” instead of the more prevalent elsewhere outside the US “you are sending money to us”. Are we surprised there’s fraud?

    My non-US customers want to do bank transfers, and I have to explain to them why the US banking system pretty much makes that infeasible.

  11. Kendall Schoenrock Says:

    Johnny Rocks!!

  12. Jeff Says:

    What you forget to mention is how terrible these guys are at fraud protection. Visa is basically deaf, blind and stupid about fraud detection…and when you discover something that is easily a stolen credit card, there is no mechanism to report it, and disincentives to help the customer. Plus…the challenge billing process is far too expensive to deal with. Amex will just cut you off after 1-2 challenges. The others will just swamp you with fees (a great business model for them). It is a nightmare, and not particularly better from 1996 when I first started doing this.

  13. Toby Says:

    I’ve use paypoint.net for some of my old web design customers, they’ve got pretty decent documentation and the time ive had problems getting code running they’re tech support has been very useful.

  14. Sean Says:

    We had some similar problems when we wrote our own credit card processing software for Clicky. We use auth.net, and our merchant is with CDG: http://www.cdgcommerce.com/

    With CDG, you don’t get AMEX by default, but it tells you taht on your “dashboard”. All you do is click a button and wait a few days and then you have it.

    Figuring out the specific reasons for declined transactions is the biggest problem by far. About half of the declines we get have an error code, but the other half don’t - just “declined”. It’s a proceses of trial and error, monitoring each failed transaction to try to figure out why it failed.

    The most common reason for a decline taht just returns a generic declined error is when the expiration date doesn’t match. So when we get a declined transaction, one of the “tips” we display is to double check the expiration date, because auth.net won’t tell us it’s wrong.

    And for the card code, sometimes it returns the error that it didn’t amtch, but sometimes it doesn’t. So we also display that tip as well: “Please double check the card code”.

    International AVS is annoying too. More ethan half our customers are international, but I’d guess that only 1/3 to 1/2 of the transactions actually have an AVS check done on them.

    Luckily, you, like us, are selling a service and not tangible goods. This means there will be almost no fraud involved. 6 months and thousands of transactions later, we’ve only had 1 chargeback. So that’s good.

    I’m glad I took the time to integrate this ourselves rather than paying for an existing product or having someone else do it for us. It is a great learning experience, and being able to put on your resume that you’ve written credit card processing software is a great thing.

  15. Sean Says:

    Oh yeah, forgot to say, auth.net’s documentation for their API is pretty bad. That was frustrating for development. I mean it covers most things, but there were also a lot of thigns I had to figure out myself via trial and error.

    As for support, I’ve never called them, but I’ve probably emailed them a good 10 times. Usually I’ve gotten a generic form response that is no help, but sometimes they come through and actually read my question and respond with a real answer. Unfortunately, even then it’s usually not too helpful, but a few times their support has come through for me.

  16. Derek Says:

    @Amy, feel free to give me a buzz if you want to know more about TrustCommerce.

    I pretty much was “grandfathered” into a project that was using it. At first, I had that payment gateway sinking feeling in my stomach, but to my amazement, its actually a great service!

  17. Stephen Says:

    I totally agree. It amazes me how sketchy all the payment gateways are. I’ve spent a significant amount of time working with Auth.net and Linkpoint. Actually, I have had very bad experiences with customer support on both of these too.

    I recently switched to using Paypal Website Payments Pro. The documentation is still almost worthless, but I feel much more confident using Paypal than the others. They’re just much more professional.

    Also, another thing that took me a while to figure out at first was that you’re usually dealing with resellers, and that means you should be able to negotiate on the rates (I talked Linkpoint way down, but Authorize not so much). When we’re talking about something as important as processing payments for my company I’d rather feel like I’m paying a set price for a well-thought-out service, and that’s another thing I like about Paypal.

  18. Dat To Says:

    You are right. These companies live on confusing people because it somehow works for them 80-90% of the time and they make a ton of money. They have $12-14/hr employees who have a set script and if you ask anything outside the ‘norm’ you get someone else. Whenever I deal with them, even the ‘good ones’- it takes a week to do just one thing and the attitude!

  19. Prakash Sankar Says:

    Auth.net and other gateways charge a lot of fees. We went that way and burnt our fingers.

    Best is to integrate google checkout and paypal using their apis and concentrate on your core competency.

    your customers will thank you for it.

    Thanks.

  20. rick Says:

    I just can’t comprehend that whenever there is a problem it is always someone elses problem. The bank, the merchant , the processor, the batcher. It is silly how many grubby hands are trying to sop up a few dimes.

  21. Sean Harper Says:

    This is a really cool guide, thanks. I started an ecommerce business (http://www.tss-radio.com/) four years ago and have been consistently frustrated with the market for credit card processing.

    Nobody is transparent about their pricing, they have obtuse lingo, none of the companies are used to marketing on the web and the point of contact is usually a salesperson that has very limited understanding of online business.

    Last spring a business partner and I started a company that is similar to LendingTree, but for credit card processing. You enter a bit of information about your business and get back binding bids from credible credit card processing companies, from which you can select (or not) without any pressure or sales BS. The product is still in beta, but we think it’s pretty cool and our initial customers are happy. We are also a RoR shop.

    Check it out, we would appreciate any feedback on the service.

  22. Robb Lejuwaan Says:

    I agree with almost everything you are saying. I will say there is a science to AVS and most of credit card processing.

    The problem is there are very few “scientists’ out there studying the subject. If you ever have any questions about this stuff feel free to ask me; If I don’t know the answer already I’ll find one for you.

  23. Shira Says:

    Wow that is a long list…I tend to agree with all. I found out that minimizing some of it depends on the way you negotiate your merchant account. I applied with few providers (used http://www.creditcardprocessing-r-us.com- a directory that features few merchant account providers under the same roof) and just negotiated everything, fees terms and support. At least now I have a dedicated merchant account manager that has to speak with me!

Leave a Reply