Forum OpenACS Q&A: online reservations and payments
I have been asked to provide a demo and ballpark quote for a system -
you know the way. I have been looking on the boards but I'm still
not sure about these points. <br>
1) Let's say it's a reservations system with extra functionality. Is
there a version of the problem set solution available which is
compatible with OpenaACS? We could base a system on that and build
on the extra functionality. <br>
2)It's to also include online payments - what's the current
recommended system (if any)?
Janine is about the finish the Verisign gateway while I am beginning on an Authorize.net gateway using the same service contract.
At the same I will be replacing the CyberCash calls in the ecommerce package with the above payment service contract. This enables the ecommerce package to work with Versign and/or Authorize.net. Others can then add more gateways such as IntelliPay, goEmerchant once the service contract has been released.
The gateway service contract will be released when both the Versign gateway and the Authorize.net gateway have been finished. We prefer to gain experience with more than one gateway to ensure that the contract is not geared to a particular gateway.
I am working on the creation of an ACS based travel trade directory, for which the payment infrastructure is critical. http://www.timedesk.nl.directory.htm. The plan is simple... Start getting agents and suppliers to register for the current 3.25 instance so people get a feel of what's coming. Once the payment modules are operational migrate to Acs 4. Is there any provisional timeline so I can invite a number of beta user to start playing around. Is there any chance we will have something operational by the end of 2002? What would the procedure for ACS users to hook up the the third party versisign and authorisze net services. Just follow what's on those companies web site, or is there a mechanism within the ACS environment that eases the registration and account activiation process? It would be great to have this info, so Know what to start writing as far as instructions and procedures go for TimeDesk.
You raise another point ... a quick guide to getting hooked up to Verisign etc would probably be useful for newbies.
Incidentally, we've had the VeriSign module available at:
I've added the support for Address Verification since it's initial release.
the tentative timeline is to have both the Versign and Authorize.net gateways working by the end of March. This could slide a little as I just starting on the Authorize.net gateway and haven't seen the Versign gateway yet.
You could test the ADC interface to Authorize.net without a test account by passing x_Test_Request="true" with each request. For more information read the Authorize.net developers guide.(https://secure.authorize.net/docs/developersguide.pml#TESTING)
However some extra software is needed to make a connection to the ADC interface of Authorize.net from OpenACS. My advice is to wait for our release which will include a complete installation guide.
Setting up an account with the gateway of your choice is beyond the scope of the payment service contract. Follow the instructions of the choosen gateway.
As for the initial question on this thread, I should be able to release the general_billing data model and API fairly soon. Looking through the ecommerce data model, I see a pretty easy pathway to making it an "extension" of general_billing. And billable content, or event registrations, or room reservations, or whatever, can be done without wading through the whole ecommerce juggernaut.
1. Client asks for a service.
2. Travel consultant checks resources
3. Quotes client
4. Process orders based on rates received subject to market conditions (i.e. that can change by the minute).
5. Agent confirms to client
6. Agent pays supplier ( or guarantees payment for realease after services are provided. (escrow account)
7. A last option would be where clients pay local and agents invoice supplier for commission, and supplier can pay to agent on a direct debit/credit basis.
This is a brief breakdown of my challenge. A solution has not yet been presented anywhere on the net but from what I have seen from the ACS toolkit, I am convinced it can be done. I also believe a number of people on this list are also working towards similar concepts. I.e. the alternative to the top heavy shoppingcart format. A great improvemnet would be to add baisic transaction infrastructure to the ticket tracker, because this tool can easily be linked to customer services processes of suppliers by means of hyperlinks. Jus some thoughts...
Other packages can use the contract to access a payment gateway of their choice. The payment service contract does not cover general billing issues such as recurring billing cycles, discounts or late fees. The service contract governs only basic financial transactions.
Your general_billing package could make use the payment service contract when it becomes available. Please do keep the community informed about the general_billing package. It sounds to me that the general_billing package could extend the payment service contract and offer general billing handling capabilities to other packages.
the current ecommerce module is ill equipped for customers to place orders for items that are not yet in the product catalog. You might want to take a look at the brief description of a new Merchant System that Tom Jackson is working on. In his design allows customers add products to their order, even if they do not already exist in the system. This allows customers to better communicate what products they need to purchase.
Then there are other considerations which don't fit the ecommerce package well. The quotes for the item (or service) would have an expiration date/time. The current ecommerce package is exclusively geared towards selling products from a catalog of a single vendor.
The OpenACS toolkit as a whole offers an excellent platform to build the system you are looking for on. The payment service contract would tackle the financial transactions while other (new) packages could meet some of the other challenges.
Ben, your order process is similar to the project I am working on. I need to contend with constantly changing prices and stock levels. In my case, suppliers are required to keep the website up-to-date. I believe that I will need to provide some kind of xml based remote update capability for suppliers, in addition to a web interface. I assume that customers will want products that are not completely specified, or even listed on the website, or products which are listed, but don't have a current supplier. Another capability that will find it's way into this system at some point is a shipping cost calculator. I'm not sure exactly how this will work yet, but at least UPS and FedX will be included. Shipments are separate from orders, and are applied to order items.
The Merchant System also assumes a high degree of customer/merchant interaction. I am more interested in automating the maintainance of the website and less intersted in automating the complete order process. Human interaction is required and desired for effective selling. What the merchant system is going to provide is a hopefully simple framework that can be expanded easily to satisfy the specific needs of a particular merchant.
In thinking about travel, this is a very complex set of products. I am guessing that a product could be something like 'round trip to Boston from St. Louis'. So this description could go into the products table. Several suppliers could offer 'stocks' that satisfied this 'product' in various ways. Each stock can have a separate description and price. In this case, the time and carrier might be what distinguishes the different stock items. Customers can search first for product and then list available stocks. In my case, I will probably not have separately listed prices, unless the quality of the stocks are different (used, referb, new ). Right now orders are placed by submitting a purchase order (order template). The order template lists only products. At the time the template is converted into an order, the stocks will appear and the user can select which stock, and set the quantity.
Something that might be nice for supporting corporate clients is that 'customers' are assigned things like credit, etc. whereas users are assigned to customers. Each user is assigned an appropriate privilege level that applies to the customer objects.
What I don't know is when this will be available for release as a package. It took me quite a while to organize my query-writer package which I will release this week, after OACS4.5 gets out, and it is a relatively simple package.
One thing I am currently struggling with is how to elegently extend the attributes of products. I thought I could use the content repository, but it looks like the external attribute table needs to be a table whose primary key references the content_revisions table. Also, this table is going to be just as difficult to extend as the current product table. So what I was thinking is a skinny table. With a wide array of product types, each with different relevent attributes, this might be more extensible. Maybe this table could then reference the cr table? Does anyone have an idea that would help me get a grip on this whole cr thing? I would like to come up with a simple interface to create new attributes, and make it easy to edit the product template to display these new attributes. Attributes could be things as diverse as manufacturer links, to product manuals. Probably I am thinking about this incorrectly.
To be continued
Your misspelling of focus (phocus) made me think of the PhoCusWright Travel Technology conference, which is in Atlanta in April. Philip Wolff, who organizes the conference, is a great guy and knows just about everybody there is to know in the business. I've attended two of these travel confernces and, from experience, they're well worth checking out.
Probably would be a bit easier to adapt the payment gateway service contract, but I haven't gotten to look at that yet, so I can't speak to that too well.
Feel free to take a look at our General Billing and Verisign Interface packages, as well as the Event Registration package which uses them. Mind you, these are all set up for MACS, so you'd have to put in some work to apply them to OACS.