Forum OpenACS Q&A: new ecommerce modifications

Posted by james shannon on 08/12/00 06:32 PM

Hello...
    I know that the ecommerce module is importatnt for the company I'm working for, and I don't know how important it is for everybody else. Anyways, I plan on cleaning up any bugs(just doing a grep, there still appears to be sysdate()'s left), and also creating an alternative to cybercash.
    I'm sure nobody will have a problem with me cleaning up the bugs, but the heart of my question is this: How many "extra's" would you like me to upload back in to the sourcetree? At the very least, we plan on doing little things such as allowing for the products to be ordered on the category listing page and allowing a descriptive category test to go along with the listing. How far should we stray from ACS Classic?
    As far as the cybercash alternative, my company has decided to use something called intellipay. It looks quite promising. It's flexible, cheap, and easy. (Just like Scott M :). It works via HTTP POSTs to their website that contain the billing information and name/value pairs in HTML that contain the status information. Hopefully, I'll be able to produce it as a separate package that can be installed at will. But, if I can't do so easily, would anybody be interested in seeing it implemented with OpenACS(with the appropriate settings to turn it on and off, of course).
    Also, is anybody else itching for a full implementation of ecommerce that wants to join in?

Thanks..

2: Response to new ecommerce modifications (response to 1)

Posted by Don Baccus on 08/12/00 07:13 PM

The sysdate's aren't necessarily bugs, remember that we have sysdate() as a function that returns the current date, and view called "dual" that returns sysdate() as a single row, so "select sysdate from dual" works (as well as "select 1234 from dual" etc).

There are parts that haven't been ported yet - you should probably talk to Ben, who ported most of what's been ported.

Regarding an alternative to cybercash, yes, I'm sure folks would be interested. Not only OpenACS people, but ACS Classic people. It would be good to isolate differences to settlement-specific tables so the rest of the ecommerce module doesn't need to know about this change (which I'm sure you're already planning on).

3: Response to new ecommerce modifications (response to 1)

Posted by Ben Adida on 08/12/00 07:33 PM

More functionality is always good. However, at this point, I would recommend to focus on fixing bugs and defining a more generic payment fulfillment interface, rather than truly rearchitecting the whole module.

The reason is simply ACS 4.0, at which point you'll be able to have a truly modular system that doesn't bring about conflict with the rest (and you can even fork the ecommerce module!). I recommend holding off until then to really bring about huge changes to the ecommerce module. By the way, as soon as ACS 4.0 is available via CVS, we're going to start thinking about an approach to porting it.

4: Response to new ecommerce modifications (response to 1)

Posted by james shannon on 08/13/00 05:23 PM

    Do we have an idea on when we will have CVS read access to ACS 4? I'd like to look at ecom4 and see how many changes they have made/plan on making.<br>
    As far as holding off - that's easier said than done. This is one of those 'next week would be fine, thanks' projects and unless waiting offers huge benefits(thus the peek at acs 4.0), then I'm probably going to have to go ahead with using the current ACS and modiying it out to whatever I need.<br>
    Which brings me to my original question. If I do modify the current ecommerce for more functionality, Ben/Don, should I merge the useful parts back into openacs or do you want as close a mirror to acs classic as possible?

5: Response to new ecommerce modifications (response to 1)

Posted by Don Baccus on 08/13/00 08:04 PM

I'd say by default we want to mirror, other than bug fixes.

On the other hand, if you're doing this work anyway, why not keep a specific list of features you've added? We can then think about what can be folded in.

6: Response to new ecommerce modifications (response to 1)

Posted by Scott Mc Williams on 08/19/00 01:42 AM

<blockquote>>It's flexible, cheap, and easy. (Just like Scott M :).
</blockquote>

Ok...THAT was a cheap shot. True, but cheap. :)

7: Response to new ecommerce modifications (response to 1)

Posted by Dave Bauer on 08/25/00 03:59 PM

I will be setting up ecommerce on OpenACS in the next few weeks, I would be interested to see any alternative payment options. I just started looking to the module so I am not sure of everything that is involved.

8: Response to new ecommerce modifications (response to 1)

Posted by james shannon on 08/25/00 06:45 PM

I've promised myself that I'll get to it this weekend. I've researched it a bit, and I think that once I get tsl(?) working with OpenSSL(the largest problem), then I can get a version of util_httppost working with SSL. Once that happens, I think it will be relatively simple to make a function or set of functions similar to cc_stub that Ben(?) created.

Intellipay, as I understand it, costs something in the range of $50 to set up, and takes a %1.5 transaction fee. Better than cybercash for small scale sites and better than manual fulfillment in most instances.

9: Response to new ecommerce modifications (response to 1)

Posted by Bart Teeuwisse on 06/11/01 09:03 PM

James, where are you at with your work on intellipay? I'm currently taking a look at their solution and think it could work very well for our small business site. We are running OpenACS 3.2.5 for the moment but intent to do our major site development in OpenACS 4. I'm hereby offering my services to help integrating alternative settlement solutions into the ecommerce module.