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