Fog Creek Software
Discussion Board

handling credit card transactions in a webapp


I asked this a while back, but it was buried at the end of a thread.  I'm proposing a project with a small e-commerce app and looking for some advice.

Anyone have experience with setting up a web system to handle credit card transactions?  How hard is this?  In particular, do you need to be certified as credit-card-ready, and do you need to hook up with a third party to handle the actual authorization?

I notice that Fog Creek shop system (which I know is home built) appears to handle everything itself rather than send the user to a third party  site.  That's pretty rare for a small firm-- what's the trick?

Thanks, WILL

Wednesday, February 12, 2003

Maybe they (Fog Creek) simply store the Credit Card number until they process the transaction by hand. /shrug

Wednesday, February 12, 2003

Note: PayPal employee

It's not that rare for even small merchants to collect CC information and interface with a credit card processor. However, the responsibility of doing so is not trivial. It's generally easier and safer to use a pre-built system such as or many of the numerous free, low cost and not so low cost commerce packages.

And, depending on your situation, PayPal may be a good option. PayPal's much simpler since you would not be capturing the CC information.

Wednesday, February 12, 2003

You normally try and get hooked up with a company that will provide you with an Internet Merchant Account.  They will provide the gateway that will allow you to have seamless integration into your site.  You could check your local bank but I don't recommend it.

Check out

There are also some 3rd party credit card payment processors.  I have been using lately for one of my clients.  I may soon switch them over to using ECHO.

Jonathan A.
Wednesday, February 12, 2003

Assuming you have an api that will do the credit validation*
you just have to try to ensure that numbers are never stored in the db in if feel that your database can be compromised. Most sites that dare to claim they are secure will do this. If the credit validation service is down (the api will tell you so).. you might have to hold on to the number, how you do this securely I don't know. But one thing you can do is encrypt the number using asymmetric encryption (meaning the decoding key is not lying around on the web server or db) and batch it to a log file. And then maybe try to do them all at once manually when the credit validation service is back up.

So in the end, you should be able to: 1) Let your customer know their card cannot be accepted, so try another card 2) The card has been accepted.. but by company policy you might decide against shipping to an address not listed in the authorized addresses provided to you buy the API 3) yes, everything's kosher, we'll send the package out or lastly 4).. the credit card service is down, please expect a slight delay.

All the while ensuring you only have tracking information and no credit card information on your web server.

* Credit validation: It's a query to a credit validator service asking, I got this guys name, this guy's CC number, and expiration date, is he able to pay $X on a purchase?

The reply from the credit validator service is: 1) Yes, here's a tracking number, please delete the CC number from your hard drive and use the tracking number we give you 2) No, sorry 3) Busy, error, please hold on to number and try again.

Paypal is starting to look very tasty eh? :-D

Li-fan Chen
Wednesday, February 12, 2003

This is fairly ancient stuff, but this is how people used to do it:

Li-fan Chen
Wednesday, February 12, 2003

I used Paypal as my payment handler until I saw how many people are scared off as Paypal makes them join as members before they can pay you.

According to my site's stats 90% of purchases cancel when they see they Paypal sign up screen.

Matthew Lock
Wednesday, February 12, 2003

Not enough coffee yet, I meant

"According to my site's stats 90% of purchasers cancel when they see the Paypal "sign up" screen. "

Matthew Lock
Wednesday, February 12, 2003

It's not that difficult. A while ago I have created an e-commerce system from scratch; used CyberCash for all the CC transactions. All the APIs are documented, so it's not difficult at all.

Of course, you have to be very careful if you want to store CC numbers in your database...

Wednesday, February 12, 2003

Don't forget, kids - a 2.5% chargeback rate and your credit card processor says "So long!".

Even if you can process cards online, the fraud management angle is enormous.  Some months back somebody asked Joel how this was going after he dumped Digital River and went in-house, and he wasn't talking.  The value in outfits like Digital River and their gang is the fraud screening - they are laying their ass on the line for every transaction.

If you think the script kiddies don't want to try and scam developer's tools like Joel's stuff or ours, you are dreaming.

Maybe The Boss Hisself will chime in here.

Mitch & Murray (from downtown)
Wednesday, February 12, 2003

If you can do a shopping cart, you can do this.

I used, and it was extremly easy (I'm cheating, because they're giving the ASP page, and I just changed a few var names).

Wednesday, February 12, 2003

I personally want to focus on my business products and not have to worry to much about building and maintaining the ecommerce subsystem.  Since we develop for the Pocket PC, I've been looking at to take care of all the transactions.  It takes a bit off your bottom line, but the piece of mind can be priceless.

Thursday, February 13, 2003

It depends on where you are located as to what precise options are available to you, as well as the industry for which you wish to set up the credit card processing.

In general, there are two main ways to accepting (and validating) credit cards online:

Method 1: Via an API provided by your merchant account provider (or, more normally, one of their affiliates).  You receive instructions on the format that you must provide the data in (either the variables to pass, or sometimes a file format), and either a port to connect to (and they specify how to access etc etc), or (more normally) a black box program that you call when you wish to process the transaction (or pre-authorize it). 

This method allows you to have good control over the entire process, and can make the purchase "seamless" - but for some reason we've found the providers tend to have less data validation (eg - Here in Canada, Moneris doesn't check the credit card name against the credit card address).  It also requires more programming work generally because you have to handle the error messages etc. You can also choose whether to keep the credit card numbers or not at this point, since you are collecting them - but most banks (here in Canada at least) have fairly strict guidelines about the machines collecting and storing credit card numbers (eg must be a separate controlled access server room, numbers should be stored in a physically separate machine that is not directly connected to the Internet etc)

Method 2: Via a third party credit card processing company (eg InternetSecure).  In this case, you never collect the credit card numbers, so it becomes much less of a headache.  Instead, you send your customer off to the third party, usually to a special link and pass their purchase information with them via the query string.  The third party processes the transaction and sends them back to a page you define.  The data validation on these sites tends to be better (it's their necks too or something), and it is much easier and less hassle to set up.  However, you have much less control over the process, and you often end up forcing the user to either provide the same info twice (if you want to have the CC name, for example), or losing the info.  There tends to be many more screens as well, which you have extremely limited control over (usually just a logo).

In both cases, the process of setting up the business side of the account (getting existing merchant accounts "Internet ready", or applying for the merchant account) is much more painful than the technical side.  Since merchants selling products over the Internet rarely have the opportunity to get a signature from the customer, the transaction as a whole is considered higher risk (and thus more expensive).  Also, the nature of the goods provided makes a huge difference.  If you are providing services, or something "time delayed" (eg anything to do with travel) - you are much more likely to have chargebacks since you can't prove delivery of goods (this is also why it is "less risky" to sell software on CDs and with manuals than simply an electronic version - according to the banks anyway).

This means that your merchant account provider is more likely to require a high deposit (to cope with chargebacks) either on a rolling basis, or up front.  Here's an example: we've had the opportunity to set up reservation sites for very small airlines (less than 50 seats), who (like all airlines) sell tickets in advance.  These tickets have certain conditions (eg non-refundable).  However, because the customers of the airline can call their credit card provider and say "we didn't get the service - so please give me back my money".  This is in fact true, even if the customer missed the flight. Thus, in practice the conditions are unenforceable unless the airline gets a signature.  As a result, all of their sales are considered "high risk", and they have to pay a ~$500,000 deposit just to get Internet ready.

Thursday, February 13, 2003

Holy Beach balls,

Phibian you are the bomb!

-- David

Li-fan Chen
Thursday, February 13, 2003

check out

Wayne Bloss
Thursday, February 13, 2003

Provided you have chosen to use an api to access a credit validation bureau, it's advisable that the credit card information never quite make it to your general web space, if you can partition financial related processing to a separate slightly more secure web server that'd be the very best practice. Ofcourse it will probably be a part of the same doman and merely get's financial web visits redirected to it. You might for example virtually map all requests to /store/ to the second more secure server. Or once the transaction is completed your session will redirect you back to the regular programming. You can keep most of the non-confidential information about the business transaction in the general database ofcourse--but if you can move that to the second server all the better. There are also best practices you can do like asking a security auditor to investigate whether you have properly harden your web store.

Li-fan Chen
Thursday, February 13, 2003

Will, a fine book on the topic to check out maybe "Web Security, Privacy & Commerce, 2nd Edition" by Simon Garfinkel. I liked the first edition and the second edition seems to have many new chapters for today's world. (

Li-fan Chen
Thursday, February 13, 2003

Have to recommend They're good, cheaper than (shudder) PayPal if you have enough transactions, and have a good open source API that makes it easy and fast to validate and clear credit card transactions with them securely.

I was predisposed to like them because they run on Linux, use postgreSQL, and  have a nice perl module on CPAN for their API; but they've also been easy to contact and willing to answer lots of suspicious questions

Norman Yamada
Wednesday, March 5, 2003

dear sir

please help me $25000.00 JUST I AM VERY PROBLEM IN MY LITTLE LIFE i am seck and my life positive virues
please help me
my e-mail

shakir khan
Tuesday, March 16, 2004

*  Recent Topics

*  Fog Creek Home