Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

E-Commerce Monks

by Alexander (Sexton)
on May 08, 2003 at 03:16 UTC ( #256461=perlmeditation: print w/replies, xml ) Need Help??

I'm pretty well decided on a Unix/Apache/Perl approach to establish an E-Commerce presence. I have yet to iron out all the details and it just seems more painstaking to find a decent bunch of informative e-commerce resources than I would hope.

I have also sought out places to discuss the topic with others, but have not found anything.

As great a place as Perl Monks is to share info and insights, I would like to gather monks with an interest in discussing and sharing e-commerce/open-source/apache/perl experiences, discoveries, insight, and even code.

I know there are monks here who would benefit from this. If such a group already exists, I want to be a part of it, if not how about we create one!

Sure, we deal in opensource, but so many of us do business.

I happen to be of a mindset to share and benefit alike. Heck, thats the whole idea of opensource anyways. So here I am, attempting to target the select bunch of us who dabble with E-Commerce stuff.

Hey, sometimes the only way to know is to ask! =)

Edited 5/9/03

Formatting removed.

Hey, sometimes, all you need to do is ask. ;-P

Replies are listed 'Best First'.
Re: E-Commerce Monks
by tachyon (Chancellor) on May 08, 2003 at 03:38 UTC

    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.




      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.
Re: E-Commerce Monks
by perrin (Chancellor) on May 08, 2003 at 04:11 UTC
    • 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. :)


        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.
Re: E-Commerce Monks
by derby (Abbot) on May 08, 2003 at 13:08 UTC
    I always thought most of the monks here do e-commerce work. That's one of the main reasons I posted the GnuPG tutorial and it's also the reason why I read (and re-read and re-read and will probably read again) perrin's great EToys article and Salon's Industrial Strength Publishing

    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?


      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.


Re: E-Commerce Monks
by Alexander (Sexton) on May 08, 2003 at 04:10 UTC
    Mostly Vanilla, yet distinct flavor still matters. Bryers vs. Ben & Jerry's vs. xyz brand, etc. Focus and intent still matter. All the supplementary/complementary stuff that goes along matters aswell. Such as Hey, I found this great article/script/daemon/work-around/tutorial/etc today!. Lately, most of what I do has revolved around E-Commerce. I know I cannot be the only one on here. So here I am seeking to gather together a collective conciousness.

    Thank you for your contribution. :)
Quick! Jump on the band wagon! (was Re: E-Commerce Monks)
by Alexander (Sexton) on May 09, 2003 at 14:10 UTC
    Fine, so you didn't like the formatting, and you even felt that it overshadowed any point be it good or bad.

    Well the point was good. The point is still good, and while expressing an objection to the formatting is understandable, those who did so were callous.

    I will gladly abide by the objections to the formatting, but I would make a suggestion to those who objected: Be more positive. Life is not worth being callous.

Re: E-Commerce Monks
by Juerd (Abbot) on May 08, 2003 at 16:53 UTC

    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 => '', plp_site => '', 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 => '', plp_site => '', do_not_use => 'spamtrap' }

          A reply falls below the community's threshold of quality. You may see it by logging in.
Dont dismiss, Mentor (was Re: E-Commerce Monks)
by Alexander (Sexton) on May 12, 2003 at 15:44 UTC
    I would like to suggest not being so hasty to dismiss everything not directly related to accepting credit-cards. I know that once you reach a certain level of knowledge and capability that it becomes difficult to understand the haze which clouds the vision of those who are less accomplished. But it is my understanding that Perl Monks is here as a place to learn and share, for the advanced and novice alike.

    If you are an advanced member, dont shoot some question or topic down because you as an advanced member have advanced beyond a need to discuss it. The not-so-advanced still may reap great benefits. Everyone must go through a learning process to become advanced. Shared experience and lessons from mentors are part of that learning process.

    Dont dismiss. Be a mentor, or be silent so those willing to mentor can be heard.
Re: E-Commerce Monks
by BorgCopyeditor (Friar) on May 14, 2003 at 21:16 UTC
    You could try "the list" on (which site also has useful articles from time to time). It's somewhat web-centric, and sometimes seems plagued by HTML-slinging webmonkeys asking about which META tags will get their clients' site to #1 on google, but it also has some old-timers who know just about all there is to know about running an internet business. In any case, they're all professionals. The feel is somewhat similar, if a little less expert overall, to that of this site.

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

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://256461]
Approved by ybiC
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2022-11-30 01:40 GMT
Find Nodes?
    Voting Booth?