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

Yeah, lots

[RallyDriver]

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.

Do you want to connect to the bank yourself?

[Falsch Freiheit]

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 [hks.net] and OpenCCVS [freshmeat.net] 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)

I Set up CCVS

[pwb]

It was pretty easy.
They have interfaces in c and perl ammount many other langs.

Re:Do you want to connect to the bank yourself?

[RedDirt]

A competitor of CyberCash is Authorize.net. My company has set up several e-commerce sites with authorize.net through a company called Electronic Exchange Systems (www.safesolutions.com [safesolutions.com]) and they're able to get you a pretty decent deal on a merchant account and also on the monthly access charges to authorize.net. It's significantly less expensive than CyberCash.

It's pretty easy, but...

[FIGJAM]

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/ [cgi-resources.com] 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 [exxcomm.com]