Many of us who get paid to Perl have at least dabbled with e-commerce. If you have a specific or even general question why not ask it here? You don't have enough time to set up a new portal and write a fully blown e-commerce app, even if you could get a useful number of users. The only thing particularly specific to e-commerce (as opposed to general CGI stuff) is handling secure credit card tansactions and the like. All the rest is just vanilla CGI and database stuff.

There are really only three parts to secure transactions:

• Protecting the CC data in transit (use HTTPS with Apache and Open SSL) and securing your server to protect the back door.
• storing CC details securely. My advice is don't store the CC details. You cant hack CC details off a server if they are simply not there. Make the user re-enter CC details for every transaction (they will feel more secure about this anyway) Of course by all means remember all the other account details.
• Handing off to the 3rd party CC processor - they will supply the interface API spec and generally sample software in a variety of langs - and waiting on the response.

cheers

tachyon

s&&rsenoyhcatreve&&&s&n.+t&"$'$`$\"$\&"&ee&&y&srve&&d&&print

My advice is don't store the CC details. You cant hack CC details off a server if they are simply not there. Make the user re-enter CC details for every transaction

We had exactly this approach, together with a third-party CC processor on a place I was working on earlier, one of Scandinavias bigger electronics ecommerce sites. We had to change this approach and store the CC numbers because we had quite a lot of trouble with frauds.

We needed to be able to access these numbers when a fraud was suspected, and due to the third party company being quite stupid in what data they could receive and return (their system was lacking a lot, but they were the only ones in the market, more or less after some turbulent dot-com times), we needed to have access to them from our own computers. Maybe others have better luck in other countries. :)

Anyhow, we first made it so that the numbers were stored on another machine and not together with the other details, only a key to identify it by, and they were purged after a certain time limit. Later, we also added encryption to this data. Can but hope that all this was enough.

If possible, I totally agree that these numbers should not be stored. As it was now however, the data was very inaccessible, and only limited damage could be done if someone carried away our machines at night and managed to crack the encryption. :)

---

You have moved into a dark place.
It is pitch black. You are likely to be eaten by a grue.

• Search and/or join the mod_perl mailing list.
• Look into Interchange, and possibly join its list or even use it.
• If you decide to write your own, you can read my article about it.

But before you use Interchange, you might read my explanation of why I dumped Interchange.

Note it's been a couple years and I'm not sure what's changed with Interchange.

My current bias that I tend to write smaller e-com applications and the re-usable applications I find tend to be "too much" and are harder than needed to work with and maintain because of the additional complexity.

Although e-commerce is complex, it's a collection of things are all fairly straightforward these days: using a database, session handling and posting over SSL. Definitely because ther are financial transactions involved, I think there is more of emphasis (and programmer fear!) of quality control and "getting it right".

In my own cases I've found that custom solutions have been a good fit to build and maintain.

That said, I would happily consider adopting an e-commerce package if it used some my favorite tools:

CGI::Application, HTML::Template, Data::Pageset, SQL::Abstract, and Postgres

The right fit for me would allow me to use just the bits I need when I want them, and also have more power there when I need it....much like a collection of fairly independent Perl modules. :)

Mark

These are very valid criticisms and I agree with most of your sentiments. I've never used Interchange, preferring to build my own with the help of CPAN, like you do. Unfortunately, it's hard to find a better fully-working example e-commerce app in Perl. Zelerate is not good. Do you have any other suggestions for things we can point people at when they need an example?

I had spent some time on Interchange several weeks ago and encountered obsticle after obsticle until I finally threw my hands up and shelved it.

All I know of it is what I have seen in the demos. On preliminary inspection, it looks impressive, but I have yet to make a successful install. I may look into it again if only to satisfy the lingering questions of it's viability I still have. For now, I will reserve judgement.

One thought which I cannot help to ponder is that Interchange is put out by Redhat. Redhat's angle is ease of installation, yet in my experience with Interchange so far, it is not an easy install. Granted the documentation and reviews I have seen are upfront that it has a steep learning curve... at what point are the benefits of Interchange outweighed by it's steep learning curve?

For me, it is currently a time consideration. As long as I can satify my minimal requirements and keep away from security pitfalls, I'll take the least line of resistance for now. Who knows, by the time I am ready to consider taking Interchange off the proverbial shelf, there will be something better, or I will have advanced far enough to write something myself.

Like tachyon noted, the only real difficult part of e-commerce is the CC architecture and even that's not terribly difficult with the good work Ivan and others are doing with Business::OnlinePayment. The tough part there is working through the business side of the house to set up the necessary partnerships (payment gateway, clearing-house, and bank).

So I say, use perlmonks as your forum for e-commerce. Post your questions, meditations, and snippets here. Even if there not purely perl, I think most monks would see value in meditations on e-commerce especially if it clears the haze that surrounds credit card processing - anyone up for doing a meditation that compares and contrast payment gateways?

-derby

Thanks for the link to the Salon paper! I believe it is talking about the predecessor of Bricolage. My biggest problem with understanding how Bricolage worked was wrapping my head around the workflows, and this paper set me straight.

I also re-read Perrin's eToys paper again for good measure. Many thanks to Perrin for publishing the paper in the first place. "Ooooh oooh ooooh ahhhh ooooh...." I always loved those commercials... :-)

Thank you for staying with the spirit of my initial post. I have another question to throw in. What do people like to implement? As in their own SSL or a gateway? HTML, SSI, PHP, CGI, etc. And what about databases? Flatfile, SQL (which SQL? mySQL, PostGreSQL, Oracle?), ODBM, no datbase?

I just happen to think there's alot of interesting opinions to explore

I think most monks here begin with LAMP where the P is not PHP and not Python but Perl. For more detailed yet open ended discussions, you may want to consider attending your local perl mongers group.

-derby

Whenever email I receive looks like this, I tend to delete the message, because it looks like spam. I delete it before even trying to read it.

I know you don't care, but I did downvote your post, even though perhaps there's useful information in it.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

Ha! okay, now I can troll.

I wasn't going to say anything, but out of curiosity I tested the root post with 2 spam filters I wrote, and they both picked it up as spam due to the formatting. I have never had a false positive due to formatting before (100,000+ emails tested (I know it's not that much)).

I wouldn't have said anything, except for Juerd's post. So you might want to reconsider your formatting :)

You downvoted his post even though you thought it might have useful information in it?

I don't understand the basis for the downvote....either the good monk had an idea you agreed with or found valuable or not.

I don't understand the basis for the downvote...

Excessive formatting.

Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' }

BCE
--Your punctuation skills are insufficient!

My first time seeing your nick and signiture are worth the upvote by themselves. ;-)

Its always good to learn of additional resources, so thank you for mentioning it. The list appears to be a mailing list rather than an interactive site. Unfortunately for me this makes a difference as my email has limitations.