Home
The Toolkit for Online Communities
17238 Community Members, 0 members online, 1793 visitors today
Log In Register
OpenACS Home : Forums : OpenACS Q&A : online reservations and payments

Forum OpenACS Q&A: online reservations and payments

Icon of envelope Request notifications

Collapse
Posted by Ciaran De Buitlear on
Hi,
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)?
Collapse
Posted by Don Baccus on
Janine Sisk and Bart Teeuwisse (did I spell that right?) are working on payment gateways for OpenACS 4.  I know Janine's essentially finished with the Verisign version but it won't go into our CVS tree immediately, not before we release OpenACS 4.5.
Collapse
Posted by Bart Teeuwisse on
Don, you spelled my name correctly. :)

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.

Collapse
Posted by Ben Koot on
Bart,

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

Collapse
Posted by Don Baccus on
The payment stuff we're talking about will certainly be done long before the end of 2002.  Maybe Bart can chime in with an estimate as to when he thinks he might be done with integrating stuff into e-commerce.

You raise another point ... a quick guide to getting hooked up to Verisign etc would probably be useful for newbies.

Collapse
Posted by Ben Koot on
Don, I just sigend up for 30 day verisign demo  Authorize.net.  doesn't seem to have a demo account set-up. I will keep you posted
Ben
Collapse
Posted by Brad Duell on
The ecommerce module of OpenACS is very robust when it comes down to it.  We've modified it to do sales of event registrations through the Verisign authentication process, and it's worked fine for us.

Incidentally, we've had the VeriSign module available at:
http://www.ncacasi.org/contrib

I've added the support for Address Verification since it's initial release.

Collapse
Posted by Bart Teeuwisse on
Ben,

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.

Collapse
Posted by Titi Ala'ilima on
We're currently working on an event registration package which needs on-line billing.  I've been working on a general_billing package which could eventually be inserted under the e-commerce package, but it would be much more lightweight for purposes that don't require all that stuff.  However, all this talk of Verisign and stuff leaves me wanting a little more information on your payment gateway service contracts.  We are on a short timeline for our prototype, but perhaps by the time our project is concluded, we can bring these two things together.

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.

Collapse
Posted by Ben Koot on
The travel trade formula I am working on is no longer based on FIXED PRODUCT RATES in a database because in the travel industry this model is no longer a valid business concept. Most transactions are based on yield management ( for your info, listen to this interview" . The product info can be stored in the product module of ACS e-commerce, but rates are subject to confirmation from a variety of sources ( on-line systems like www.expedia.com www.orbitz.com or as advised by supplier by e-mail to retailer)

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

Collapse
Posted by Bart Teeuwisse on
Titi, the payment service contract is a contract much like the search service contract. It defines a contract (or API) for financial transactions such as charging, crediting, voiding etc. A contract can have several implementations each implementing the defined transactions differently. E.g. the Authorize.net implementation would use the Authorize.net gateway to perform the actual transactions.

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.

Collapse
Posted by Bart Teeuwisse on
Ben,

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.

Collapse
Posted by Tom Jackson on

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.

Collapse
Posted by Ben Koot on
Tom, Over the next few days I will put together a string of requirements that might be helpfull and could easily be related to the problems you are trying to solve. I will phocus on travel. A. because that is my core competence (and has been for 15 years) and B because travel has been recognized as the world's most potentialy succefull comercial application industry in the world. I am connected to a network of 1800 mainly US based travel advisors that need to reinvent their businessmodel, and are in real need of a travel advisors controled software application, so they can match the logistics of systems like Away and site59, both based on ACS. Untill today travel advisors have relied upon the technological support of companies like Sabre , Timedesk I have a meeting in Orlando in May this year with a number of ringleaders where I can " plug" an OACS based sollution

To be continued

Collapse
Posted by Clay Gordon on
Ben:

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.

...That's causing me serious grief?  To use third party credit card authorisation software eg. We're building a bookings system, connecting it to Trintech / Gladstone "payware" system.  To do design, built and test interface to payware (including the info we need to store on "our side"), interface with payware, Integration, Bank testing.  Just a ballpark.  Anyone?
Collapse
Posted by Ciaran De Buitlear on
Sorry - that might be unclear - I'm looking for a ballpark estimate of the number days effort involved.  If you've done something like this before can you help?  It's obvious to me that the type of "middleware", the bank invilved etc. are huge factors but if I got a couple of examples I would be more informed.  I might also implement the solution that was the easiest!
Collapse
Posted by Titi Ala'ilima on
Custom programming the integration for a given payment gateway (Verisign) probably has taken about 3 developer weeks to get a pretty robust system in order to communicate with the gateway, and another many scattered hours of non-dev time are required to make sure the bank and the processor and the gateway are all talking to each other.

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

Collapse
Posted by Jacky dfsfdg on
I use iKobo as online payment service and I have to say that Iam quite pleased with thier services. They have improved also the customer support with live system, they have the largest coverage of all online payment services (170 countries) and the fees are really low. I tell you from my experience they are reliable and very fast because they use an revolutinary system called iKard (a debit Visa electron card). They send this card to everyone that receives money on his iKobo account. You should check them out at www.iKobo.com. They work for me.