[thelist] Credit card validation

Keith Davis cache at dowebs.com
Sun May 27 04:15:07 CDT 2001

"Charles F. Johnson" wrote:

> Please don't get the wrong impression; there are no illegal intentions here!

Excellent, and understand my warnings are not particularly directed at
your client, but are also being offered quite broadly because there are
thousands of list members reading this thread who may have similar

> The request was made because, apparently, when the orders are imported into
> their database the authentication step is skipped. But this is why i'm
> asking, because i want to make sure everything is done according to the
> rules, and it seemed unusual to validate the card without charging it.
> We'll probably recommend that they do the validation step the same way they
> would for a phone order (i.e. manually); at this point I don't know all the
> details of their merchant account, whether it's an MO/TO account or not. But
> your warnings about possible liability are not falling on deaf ears...

You say they are importing "orders". I take that to mean that they are
actually going to charge the card and ship product. I also take it that
they now do a manual validation for phone orders. That word "manual"
throws up a red flag here, I take it that they are manually keying the
card number into their swipe machine. If that is an OTC
(over-the-counter) machine they are in violation. It could be a MO/TO
machine, in which case pass go, collect $200, and land on authorize.net.
But chances are it's an OTC so I'll proceed here with that assumption.
If so, then they are indeed getting a simple validation of the card
number and it's availability of credit for an amount. All OTC accounts
allow this, to a small degree. 

Take the old time convenience store that sells gas and has a sign at the
pump "Pay Before Pumping". Customer runs in and plops down his card and
runs back out. The experienced clerk quickly swipes the card and
validates it for $40 before turning the pump on. He now knows that the
card is not reported stolen and has credit for a tankfull. That kind of
thing is what the "validation" is for and it can be done by
"manual-entry" since some cards are unreadably worn. But, if the clerk
does this 3 times in a row with different cards the bells go off in
Omaha and the store gets an urgent call from the card processor asking
for the owner/manager. 

So now we get to the step of how your client actually charges the card,
presumably again through their OTC swipe machine by "manual-entry",
requesting a "charge" this time. An OTC account also allows for this, to
a degree, again because some cards are unreadably worn. But, if the rate
of "manual-entry" charges exceeds a threshold, bells go off in NYC at
merchant services. This time there is no phone call. This time an ISO
makes an onsite visit. That threshold will vary from 5% to 15% of total
credit card transactions depending on the nature of the business. 

Now, your client's web sales may not exceed 5% of his total credit cards
sales. He may use his OTC account to process what should be MO/TO
transactions for a long time without setting off any bells anywhere. 
But everytime he does it he just increases his potential for loss should
he get caught at it. 

> We'll probably recommend that they do the validation step the same way they
> would for a phone order (i.e. manually);

Please Charles, do not do that. From what you have told me, you would
actually be recommending that your client continue to violate creditcard
regulations. And you do not have to put yourself in that position.  What
I would recommend to you is to be right upfront, tell him that you've
researched the situation and from your limited research you think he
needs a MO/TO type merchant account. He may be innocently unaware! If so
you just put a major feather in your cap. On the otherhand, he may
respond to that the way many small businesses do, "Yeah, yeah, I know
all about that crap and I'm not going to waste my time on it." If that's
his response you have a built-in safety mechanism to keep from being
entangled in his violation, without recommending anything.

He wants to do the validation live-time. That will require going through
a bank or authorize.net or some other gateway since you cannot connect
directly from the website to the processor. Guess what, they'll require
a MO/TO account to hook him up and they'll know right off if it's an OTC
or a MO/TO. They are programmed to send web transaction "book" and
"capture" codes and an OTC account requires "validate" and "charge"
codes. Remember most of these third party gateways make their serious
money selling MO/TO accounts and they do not pass up this opportunity.
(Some gateways can do OTC, but they are strictly for instant delivery of
electronic download or restricted access. They are considered a "cash"
transactions. Using one of these gateways to process transactions for
shippable hard goods is not just a violation of creditcard rules, it
crosses the line to willful criminal fraud. Don't even mention them.) 

Since you cannot physically do the validations in live-time, offer to
save the transactions on the server and provide a secure SSL page or
secure SSH connection that will allow him to pull the orders off the
server. That's it, you've done your part, the transactions have left
your hands, your area of expertice, and your responsibility. How he then
processes them, or with what type of merchant account, is then not your
business, you are not entangled in any of it once the data leaves that
server and the enablement you provided. You still want a holdharmless in
your contract to keep his lawyer muzzled should/when things go sour. 

Understand that the vast majority of MO/TO transactions are not done
live-time. Most of them are done by pulling the data off the server
periodically and processing them via offline processing software. The
only valid reasons for live-time processing is to automate things the
way your client envisions, or when the enterprise is distributed and
remote fulfilment centers will trigger the capture at the time of
shipment, or to avoid providing SSL and storing sensitive data on the

The last 2 reasons may be a concern. If the domain is name-based instead
of ip based you cannot install SSL. You can get a reasonably priced SSL
cert at http://www.equifaxsecure.com/. As for storing data, many
e-commerce sites assign a unique ID to the transaction and then email
all of the transaction to the merchant, except for the last 6 characters
of the credit card number. They save those 6 numbers and the ID on the
server. The merchant then retrieves them and matches them up to the IDs
on the emails. When I do this I also keep the amount, customer's name,
and phone number on the server, just in case the email goes into a black
hole. Never had it happen, but I sleep better knowing no customer is
going to be left wondering if his money fell into a black hole. 

I know I've worn your patience out with all this, but hey, I've been
doing e-commerce since before the term was coined. And I sold off our
e-commerce clients last Oct so I could get some perspective on what's
went wrong with the e-commerce industry in general. You just stepped in
front of a loaded gun Charles. Sorry, nothing personal...

Good luck, and say HI to Sally and Bob if you get down to Tampa.


More information about the thelist mailing list