Can you elaborate on the reasons why your company is prepared to drop the ecommerce module? Was it mainly due this error message or some other reasons?
Nagita Karunaratne, the boss' concern was mainly due to a series of errors, incomplete features, and undocumented steps, which pushed the project significantly passed the original deadline we set and others' expectations (that we had built up). We should have set up a working test site beforehand, but didn't think it was necessary since others were successfully using it. My mistake.
Hi, Tom. Gladly the backend issues have since been resolved.
For the record, the issues consisted of:
1. issues recorded in the bug tracker. Most are now fixed thanks to help from Bart and a growing number from the community.
2. poor documentation with a different payment gateway that seemed to claim compatibility to authorize.net. Turned out it was *not* compatible for direct access. We've created an ezic.com gateway thanks to help from Bart and EZIC. However, the site uses the authorize.net gateway. note: Ecommerce is limited to using one gateway.
Advantages of each? Authorize.net is the mature, sophisticated choice. EZIC gateway is a simpler, recent implementation. EZIC offers a feature to change the billing message that appears on customer statements, which is useful when setting up vendors with multiple domains. (The refund function has not been tested yet).
You should also note that every retailer has an infinite desire to customize their site with features, so you constantly have to hack in these features.
Customize? Actually, we just wanted to start with a generic running setup and modify later. The generic features are reason enough to choose openacs' ecommerce package. However, it became clear to us that not all ecommerce features ported from aD have been used. Or, if they were, bug fixes did not make it back to openacs.org.
Weaknesses? There's one feature needed before officially announcing the implementation. We're working on a single checkout form that integrates with the existing multipage ordering checkout format, so that the one page form is used for first timers, and the multipage format is used when more than one address already exists for the user. This should reduce end-user usability issues we've encountered. The code will be worked in to 5.x.
