[thelist] Credit card validation

[Charles F. Johnson]

Keith Davis <cache at dowebs.com> typed:

> 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.

Not at all! In fact, you just made a big deposit in your Bank of Karma by
sharing your knowledge with this e-commerce grasshopper. A million thanks
for your clear and detailed explanations.

> 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.

When they're back in the office on Tuesday, this is the first question we'll
be asking. I suspect it is an MO/TO account, because they're not the type to
cut corners like that, and I believe they do a lot of telephone business.

> 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.

Actually, this is exactly the way it works right now. The order form is on a
secure page, and transactions are stored on the server in a
password-protected directory. The client accesses them through another SSL
page, and then clears the file (by uploading a blank file with FTP) after
saving the orders so that CC numbers are only stored on the server for a
very short time. I created an Applescript that automates the process, to
provide some insurance against screwups.

This new issue came up because they recently switched their whole business
to a new DB system (Flexware). Instead of storing the orders in a simple
text file, they'll now be in tab-delimited file that can be imported
directly into their new DB -- which should save them a significant amount of
time and work. The way the process was described to us by their DB
consultant (a Flexware employee), when a file is imported it somehow skips
the initial CC verification step, and goes directly to preparing the orders
for shipping. This kind of makes sense to me now, based on what you wrote
(although it sounds like the DB consultant was a little unclear himself on
the terminology):

> A MO/TO account typically has two stages, the amount of
> the sale is first "booked" meaning that the amount is removed from the
> card's open-to-buy limit and put on 30 day hold for your account. The
> second stage is where you "capture" the amount by actually charging the
> card. It is illegal to "capture" the transaction until after the product
> has been physically shipped.

So it seems what they're asking us to do *is* the "booking" step. And if I
understand your points correctly, the "right way" for us to do this is to
have the client open a second merchant account and use a service like
authorize.net or Cybercash to authorize the charge. Hmm. Significant
expense, and the online ordering system will have to be redesigned (again).

What I love about this: the original spec for the project was just to write
back-end code to put the orders into a Flexware import file. So I deliver
this code, and they say "Oh, and there's one other little thing we'd like
this to do..." :^|

charles johnson
lgf web design
http://littlegreenfootballs.com