interchange for e-commerce?

[dshahin]

I recently purchased a business (a comic book store) that I want to modernize in a big way. I need both an effective point of sale system, and a complete online storefront. I want to use Perl, for obvious reasons, but find myself wondering whether to totally build a custom system using CGI::Application and HTML::Template, or to use something like RedHat Interchange as a platform and concentrate on customizing that.

My main concern is to spend as little time reinventing the wheel as possible, yet have a design that will scale well when and if needed to. The fact that I can rebuild an Interchange server from official vendor CDs is also a plus to me. Is there another Free appserver out there that uses Perl and is better supported?

I'm also looking for any info in general about linking my application to credit-card processing software. Are there Perl modules to do this sort of thing, or am I stuck with whatever the credit card companies dictate?

thanks in advance.

[maverick]

The credit card part I can help with. I have a client whose site has online payments and it uses the 'PayFlow Pro' system from Verisign. There is a Perl interface to the library which is very straight forward ($return_hash = pfpro($hash_ref)). I use it under Linux, but I think there are versions for a bunch of different platforms. You do have to do some setup with verisign and your bank to make all of this work, which if I remember correctly is basicly a few forms and a fee. The other thing you'll need is a SSL certificate so that you can run your e-commerce app under SSL. Don't even consider handling credit card info without using SSL on the server.

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

[dshahin]

thanks for the tip. seems like they have just what I need. should I buy a certificate from them too, the price seems a little steep to me.

[maverick]

The price is pretty steep...but there aren't many choices.

Now here's the part that really sucks. All the certificate gets you is not having a dialog box pop up in the browser that says "we don't know who these people are. do you want to trust them?" If you click yes, then everything works exactly as it would if you went to say eBay or some other such site.

Basically what the certificate from versign is, is a third party that the browser already trusts saying that your site is to be trusted. Pure psychology, dialog boxes of that sort tend to spook people...to me the whole thing is a racket.

/\/\averick
perl -l -e "eval pack('h*','072796e6470272f2c5f2c5166756279636b672');"

[drewbie]

Keep in mind that Verisign is evil incarnate. ;-) They now own Network Solutions, which is another evil corporation. How much spam do you get from NS selling the domain database? They do it themselves, even they say they don'w/won't! And yes, I'm a bit biased.

See http://www.kuro5hin.org/story/2002/3/8/17563/05947 for just one example. There are many others.

[dws]

I recently purchased a business (a comic book store) that I want to modernize in a big way. ... My main concern is to spend as little time reinventing the wheel as possible, ...

You might consider spending zero time reinventing the wheel. Instead, go with an off-the-shelf package.

As a new small business owner, you're going to be wearing lots of hats. If one of those hats is technical, particularly if it's one you're tempted to reach for a lot, you're upping the risk of either burn-out or running the business into the ground.

The failure rate for small business is high enough. Why risk notching the risk up?

[Ryszard]

For a modest fee I'm sure there is more than one monk here (including me) who would be willing to take over the technical hat.. ;-)

[perrin]

I see it as a tradeoff in cost/ease of setup vs. specific functionality. You can make a store on Yahoo's shopping thing within a couple of days and it won't cost you much, but you won't be able to customize it much either, beyond changing the basic graphics. The next level is packaged software like Interchange. It will be faster than building your own, if what it does is close enough to what you want. The final level is building your own, probably based on some existing framework like OpenInteract or Apache::PageKit. We built our own at eToys because our needs for specific functionality and scalability exceeded anything that was available at the time. (Note that Interchange may have improved a lot since then.) If you're wondering how much work it takes, read my article about it.

[gav^]

I have to disagree with the first point, I work for a company that develops a lot of big (and small) Yahoo stores. There is a large amount of customisation possible, it is great value and also scales for big sites. The main advantage is that you are running straight away and that you get all the traffic pushed from the Yahoo network (which can be considerable and some big players have Yahoo stores in addition to their main sites just to attract this traffic).

gav^

[perrin]

Thanks for the info on Yahoo store. My assumption was based on the relative uniformity of the sites I see on it. Also, you can't actually modify any code, right? So if you wanted a special feature, like a gift registry that would give discounts to people who buy from it or a special offer for customers who meet certain conditions, you can't really do it yourself.

Maybe you could update your answer with some information on the flexibility and limitations of the Yahoo option?

[shotgunefx]

I'd have to concur with gav^ on this one. If you know how to work it, Y! Store can be a very flexible solution. (Definitely not without it's faults though.) The biggest thing you gain is traffic and the ease of maintenance is nice too. (big cluster O'servers, connectivity.)

-Lee

"To be civilized is to deny one's nature."

[justinNEE]

You do have options when it comes to merchant accounts, check yahoo under:

B2B>Financial Services>Transaction Clearing>Credit Card>Merchant Servi
+ces.

The last one I worked with was authorize.net. They let you ftp a batch of credit cards / charges whenever you wanted to or use a page that was on their server as the credit card form. You can change everything on that page. (e.g. add your own logo, add more inputs to the form, etc) You also tell them what page you want it to go to after the charge is made, and it passes you acceptance/denial info. Its kind of primitive, but I don't think you even need pay for an SSL certifcate since you never have the credit card number.

[webadept]

Alot of my customers have told me that Costco has a merchant account thing worked out with IONGate. Many of them have switched from various others to this because the pricing is so reasonable. Reasonable enough to pay me to switch the coding for them.

I don't use them, or any merchant accounts so no personl experience, except writing to them. Their interface is pretty direct and simple. You will need SSL if you want anything beyond "Thanks for your credit card" or using their form. But again its pretty basic, of course most of them are now. It doesn't profit them to make it difficult for Perl programmers to interact with them.

Good luck, and umm... do you got any good Witchblades?? :-P

Glenn H.

[Stegalex]

I run a small Yahoo! Store which you can view here. While I like coding in Perl, there are some SERIOUS advantages to being a Yahoo! merchant which compensate for most of Yahoo!'s shortcomings.

Advantages of Y!
• Being indexed into Yahoo! Shopping's search (HUGE)
• Merchant account, cc processing, security, availability
• Quick and Easy to get online fast
  
  Disadvantages of Y!
• Inventory control does not work
• Lack of Returns Processing
• Lots of merchants don't like their ratings system
• Customers can't find out shipping cost until they are just about to place orders.
  
  All in all, Y! Shopping is a very good deal IMHO. I like chicken.

[Necos]

Earlier today, I was lurking around the ActiveState webpage (yes, I know they're pretty grey area around the Monastery) looking for the Win32::Lanman module, when I came across something very interesting:

Business-CreditCard ver. 0.1 Validate/generate credit card checksums/names

I thought to myself: "Who in the hell would want that?" Apparently, some people have a need for this module. I don't do the e-commerce thing, but it might be worth looking into what this module can do. It seems to me that it would a nice thing to do (as a favor to the servers that might end up validating the credit cards) to do a small check to see if the credit card is valid (hehehe, I remember the old grade school jokes of entering 1111-2222-0000-1111) before passing over the credit card data over to your CC clearing house.

Best of luck with your business venture,

Theodore Charles III
Network Administrator
Los Angeles Senior High
4650 W. Olympic Blvd.
Los Angeles, CA 90019
323-937-3210 ext. 224
email->[e-mail]

[zentara]

These newer ecommerce packages are getting way too big and complex. I want something I can understand , when I look thru the scripts. Have you looked at Perlshop? http://www.perlshop.org It's all perl, simple to understand and modify. It still uses a cgi-lib sub for getting params, but it can easily be converted to using CGI.pm. Perlshop supports a wide variety of cc cards, and you can easily make a custom cc verification sub for your special cases. It can be integrated with a database. It's free, you are free to modify it, it works, it's all perl, and it's still simple enough to understand. The guy who took over the sourcecode at waveridersystems, has an inexpensive addon called Office, which allows you to view order histories and print out shipping labels. Enough sites have been using it, without problems, that it appears to be pretty solid.

[oubiwann]

I have setup and installed Interchange with a PostgreSQL backend several times. There was a little manual handiwork that was required (due to pg permissions, etc.). In fact, I started playing with it when it was still MiniVend (if you look at the internal variables, you will see all the MV's referencing their herritage :-) ). It has really come a long way.

I have used, developed on, and administered massive e-commerce kludges such as Broadvision, and I have to say that I really like what I have encountered with Interchange. It's free, it's perl, it's fast and it's dependable. However, there are some things to keep in mind:

• You are going to have to learn at least some of the templating and scripting that they implement (even though you can write embedded perl).
• Interchange lacks some of the advanced features of the more $$ suites, including such things as (please correct me if I am wrong) connection pooling with Databases.
Also, I have only done 2-tier... I don't know how well it handles 3-tier/increased distribution/load balancing... I haven't needed that stuff for the small projects I have done - maybe you won't need it either.

[barrd]

In terms of expansion the Interchange suite is capable of such. In the words of the Guru - Mike Heins "anything is possible". If you subscribe to the Interchange mailinglist:

Interchange Mailinglist

There are many people who can help out with such ventures, of course a very good knowledge of Interchange and a variant of SQL is necessary. Dan Browning (from the list) has achieved many solutions in this area as have others.