Slashdot Mirror

How about TrustCommerce? They've got an API for most of the popular languages. I use the Python version.

http://www.trustcommerce.com/tclink.php

TrustCommerce is very developer-friendly. They don't provide a ready-made payment form for your website, but if you or your shopping cart can collect the data, they have a solid, simple gateway API for processing it. And with regard to the topic of the article, TrustCommerce claims that its redundant systems offer 100% availability through failover.

I've been using TrustCommerce for a small site for several months, and I'm now implementing a large site with them. I've had no problem with their payment gateway or with their "vault" interface for manually entering transactions and viewing reports.

Their documentation is thorough and they support multiple code interfaces to their API: PHP, Python, Java, EJB, Perl, Ruby, ColdFusion, C, and COM/.NET/OCX/ActiveX.

TrustCommerce has given me good customer service and very good developer support. In my first project, I was using a hosted server and one of TC's developers helped me talk to my hosting company about installing the TCLink module that communicates directly with the gateway. My host had a policy against installing custom modules on the webserver, so TrustCommerce had an alternative solution, sending transactions securely through HTTPS/POST and using Curl to read the results back, and that method has worked fine.

For my new project, I've built my own webserver so I can use the TCLink module without begging a hosting company for customization. My server uses Suse Linux Enterprise Server 9, and I found out the hard way that TrustCommerce built its Linux RPM module for TCLink-PHP on Red Hat. (On SLES, I should have installed and compiled the "UNIX" package instead of the "Linux/RPM" package. You probably won't have the same problem if you use Debian because debian-unstable includes TCLink modules for PHP, Perl, Python and Lisp.) I'm a Linux newbie, but TrustCommerce's developer support patiently talked me through creating the symlinks I needed to make the rpm module work on SLES.

TrustCommerce is very developer-friendly. They don't provide a ready-made payment form for your website, but if you or your shopping cart can collect the data, they have a solid, simple gateway API for processing it. And with regard to the topic of the article, TrustCommerce claims that its redundant systems offer 100% availability through failover.

I've been using TrustCommerce for a small site for several months, and I'm now implementing a large site with them. I've had no problem with their payment gateway or with their "vault" interface for manually entering transactions and viewing reports.

Their documentation is thorough and they support multiple code interfaces to their API: PHP, Python, Java, EJB, Perl, Ruby, ColdFusion, C, and COM/.NET/OCX/ActiveX.

TrustCommerce has given me good customer service and very good developer support. In my first project, I was using a hosted server and one of TC's developers helped me talk to my hosting company about installing the TCLink module that communicates directly with the gateway. My host had a policy against installing custom modules on the webserver, so TrustCommerce had an alternative solution, sending transactions securely through HTTPS/POST and using Curl to read the results back, and that method has worked fine.

For my new project, I've built my own webserver so I can use the TCLink module without begging a hosting company for customization. My server uses Suse Linux Enterprise Server 9, and I found out the hard way that TrustCommerce built its Linux RPM module for TCLink-PHP on Red Hat. (On SLES, I should have installed and compiled the "UNIX" package instead of the "Linux/RPM" package. You probably won't have the same problem if you use Debian because debian-unstable includes TCLink modules for PHP, Perl, Python and Lisp.) I'm a Linux newbie, but TrustCommerce's developer support patiently talked me through creating the symlinks I needed to make the rpm module work on SLES.

I'm rather shocked to see all the complaints about the Gimp here. The comments seem to be divided into two categories:

1. I've never used it, but from the screenshots it looks scary! It sucks!

2. I've used it, and it didn't work exactly like Photoshop. It sucks!

As a person who has used Photoshop (and a bevy of other paint programs, all the way back to the days of DPaint) extensively, I feel the Gimp is by far the best program available for creating (pixel-based) graphics, especially in the realm of web imagery.

I have used it to create from-scratch graphics for countless websites, including: this, this, this, and this. I have also used it to do many print items, such as this flyer. (Amazingly enough, CMYK is not really that necessary if you don't mind slight variations in the color on the final product. If you are doing serious print work, you should really be using a vector illustration program for everything but photo retouching anyhow.)

I think perhaps the Gimp's strength is how a non-artist (ie, me) can create pretty nice looking art with it - as I believe the links above will attest. It has a number of features not found in any other paint program, such as highly configurable tablet sensitivity.

Unfortunately, the hardest thing about using it for someone who has switched from Photoshop is that it looks _very_ similar to Photoshop, but yet it is really not very similar at all. Much like an expencied Windows user switching to KDE, they will find themselves fooled into expecting the interface to behave exactly the same way - and it doesn't. It's a different program, with a different interface.

But those who either have the patience to un-learn their Photoshop habits, or are not burdened by them to begin with, will find the Gimp to be one of the most powerful graphics tools available today. It is also quite likely one of the most impressive and mature applications available in the realm of free software - on par with Mozilla, OpenOffice, and Evolution. I'm not sure why it doesn't get the same respect that these packages do.

You mentioned that you needed to process credit cards. Check out my employer, TrustCommerce, which offers a completely open source credit card processing API for connecting to our payment gateway. It compiles on tons of platforms (including Linux), and we have versions for many programming languages: C, C++, PHP, Python, Ruby, Perl, ColdFusion, Lisp, etc. All code is GPL.

You mentioned that you needed to process credit cards. Check out my employer, TrustCommerce, which offers a completely open source credit card processing API for connecting to our payment gateway. It compiles on tons of platforms (including Linux), and we have versions for many programming languages: C, C++, PHP, Python, Ruby, Perl, ColdFusion, Lisp, etc. All code is GPL.

Don't store your own credit cards, stash them someplace secure. You don't keep your money in a sock under your matress do you? You put it in a bank. Some deal here.

http://www.trustcommerce.com/opensource.php

There are many areas where the apps are lacking, but photopaint is not one of them. Scroll down towards the bottom of this and look for the quote about Photoshop vs the Gimp from a professional artist:

http://people.trustcommerce.com/~adam/office2.html

Mandrake Linux Business Cases
Consulting Times
Open Source - ready for business
Open Source on the Business Desktop
Why Open Source Software / Free Software (OSS/FS)? Look at the Numbers!
A Hard Look at Linux's Claimed Strengths

I work for TrustCommerce, a credit card processing gateway that just happens to compete with Verisign, the gateway mentioned in this article. What I want to know is why the Verisign rep said nothing about the velocity controls that should have been in place on the account in question. Velocity controls work like this: If a merchant goes over a certain number of transactions per day or per card, no more transactions are let through. The whole point of these controls are to prevent exactly this sort of basic fraud from occurring in the first place.

My company began using it a few years ago as a replacement for a commercial JSP server that was a completely piece of crap. Compared to the commercial program it was okay, but it frequently (like once every couple of months) would lock up and require not only a complete restart, but in fact a "kill -9" of all java processes running as the Jakarta/Tomcat user.

Today we are using JDK 1.4 and Tomcat 3.x and are pretty happy. It doesn't lock up or do weird things anymore. Speed is okay; not blazing fast, but for our business, the compiling (or interpreting) of dynamic pages is not the slowdown. Database access is a hundred times as CPU intensive so speed of our dynamic content isn't really important. Our pages are fairly complex and usually compile in about 500ms.

All in all I vastly prefer coding web pages in PHP. Java is just plain clumsy for creating web content. But if you've got hundreds of thousands of lines of legacy code (like us), Tomcat will do you just fine.

Anti Aliasing isn't the end-all be-all of fonts. What matters is to have good fonts to begin with. If you go get the Microsoft ttf fonts and install them, you'll be much better off in programs that don't support anti-aliasing (easily) like Mozilla. Moz. is infinitely usable and looks just like Moz. Win32 if you use the same fonts.

I mention that because he complains about anti-aliasing, especially in Mozilla, both on the 10 things needing fixing page, and on the Top N Things That Have Been Solved page.

Microsoft core TTFs are available here: MS TTFs

Install guides and scripts are available several places: http://www-uxsup.csx.cam.ac.uk/~jw35/docs/ms-fonts .html, http://www.linux.org/docs/ldp/howto/mini/TT-Debian -7.html, http://linux.org.mt/article/ttfonts.

The best script to auto-install to RedHat that I've found is here, he has lots of other goodies to boot: http://www.linuxquebec.com/~nomis80/

It's easy to forget how far we've come, looking at the list of nitpicks that still exist today. But just take a look at a few of things that have been solved. Based on the past diligence of OSS developers, I expect to migrate all the items on the other page to this one over the next six months or so!

Created: July 12, 2002
Last Updated: July 12, 2002

The rapid pace of development of free/open source software has always stunned me. In just a few years, Linux and the free BSDs have become serious players in every major computing market, from embedded systems up to enterprise-class servers. Most impressive, however, is the strides they have made on the desktop. KDE and GNOME rival, and sometimes exceed, commercially available desktop environments who have been around for decades. (With apologies to the BSD developers, I am going to shorten "Linux and the free BSDs" to "Linux" for the rest of this essay.)

And there's nothing that gets FS/OSS moving like criticism. Three years ago journalists and industry pundits complained loudly that Linux has "no journaling filesystem!" Today it has a dozen. Everyone complained, "No good web browsers!" Today there are half a dozen. Everyone complained, "No good office suites!" Today there are three or four. I sense a trend here...

So, in that spirit, I am now going to complain loudly about every major nitpick I can think of. Understand this: I love free and Open Source software. The powerful tools it offers allows me to work at speeds I never could have dreamed of five years ago. And more importantly, it made computers fun again. If there were no FS/OSS and my choices were Windows, MacOS (not counting OS X, which wouldn't exist without FreeBSD anyway), or a proprietary UNIX...I probably would have lost interest in computers long ago. So please realize, the "complaining" I'm doing here is purely an act of love.

As a complement to this piece, I've added a Top N Things That Have Been Solved page.

The List

1. No 'best' browser.
2. 2. Prompting for a filesystem scan.
3. 3. Printing needs to be easier to configure.
4. 4. Make it easy for the user to find out how to do things.
5. 5. Cleaner redraws.
6. 6. Die stray processes, die!
7. 7. Easy way of sharing files.
8. 8. Sound support.
9. 9. No common editor which supports "soft wrapping."
10. 10. No easy way to configure X - especially change resolution on the fly.

1. No 'best' browser. There are lots of browser choices (that's good), but there is no one reasonable default choice that can be made available to users. Konqueror enjoys immense popularity because it's the default for KDE, the most popular desktop environment - ironically, the same reason that IE enjoys such success on Windows.

Konq is great - really, it's my favorite browser - but it has contained showstopping bugs in the last two major versions. 2.2.2 had a horrible bug which caused it to lockup about 1 time in 10 when selecting any text in an input box (including the URL bar). I set up RH7.2 boxes for numerous friends and coworkers, and trying to explain why the primary browser locked up so often was quite difficult. I thought 3.0 would save us, but alas - it has an even worse bug whereby forms submit incorrectly about 1 time in 5, causing most functionality-oriented sites (including the TrustCommerce merchant admin site) to be completely unusable. My other major complaint with Konq is its jerky page updates: clicking a link will cause a big white box to suddenly obscure part of the current page - compare to Mozilla which updates the display very cleanly. 3.0 was significantly better on this front, but it's still enough of a problem to hurt the user experience. Finally, it's still slow when you have a lot of browser windows open. The worst is when you middle-click a link to a large PNG image (say, the screenshots on the GNOME site). I minimize the window while the image is loading, but in the meantime my other browser windows become _very_ unresponsive; trying to scroll is jerky and difficult. Very unpleasant.

Mozilla-based browsers are the best. They render most pages correctly and enjoy the commercial support of being the basis for Netscape. However, Mozilla is not integrated with any desktop environment, making tasks such as printing, accessing the file open or save dialogs, and cut-n-paste unpleasant. Galeon is the best browser currently available, to my mind, but the lack of anti-aliased fonts keeps me going back to Konqueror. Opera is good, but it's commercial, and suffers badly from the default fonts being ugly. (You can fix it to look more like Konq if you spend some time fiddling with the config files.)

Solution? Browser developers need to focus on removing the remaining impediments to user-friendliness. Konq needs to be faster and smoother in its display, and stop shipping with major bugs that make it nearly unusable. Mozilla needs to get better desktop integration (such as being able to specify your mail client, and ditching that lame file dialog for the default GTK dialog) and anti-aliased fonts for rendering. Whichever browser is the first to come to completeness on these points should then be chosen as the default by distributions. It's a tight race, and one that will no doubt be won in the next couple of months. Hopefully it will be a tie - having several 'best' browsers would be awesome!

2. Prompting for a filesystem scan. Bad on the desktop, killer on the server. Who in the _world_ wants their bootup process interrupted by this busy work? The introduction of journaling filesystems has greatly helped this (it happens only 1 time in 20 on an unclean shutdown, rather than about 1 in 4), but it's still bad.

Here's what happens. A power cord gets kicked out of your desktop machine. The system boots, tries to scan the filesystem, can't recover the journal, and panics. You are prompted to enter the root password, and then you're expected to type some cryptic commands like "fsck /dev/rd/c0d0p2", possibly answer a bunch of cryptic questions like "Deleted inode 12345. Fix? <y>", and then reboot. Does anyone enjoy going through this process? Does anyone find themselves wanting to answer "no" to the question of whether to fix inode 12345? I doubt it. The system should just fix the filesystem, even if it means losing a few recently-written inodes, and get on with booting, without asking the user anything.

Think it's better server-side? No: it's much, much worse. Now when a machine hardlocks (say, due to hardware that is overheating due to heavy load - a common scenario if you're using standard PC hardware and your webserver gets slashdoted), and you call the colocation facility to ask them to reboot the box, the thing doesn't come back online. Now you've got to ask the person in the facility to wheel a monitor over and plug it in, give them your root password (aggh!), and tell them to type the aforementioned cryptic command. This SUCKS, bad. (Apparently it sucks so much my grammar is starting to suffer!)

To their credit, Mandrake's Aurora boot system asks the user if they want to go ahead and repair the filesystem anyway when this happens. It's only a single, easily-answerable question: quite reasonable for the desktop, but still pretty lame in the server scenario.

3. Printing needs to be easier to configure. Offer fewer choices (such as driver selection), and give easy access to print job control, as well as GUI-based diagnosis and correction of errors such as printer jams.

For years I struggled with /etc/printcap; I never could seem to get it to work quite right, especially for sharing printers on the network. I found it easier to write device drivers for the Linux kernel than to set up a stupid printer! (I have written a total of three device drivers for the kernel, but I have yet to construct a working printcap file.) Today things are better: GUI programs such as Red Hat's printconf-gui and Mandrakes PrinterDrake make it possible for mere mortals to set up a printer. But still they remain too difficult. For example, Red Hat does not install the printer on startup: the user needs to know to type "su" and then "printconf-gui" at the command prompt. Both have the problem of prompting you for which driver you would like to use for certain printer types. For example, I have a basic HP Deskjet at home. Mandrake gave me two choices for the driver, while Red Hat give me a whopping five! Asking the user questions they are likely to find irrelevant is bad UI design. The user doesn't care what driver they use, they just want to be able to print at the maximum speed and quality possible. If you want to hide this choice in an "advanced" tab somewhere, that's fine: but don't force them to make the choice!

Ideally printer install should work like this. You run the printer install program, and it gives you two choices: "Set up a printer attached to my computer", and "Set up a printer from the network." The first choice looks in /proc/sys/dev/parport/parport?/autoprobe and determines the type of printer that is connected and choses a driver for it. It displays the type of printer detected, then asks you one last question: "Do you want to share this printer with people on your local network?" After answering this question, it sets up the printer, and you're done.

4. Make it easy for the user to find out how to do things. Most Linux distributions come with a ton of applications, development tools, and support for all sorts of fancy devices. But none of this is very obvious when you boot into KDE or GNOME for the first time. The menu contains a few apps but they are scattered about and don't have names that reveal what they do. The vast majority of tools on the system aren't even in the menus. We need to make it easy for a new user to find out how to do stuff with their shiny new OS, without having to do a web search to find out.

This is, IMO, Linux's top strength on the desktop. Windows comes with an email client, a web browser, and Freecell. MacOS has the same, but iTunes in place of Freecell. You really can't do much with a default install of either OS. On the other hand, Linux comes with a wealth of applications and toys that could keep the user busy for years without ever downloading or purchasing any additional software. Let's make this obvious! Here's how.

There should be an "I want to..." dialog. It should be a large icon on the desktop which is very obvious to any user. Clicking it will open the dialog. At the top is written the text, "I want to..." and below are a long list of things that you can do with your system. These might need to be grouped by expandable categories, as the list could get very long. Here are a few things I suggest:

• Browse the web
• Read email
• Chat (IRC / AOL / Yahoo / Jabber / ...)
• Burn a CD
• Install a printer
• Set up a modem
• Set up a DSL or cable modem
• Make my computer server web pages
• Share my files with others on my local network (NFS)
• Access someone else's shared files (NFS)
• Download pictures from my digital camera (GPhoto)
• Paint a picture or touch up a photograph (Gimp)

ELX is the one distro I have seen that tries something like this, but it suffers from the same problem as the KDE & GNOME menus: it gives you a list of programs you can run, instead of tasks that you can do. People use computers to do things, not to run programs.

5. Cleaner redraws. This has long been a complaint of mine in almost every OS and desktop environment: slow or flickery window updates. I have only ever seen one OS do it right, and that's Mac OS X. This isn't a speed issue, really; it's a how-you-update-the-screen issue. Mac OS X pops a window onto the screen all at once. Presumably it does any drawing that it needs to do on a back buffer and then blits it to the screen when it's all done, just like a video game. Even on a slower system, it still appears very "clean" - the window just takes a little while to appear. But you don't see any ugly drawing artifacts in the meantime.

The latest version of Windows is not bad; mostly I think this is due to the fast speed of modern hardware coupled with the minimal eye-candy that the OS offers. Things like the file explorer still don't update all at once, but it's a minor point; they've mostly got it right.

KDE, on the other hand, continues to flicker and pop. Here's a key example: click on the "home" icon in your menu bar. The window pops onscreen, but many of the drawing elements (the files themselves, but many widgets) are temporarily drawn as large white or grey boxes. A split second later the full images appear. Even on a high-end system it looks a little funny; on a slow system it looks terrible.

This is not a functionality issue, so in many ways its not that important. But it is a "user experience" issue; people coming from Mac OS X or even Windows will find their experience a little less pleasant, and that makes them less likely to come back.

This slashdot comment offers some insight into some of the reasons behind X's flickering problems.

6. Die stray processes, die! Windows has this same problem and all you can do is reboot. In Linux you can exit X, drop to a console, and start running "killall kdeinit", "killall mozilla", etc, but this is lame and for non-technical users it boils down to the same thing. Possible solution: when in X, WM should keep track of processes and the windows they are attached to. When an app has no windows open (or the main window is not open), the WM should attempt to kill them (first normally, then with -9). This functionality could be configured for debugging whereby instead of killing them, it attaches gdb to the process so that developers could figure out why there are stray processes.

7. Easy way of sharing files. Ideally a right-click on a directory and chose "share this directory". Be able to pull up a list of all folders you are sharing and change permissions or remove the sharing.

NFS is quite easy to set up - if you know exactly what you're doing. If you don't know the magic keywords to add to /etc/exports (server) and /etc/fstab (client), you're pretty much screwed. I don't think it would be terribly hard to add this functionality to, say, the Konqueror file browser. (It may be necessary to set up a small daemon that runs with root privileges in order to allow users to export the data...)

8. Sound support. OSS was great a few years ago and continues to offer support for modern cards (including professional quality ones such as the Midiman Delta 1010, which is what I have) but it is commercial and it is showing its age. ALSA is a superior solution and has been rolled into the dev kernel. Once it makes its way into the stable kernel and distros start using it uniformly (Mandrake, SuSE, and a few others have offered it for some time now) along with a good configuration tool, audio on Linux will rock.

9. No common editor which supports "soft wrapping." By which I mean displaying things wordwrapped, even when it's one long line. This means you can go back and edit the line and the rest of the paragraph will reformat itself automatically. Evolution's message editor does this, but that doesn't help me for composing text files (like this one!). Others I've tried - Kate, GEdit, and even vi - only support "hard wrapping", where it inserts a newline when you get to the end of the line. Then when you insert more words into the paragraph later, the formatting gets all screwy.

10. No easy way to configure X - especially change resolution on the fly.

This varies by distribution, but I the resolution issue is a common one. (The only distro I have seen that does it right was Corel 1.0. You could change your resolution from the KDE control panel. However, I believe this is because they were using the commercial X server Metro-X.) It boggles my mind that, after all these years, the best way to configure X is to run Xconfigurator from the console! This is, I believe, the longest running embarrassment of the free software desktop.

TrustCommerce has a great system called BillingID's where you can submit all your credit card info for storage on our secure Linux servers. You are given a handle that you can use bill the customer at any time through our cool GPL'ed client API. Retrieval of the CC info is impossible so even if your server is compromised the hacker can't get your credit card information. This lets you bill customers at your leisure but lets you offload all the extra security responsibility onto us. Security is, after all, what we do. </shameless plug>

Mandrake's site features an informative Business Cases page, which includes one article in particular that might provide some insight.

Speaking as someone who works in the credit card processing industry, this isn't too shocking. One merchant accepting payments on behalf of another is known as "factoring" and is generally a no-no, both legally and in terms of Visa/MC regulations. PayPal is a special case; how they negotiated their current deal, I'm not sure. Really good lawyers, I guess.

Here's the reason why: merchant account providers are taking on risk on behalf ot the merchant. Because credit cards provide complete safety for the consumer (via chargebacks), if a merchant runs a bunch of charges one day, cashes out the bank account, and skips town, it's the card acquirer (or possibly the issuer) that are left with the responsibility to pay off the fraudulent charges to the consumer. By using a "proxy" merchant, ie factoring, they distance themselves from the consumer and make it that much easier to get away with fraud at this level.

That's excellent, both for Red Hat's continued success, and the greater acceptance of Open Source / Free Software. As geeks we like to think that the best technology will prevail, but in truth it's all about your marketing and salesmanship. I'd like to think that TrustCommerce is experience so much success due to the cool technologies that we have developed, but I know that it's really our sales staff that brings in the green. (In fact, we have a ratio around 90% of sales to other staff as well...)

Good for Red Hat. I hope that they can pull through this recession intact; and I think they will, because they seem to understand the basic premises of business.

Here's the link:

http://people.trustcommerce.com/~adam/office.html

I think what you are looking for is a payment processor which supports recurring billing as well as open source client APIs?
</plug>

I think what you are looking for is a payment processor which supports recurring billing as well as open source client APIs?
</plug>

I think what you are looking for is a payment processor which supports recurring billing as well as open source client APIs?
</plug>

Proper billing information security involves two steps: first, the ordinary system security that we all know about - protecting your system from breakins, physical security of the machines, etc. This is a big job in and of itself. On top of that, you then need to worry about encryption of the account information, so that if there is a break-in (either virtual or physical), you are not in a position to be blackmailed by the crackers.

More details can be found on my company's page about security, here. Allow me to boast for a moment and state that we are one of the only payment processors that uses a fully encrypted data storage system: no unencypted card numbers are ever writen to disk. Cool, eh?

As long as I'm evangelizing our service, I will also mention our Billing ID system. This is probably exactly the sort of thing you should be using for this application: not only does it do automated recurring billing, but it actually stores all the info in an encypted database so that you don't have to be responsible for holding that information locally. You can run transactions on the account either by using the six digit Billing ID returned by the original store transaction, or by scheduling one-time or repeated transactions through either the web interface or the TCLink API. It's a pretty nifty system, you might want to check it out for your app.

Proper billing information security involves two steps: first, the ordinary system security that we all know about - protecting your system from breakins, physical security of the machines, etc. This is a big job in and of itself. On top of that, you then need to worry about encryption of the account information, so that if there is a break-in (either virtual or physical), you are not in a position to be blackmailed by the crackers.

More details can be found on my company's page about security, here. Allow me to boast for a moment and state that we are one of the only payment processors that uses a fully encrypted data storage system: no unencypted card numbers are ever writen to disk. Cool, eh?

As long as I'm evangelizing our service, I will also mention our Billing ID system. This is probably exactly the sort of thing you should be using for this application: not only does it do automated recurring billing, but it actually stores all the info in an encypted database so that you don't have to be responsible for holding that information locally. You can run transactions on the account either by using the six digit Billing ID returned by the original store transaction, or by scheduling one-time or repeated transactions through either the web interface or the TCLink API. It's a pretty nifty system, you might want to check it out for your app.

Yes, security is an important issue I didn't even touch on, but which should be a top priority for anyone doing commerce over the open Internet.

Personally, I don't trust large companies like Visa/MC to handle 100% of the security for a task like this. But then, as a former sysadmin and currently an engineer for a payment processor, I'm probably about as paranoid as they come...

• Ease of use. Forcing people to sign up for a paypal account before they purchase from you is a sure way to loose sales.
• Professionalism. When someone wants to sell me something via a PayPal payment, I get cold feet. It's not professional, and it makes me wonder about the trustworthiness of the business, especially if it's an item that costs more than $20 or so.
• PayPal is vastly more expensive. Last time I checked, they skim something like 5% off your credit card transactions. A good e-commerce merchant account from a real bank should only charge you on the order of 2.5%.
• Integration. I suppose this goes with the first point, but as a web designer it's an important one for me...I want to build payment handling into my PHP-generated web page, not send the user to an external site.

We use PostgreSQL on Linux here at TrustCommerce. "Mission critical" might be an overstatement (it's credit card processing, which is important but not exactly life-or-death).

TrustCommerce offers a drop in .pm module as well for people writing perl front ends to their web sites. The Raven SSL package allows apache to serve https, not make ssl connections from a perl program. The trouble with SSL in perl is not serving https+mod_perl, its in writing those easy drop in .pm modules for connecting to the eCommerce gateways. Lucky for all you eCommerce site developers, we gateway programmers get to worry about that, not you.

I don't think Adam's comment was meant to detract from the power of something like Mason and mod_perl for developing web site front ends. It was just that of all the API's we have open source libraries for (C, Perl, J2SE, J2EE, Python, PHP and ColdFusion), the Perl module was by far the hardest to develop as the existing tools lack some important features.

Having built numerous e-commerce sites and even worked on a commercial shopping cart written entirely in Perl, I can't say that I think it's the best choice. It's great if the job is small; it's quick to code, is installed on almost all hosting providers, and so forth. But for large projects the code becomes very difficult to manage, mainly because getting people to write clean Perl code is difficult.

There's a second downside: lack of good SSL networking. SSL is critical for credit card processing. I ported the GPL version of TCLink for Perl, and we ran into a lot of problems due to lack of a standard SSL library. For the first version of the client we ended up distributing a patched version of Net::SSLeay which added all of the certificate authentication functions we needed (and are missing from the standard install of Net::SSLeay). Later this became such a headache for the various platforms we were trying to support that we just coded a .xs version of the Perl client which wrapped around our C library. This has proven to be much easier to maintain.

Long story short: sure, Perl's great. Is it the best choice for e-commerce? I'm not so sure.

It depends heavily upon the type of development you're doing. Quite simply: if you're creating an end-user application such as a word processor or a game, an IDE like KDevelop is definitely the way to go. The app itself is highly visual, so creating it with visual tools makes sense. More importantly, with most apps, there's just a single program that you're writing and debugging, which the IDE can handle quite neatly.

Server tasks, on the other hand, are an entirely different story. Here you have something that is probably not terribly visual; most of the code runs in a place that the user will never see or have access to. You've got many little helper scripts, processes, client/server applications, processes communicating across many different machines, processes running automatically in the middle of the night - managing all of this with an IDE is probably impossible.

I do both types of programming at my place of employment. The core of our business is a payment gateway, which is hugely complex, and involves dozens of servers spread out across the United States communicating with each other, as well as internally, with a hundred and one small programs passing data off to one another. We do all our work on this part of our business with ssh, bash, vi, Perl, SQL, and occasionally some C.

On the other hand, I've worked on a few end-user applications (point of sale apps, install programs, reporting frontends) and KDevelop is great for them. Designing your widget layout in QDesigner is a breeze, and then integrating that back into your C++ code in KDevelop is drop-down simple. The embedded debugger is wonderful, as well.

Moral of the story: Choose the best tool for the job.

The example you mentioned in parathesis sounds more like a backend thing. Backends, especially in the banking industry, tend to be so old that they predate both open source and Microsoft in the server domain. Those systems tend to be running AIX or SCO.

You're welcome to use my company, TrustCommerce, as an example. We use open source software for pretty much everything, both web stuff and backend. Our processor runs millions of transactions a month and hasn't had a single moment of downtime in over a year. All of our web and frontend stuff is using open source software as well, but there are plenty of good examples of that from companies that will be far better known than us.

The example you mentioned in parathesis sounds more like a backend thing. Backends, especially in the banking industry, tend to be so old that they predate both open source and Microsoft in the server domain. Those systems tend to be running AIX or SCO.

You're welcome to use my company, TrustCommerce, as an example. We use open source software for pretty much everything, both web stuff and backend. Our processor runs millions of transactions a month and hasn't had a single moment of downtime in over a year. All of our web and frontend stuff is using open source software as well, but there are plenty of good examples of that from companies that will be far better known than us.

*cough*

*cough*

(I'd say that your gateway being secure is as important, if not more so, that your storefront itself.)

*cough*

*cough*

(I'd say that your gateway being secure is as important, if not more so, that your storefront itself.)

http://www.trustcommerce.com/security.html

Funny, my company has been using Linux (and other free software) for mission-critical application in the enterprise for years. That includes all the stuff they mentioned - database, financial, CRM, and more. Linux does have a journaling filesystem as of 2.4.1, and it's actually had them for quite a while if you don't mind doing some kernel patching.

In fact, I would say that the only other platform that is as capable (and probably more so) that Linux in this regard is Solaris on Sparc hardware. Solaris has its own set of problems (mostly that it feels like an "old" UNIX to me, making it hard to develop on), but certainly is quite capable.

I guess these journalists (and the people they interview) just insist on handing hundreds of thousands or even millions of dollars over to Sun and Oracle. That's fine, since the products they sell are good. But for young companies with a limited cashflow (as we were just a few short years ago), that's not an option.

In that case, Linux (or one of the free *BSDs) is your only choice.

Excellent advice. The most important thing, though, is just "ordinary" security - get a well-administered hosting service, or if you admin your own box, use all the good security practices you read about on slashdot, Security Focus, and so forth.

I would also recommend a payment gateway that makes security a top priority. Obviously the merchants weren't at fault in the creditcards.com case; they could have all the security they wanted, and the database would still have been stolen from their payment processor.

If I may be so bold, I can recommend a payment processor who makes security a top priority...

I happen to know one of the programmers at TrustCommerce. Despite the somewhat boring-looking public website, they have a kick-ass payment gateway. They have geographically seperated servers with automatic fail-over so they have 100% uptime. Their API is very clean (unlike CyberCash) and they offer clients for perl, java, C, and most of the Windows gobblygook (COM objects, Active X, etc). I've also heard their support is exceptional...a 24hr hotline and well-written documentation.

Of course, *I* think the best part is that they run exclusively (well, not counting their own in-house code) on free software. All their servers run Red Hat, and they use Apache for both of their websites and (I believe) Postgres as their database.

You can probably drop a line to customerservice@trustcommerce.com if you want a quote.

(Usual disclaimer is attached: I'm not a customer, I've just seen how they do business and am impressed. More importantly, they run on the kind of powerhouse servers that geeks like me have dreams about...)

I happen to know one of the programmers at TrustCommerce. Despite the somewhat boring-looking public website, they have a kick-ass payment gateway. They have geographically seperated servers with automatic fail-over so they have 100% uptime. Their API is very clean (unlike CyberCash) and they offer clients for perl, java, C, and most of the Windows gobblygook (COM objects, Active X, etc). I've also heard their support is exceptional...a 24hr hotline and well-written documentation.

Of course, *I* think the best part is that they run exclusively (well, not counting their own in-house code) on free software. All their servers run Red Hat, and they use Apache for both of their websites and (I believe) Postgres as their database.

You can probably drop a line to customerservice@trustcommerce.com if you want a quote.

(Usual disclaimer is attached: I'm not a customer, I've just seen how they do business and am impressed. More importantly, they run on the kind of powerhouse servers that geeks like me have dreams about...)