Slashdot Mirror
Credit Card Processing?
Kevin Miller asks: "I am setting up my first Linux based e-commerce site and need to do real-time credit card processing to fulfill software purchases. Are there any handy informational nuggets for handling credit card transactions? I am familiar with C++ and Perl but can learn with the best of tree swingers. "
Basically you can't do this yourself (just you and the bank) as you need to interface to their TP systems, but there are a number of intermediary companies which provide the service. They have secure servers on the internet which have backend access direct into the banks' TP systems.
What you need on your systems ranges from SSL and a few hundred Kb of interface code (which they provide) to just hyperlinks; in the latter case they will host the "enter payment details" page for you.
You will also need a normal merchant account, of the same type you would use if taking cards over the phone. The intermediaries all offer sign-up services for this.
Check out VeriSign, CyberCash and their friends on-line, or do a web search for "credit card processing services" or something similar. They will also handle on-line cheque verfication and debit cards.
There are alos "digital cash" type services but these are all proprietary (requires customers to have an account with that vendor) but have the advantage that they handle small payments (sub-$5) much more economically. For larger payments the credit card mechanism is the way to go.
With credit card processing there is a bank network that you need to connect to somehow. The most traditional method is a modem built into a credit card terminal (what you see next to the cash register in brick-and-mortar stores).
Obviously, actually typing in credit card numbers manually is way too much work for an online store, but you still have to connect to that network somehow to do the processing.
Method #1: A modem hooked up to the computer. This is that CCVS and OpenCCVS like to do. (You could also do this with a leased line, but you'd need to be processing a *lot* of transactions to justify a leased line.)
Method #2: Connect over the internet to somebody else that does the connection to the "clearing house" for you. This is what CyberCash does. (CyberCash also has their own "cash" that customers can use, which is much better for small amounts of cash per purchase.)
I've dealt with CyberCash to some degree or another at two different jobs. Once you've got it set up, it's okay, as long as you don't have large volumes to work with. Cybercash has two basic problems. First off, it does everything over the internet, so it is at most as reliable as the internet. Secondly, it uses HTTP over TCP to perform the transactions. What this all means is that any kind of problems that occur will tend to leave you unsure whether or not the transaction has actually gone through or not. With older versions there was a database on your end that kept track of transactions that could get out of sync (with the fixes involving direct modification of the database) with their version of things. Newer versions of their protocol have "fixed" this problem by moving the database to their end. So if you deal with maybe one charge an hour (or 10 an hour, whatever), CyberCash will generally seem okay. When you have to deal with batches of about a thousand charges once a month, the problems start to become intolerable.
My suggestion: investigate the various options that involve your computer dialing the clearing house itself. Make *certain* that the software is capable of using a queue in an intelligent fashion (ie, if it has two charges waiting, dialing once to clear both), make sure the software has *some* way to handle more than one modem (if it comes to that) and try hard to find a bank that you can use ISDN with. (Since ISDN connects almost instantly)
(Note: I think Cybercash does have one competitor, but I don't think they support Linux yet and I suspect they'll have the same basic unreliability of the internet problems that Cybercash does)
It was pretty easy.
They have interfaces in c and perl ammount many other langs.
I work for a financial services company offering secured credit cards. The internals of credit card processing is more involving than you first think. Banks actually don't have much to do with it at all. All credit card transactions are made through a Credit Card Processing company rather than a bank. The banks are just a card issuer.
:)
There are 2 types of credit card transactions...
1) those that are swiped (physically holding the card)
2) those that are not (internet, mail order, etc)
You need to arrange an account with an Online card processor who will offer you particular rates. Every business has a particular 'risk factor' for the processor to consider. This involved the type of business, physically where it is trading, the typical client of such a business, history of such businesses, etc for them to establish a rate.
The rates commonly will have a set transaction fee, a percentage processing fee, and a percentage held for some time (30-180 days) before remittance. Online transactions are a high risk factor so rates are generally higher than rates for a normal store-front trader. Blame fraud and the history of Internet business dissapearing.
When you have decided on a merchant, they will provide some basic variables to pass to their scripts for processing. What you need to look for is a company who can do exactly what you want them to do. ie, if you want to only process the order on your side *after* payment has been accepted, then make sure confirmation is able to be sent back to your scripts.
If you have other info that you need to pass through to process an order on your end (besides payment confirmation), you need to find a company who will pass all variables back to your scripts as well as payment confirmation. Some companies will have scripts that debit a card, then require a Continue button or something for the user to press before other info is passed back to you.
Basically, find out *exactly* how their scripts work and if you need something different, see if they can modify it for you or provide other options.
There are scripts available at http://www.cgi-resources.com/Pro grams_and_Scripts/ for 'shopping carts' etc if you need them for C/C++ and Perl and others
Without having a Merchant Account, your company name may not appear on your clients' statements either. Some companies can use your Merchant Account if you have one, and some others will have your company name appear on statements. With others, you should make sure people are made well aware of what *will* appear so you minimize any chargebacks.
Also, American and some Canadian processing companies use Address Verification System (AVS) for North American cardholders. This reduces the chance of fraud. Offshore processing companies cannot use this.
Thats about all I can think of atm but you can Email me if you need any other info
Just make sure you get rates froim as many processors as you can and examine their terms, the way their scripts work, and how often they remit monies. Some even want a minimum of say $10k (or whatever) before they remit on a normal basis.
Hope iv been of help
http://www.exxcomm.com
Do your best, hope for the best, suspect the worst.
I work for a Credit Card processor, and I've worked with DOS software called ICVerify. It has a nifty little feature where you can drop a file with the necessary Cardholder info (eg. Card #, name, exp date, address verification, etc) into a directory (from say a Linux box) with like a .snd extension, it'll process the info, and replace that file with a .dun (I don't remeber the specifics :)). You can then read that file in, and let the customer know if it's been accepted or not. The ICVerify machine that reads these files can be a 95 machine (eg samba), and has a modem, so it can dial to Banctec (now uppsolutions), Paymentech, or whoever your frontend is. You do have to have be a Merchant with a Card Processor who will accept internet transactions. Any more questions? rick@usb(dot)com
Of course it depends on the volume you expect, and the type of sale you're making, but having the orders looked at by a human being BEFORE you send them on to whatever process you decide on can save you tons of trouble. People typing long strings of numbers into a web form are apt to make mistakes, to say nothing of the multitude of malicious idiots out there who may phuck with yer system for the hell of it.
CCVS is the moral equivalent of a Veriphone terminal (or whatever those little bastards are called), it's actually quite good about it's queue and deals with things like lightning blasted modems gracefully. HKS will bug the hell out of you trying to get you to upgrade to the latest minor revision at the full price again, for no real enhancement that I can see.
OpenCCVS I think is pretty much just the transmitter; it doesn't have any sort of queue system, etc. That's good if you want to do that yourself anyway, and there's a whole lot to be said for being able to see the source regardless of the drawbacks.
ICverify and having someone else take orders for you are both options I considered for less than 10 seconds when I set up my system. I don't want to be relying on others to tell me if an order has been accepted or not (I don't really trust the credit card companies, much less a third order middleman), and I don't want to have to rely on DOS for anything.
Finally, and I cannot stress this point strongly enough, make sure your system is secure. If it has card numbers passing through it at all it will be a high value target. My system is low volume (in terms of orders, amounts, and traffic) and it's regularly poked at for the common holes. Less often it sees really strange stuff. TRW and the rest will be along to check your site out not long after it goes up, they're not anything like a real audit but I'm betting bad things will happen to your merchant account if they find a hole.
Posted anon 'cuz my boss beleives in security through absurdity and would have kittens if he found out I'd discussed our order processing system, however vaugely, on a public forum. (May the orifices of his women become clogged with brillo pads.)
Oh, one other thing: Address Verification sucks asteriods through small staws. Fraudulent card users seem to have less trouble getting or remembering their billing address than real customers do; "we only ship to the billing address" means (for me as a customer at least) "we can't do business with you."