[thelist] Credit card validation

[Keith Davis]

"Charles F. Johnson" wrote:
> 
> A client just requested that we come up with a way to verify a credit card,
> on submission of an order form. The way it was described to us, they don't
> need to actually charge the card for the order, just verify that the number
> is valid and it's not over the credit limit.

> any pointers...

Some of this may be inappropriate for this client, but once you've done
an e-commerce site you'll have new skills and this probably wont be your
last one.

You will need to have a merchant account. I doubt that any of the credit
card gateways provide validation for just anyone without a valid
merchant account. The gateway and the merchant account ISO are possibly
still going to charge your client, probably 35 to 50 cents per
validation. This is not like doing it through the card swipe in the
store as there are intermediaries involved.

Make sure the advice you are getting is applicable. All web transactions
must use a money-order/telephone-order type merchant account. It is
illegal to use a regular over-the-counter type of account for web
transactions. 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. I've not tried to get a simple validation
with a MO/TO since that is not part of the flow of a MO/TO transaction.
You'll have to try it. But it will probably set off a red flag at VISA
Merchant Services.

That said, be sure that the advice you are getting is not referring to a
"booking" on a MO/TO account. That stage is indeed free and does
validate the card and the limit, but it also reduces the card's balance
for 30 days or until you void the "booking". Over-the-counter types of
accounts can do a validation-only where the amount is not "booked". 
But, you cannot later "charge" the card with that kind of account for
that sale since that sale is tainted, it originated on the web. That's
what that red flag will be looking for. If your client plans to later
charge the customer, without the customer being physically present at
the time of the charge, your client will need to use a second, separate
MO/TO account and treat the charging as a totally different transaction.
Why do you need to know this? There's the likelihood of more billable
work for you if you do it the "right" way. And if you don't do it the
"right" way you could be liable, you are legally the "expert". See next
to last paragraph.

After reading the following you may want to reconsider doing the
"validation" in live-time. The alternative being to write the
transaction to your server, recall it later through a secure browser,
and process as a batch via credit card gateway software (ICVerify or
MacAuthorize/PCAuthorize) or through a "Virtual Terminal", and THEN
export as a batch to your Flexware database. (Check to make certain
ICVerify or MacAuthorize/PCAuthorize will do a simple validation, I've
never need to know)

As for getting a "live-time" connection with a credit card gateway, you
cannot do this directly across the web. The processors are not connected
to the web. Netscape developed the LivePayment protocol to connect
server to server with First Data's gateway. It failed and was abandoned.
Microsoft also abandoned work on a web-only gateway protocol. VISA/IBM
has pretty much abandoned their S.E.T protocol.  As a result, gateways
are still connected to via regular phone connections, not via tcp/ip.
You therefore must do one of the following for "live-transactions":

1) dial out from your server directly to the gateway via a land-line
modem while holding the web part of your "transaction" in limbo. RedHat
has this feature embedded in ver.7.  MacAuthorize/PCAuthorize has a
server hub version that can also do this.

2) have a merchant account with a bank that has a web server internally
networked with their gateway (B of A, Wells Fargo and some others offer
such accounts).

3) pay an extra transaction charge to someone who provides the service
described in 1. You connect via server-to-server or browser-to-server
with this third party, they do the gateway connection and return the
results. There are many companies that do this. Most of them make their
real money selling merchant accounts and use the connectivity as a
come-on so pay close attention to what you or your client signs up for
when dealing with them. Some of them were pimps and loan sharks in
earlier lives. Many of these third parties are resellers for
authorize.net. Do an "authorize.net reseller" search at google.com to
get a flood of links. Some of these offer the "Virtual Terminal"
mentioned above that lets you do a non-live-time single, or batch,
transaction authorization through a web page on their gateway server.

As for using your PHP script. If you are going the RedHat route there is
a PHP built for that and I believe it can be found through RedHat (I
don't use PHP so I'm not sure where to find it). 

If you are connecting via a bank or third party they will give you the
instructions on the data that you will need to pass on to them (usually
only the total and your order number). Usually you need to capture the
ordered items, quantities, tax, and shipping info on your server, then
redirect the browser to their server. They present the SSL payment page
which takes the cardholder's info, processes the transaction, and then
redirects to a success page on your server. Some of the third parties
require that the redirect goes to a perl script or java servlet that
they provide and you install on your server to guarantee the
authenticity of the success (CyberCash is an example). Either way, the
redirect has to not only tell the customer that the transaction was
successful, but also link up with the transaction data that you saved
and mark it as a success or deny. You may have trouble finding one of
these that will do a "validation-only" since that involves sending
different processing codes than the normal MO/TO codes.

Most important of all, try to talk with your client's merchant account
issuer (usually his bank). If your client doesn't want you talking to
his merchant account issuer (and that's understandable), get him to sign
a "hold harmless" statement that explicitly exempts you from the
responsibility to advise your client regarding banking and merchant
account regulations. That should be a standard part of every e-commerce
contract. But, consulting with the account issuer is strongly advised
because they can probably tell you how best to connect. And will surely
tell you whether it is even legal for you to do so or not based on the
terms of the merchant account. 

keith

P.S. Along the way you will see unusual long field names being used on
forms for things like cardholder's name and address. Copy and keep them
for future use in your own forms. They are global banking standard field
names and will be in use longer than HTML will. I understand that W3C
has adopted them as standard XML field names should someone figure out
how to do all this with XML.