TechTalks Transcript
E-Commerce on Campus
 Judith Boettcher [JB] |
 Howard Strauss [HS] |
 Jack Duwe [JD] |
 Brian Busby [BB] |
April 27, 2000
Audio
• Streaming
MP3
• Download
MP3 (Download
Tips)
JB: Welcome to the CREN TechTalk series for spring of the year 2000 and to this session on "E-Commerce on Campus." You are here because it's time to discuss the core technologies for your future campus.
Many thanks to IBM's Global Education Group for their partial sponsorship event on E-Commerce. IBM's approach to E-business on campus is to start simple and grow fast while building on what you have. That's very similar to the story you will hear today from our guest experts from the University of Wisconsin.
This is Judith Boettcher, your CREN host for today. I'd like now to welcome the technology anchor for TechTalk, Howard Strauss of Princeton. Howard is a well-known web and all-around information technology expert. Howard?
HS: Thank you, Judith.
I'm Howard Strauss, the technology anchor for the TechTalk series of CREN webcasts. As technology anchor, I'll engage our guest experts in a lively technical dialogue that will answer the questions you'd like answered, and ask those very important follow-up questions. You can ask our guest expert, Jack Duwe and Brian Busby from the University of Wisconsin, your own questions by sending e-mail to expert@cren.net any time during this webcast. That's expert@cren.net. If we don't get to your questions during the webcast, we'll provide answers in the webcast archive.
Business Week says that in 1999, 13 billion dollars was spent for online travel services, 14 billion for financial services, and 53 billion for computers and electronics. Projections suggest that in 2001, 50% of all retail stock trades will be done online. Some e-commerce companies are losing billions of dollars, but consumers and corporations alike have accepted e-commerce as one of the best ways to transact business. By 2003, a trillion dollars per year is expected to be spent on e-commerce transactions.
Of course, every member of the university community with access to a network PC -- which includes virtually everyone today -- can buy books, trade stocks, bid on antiques and buy airline tickets online. Since anyone can buy everything online, it might appear that universities have no need to offer their own e-commerce services. After all, what would universities sell that can't already be bought online?
Well, for one thing, they might sell tickets to university athletic events and theatre groups. They might also sell computer software, computer hardware, textbooks, university t-shirts and distance learning access. And of course, they could sell applications to the university. Look around you and you'll see that bricks and mortar commerce is being done in many places in your university. In most cases, those transactions could be done using e-commerce, which would be much more convenient and much more cost-effective for both your customers and your merchants.
Did I say "customers and merchants"? To think like the e-business people we will be for today's webcast, you must think of your users -- the folks who will buy stuff -- as customers. The departments and groups that will sell to them are merchants in e-commerce terms. Although e-commerce needs to be supported by web servers, databases and the usual melange of computer hardware and software, doing it will get you closer to banking and accounting than to conventional software development.
It might be tempting to avoid all of this and to outsource all of your e-commerce functions. That is something you might especially want to carefully consider when you learn that the University of Wisconsin has shipped 36 tons of CD-ROMs -- that's 500,000 of them -- from their own warehouse that were ordered by their own e-commerce system in just the last six months. But you'll also learn that getting an e-commerce system working and managing it is easier in many ways than you might guess.
Our experts from the University of Wisconsin have made it work very effectively in a university with about eight times as many faculty and staff as we have students here at Princeton. If it can work there, it can probably work anywhere! We'll find out how to make your collegestate.com a credible alternative to amazon.com on today's webcast of TechTalk.
Judith?
JB: Well, thanks very much, Howard, and with your introduction, I know that people know that the world of e-commerce is just really large. And what we'll be focusing on today is just really one piece of it and one very nice little story about what they're doing at Wisconsin.
So with that, let me introduce our two guest experts with us today, and they are Jack Duwe and Brian Busby. Jack is the Deputy CIO for the University of Wisconsin at Madison and the Associate Director of DOIT; and Brian Busby is the Senior Project Manager at the UW Madison Division Of Information Technology, which is that same DOIT group. (Nice acronym, actually.) Pictures and more on our experts are at the website.
Welcome, Jack and Brian. So glad that you can be here with us on TechTalk.
BB: Good afternoon.
HS: Jack, Brian, why don't we start by talking about what kind of e-commerce should be on campus? That is, what are the key applications that you see for e-commerce on campuses?
JD: Well, we look at anything that universities provide and collect money for as good candidates for conducting with e-commerce. This may include some of the things you've mentioned -- selling athletic tickets, football tickets and the like, selling conference registrations, selling software and for that matter, taking contributions from alumni and other people.
HS: So doing all the fund-raising kind of things?
JD: Fund raising is a good candidate.
HS: As e-commerce?
JD: Yes.
HS: You give your money and what you get in return is having given your money.
JD: That's true. You get the satisfaction of knowing that it's going to an excellent cause!
HS: Okay. Well, when we talked to you earlier, you said there were some, I believe, 22 departments that you viewed as merchants at University of Wisconsin.
JD: Yes, that's true. There's a couple of dozen departments, and I think, Brian, there's what -- about 40 different storefronts currently in operation?
BB: Yes, that's correct. We have basically 24 distinct departments on campus and some of them are running multiple storefronts, so we have right around 50 storefronts being served by our e-commerce service right now.
HS: Okay, tell us more what you mean by storefronts. Perhaps you could give us an example of some department that's running multiple storefronts.
BB: I think a good example of a merchant that's running multiple storefronts right now is our Union, our Wisconsin Union. Every summer, they have an International Conference Series.
HS: When you say your Union -- is that the Student Union?
BB: Yeah, that's correct.
HS: Okay.
BB: That's correct. They run -- besides doing Student Union things, they also have a Conference Services department and they run international conferences during the summer. And what we have provided for them is the ability to put registration forms, which are, in essence, storefronts to the --
HS: Hello?
JD: They're coming in to alumni but others -- in particular fields that they run for schools like Engineering and Business and other particular units on campus.
JB: Okay, in terms of the various storefronts, then, that you have, the storefronts really are storefronts from these different departments. When you talked about e-commerce, one of the concepts that we try and distinguish is between the business-to-business commerce and then the business-to-consumer commerce. From what you've described, what you have at Wisconsin, Jack, what you have is a combination -- that you at DOIT serve as a business-to-business to the departments, and then the departments to the consumers. Would that be a fair characterization?
BB: That's absolutely correct. We are a business that is a hosting business for our e-commerce merchants and we act between them. Between the merchants and us, it's business-to-business, but they are serving customers, consumer-to-business e-commerce.
JD: Now, in addition to this, Judith, of course we serve many business-to-business functions that are not covered with the infrastructure that we're talking about today. Transmitting paychecks electronically and transmitting payments to vendors electronically go through the usual banking channels that I think most universities do use.
HS: Sure, but I think today we're talking about folks sitting down at some kind of web browser and transacting e-commerce.
JD: Yes, I think that's right. The business-to-consumer function is the primary thing from the university perspective that we're talking about today.
JB: Okay, great. Many people, you know, find sometimes that it's real hard to get started with this stuff. And I think when we talked, you were saying that one of the first applications that departments came to you for was handling conference registrations. Would you like to tell us a little bit more about the departments that were interested in that and how that got started?
BB: Well, basically, when we first started this out, it was the fact that a lot of people wanted to do conference registrations. A lot of the merchants that came to us initially had already --
HS: Now, you keep saying "merchants." You mean departments? We want to keep track.
JB: It is a little strange to talk about our department heads and merchants.
HS: When I think of merchants, I think of people we buy our books from and paper from and whatever.
JB: But these are the department chairs and all, right?
BB: That's correct. And a lot of these departments had already put up web forms that would allow for registration and they were capturing the data from those web forms. We put it back in database. What they were missing was the completion of the transaction.
JB: Aha! Okay.
BB: Taking the actual payment. And that's what -- it was basically driven from the customer saying, "We can get this far. We can fill out your web form. We know you're getting our information. Why can we not complete the transaction and pay you at the same time?"
HS: So it was actually them seeing things like dot-coms like amazon.com and buying airline tickets online and saying, "Why doesn't the university do things more like that?"
BB: I believe so, yes.
JB: Okay.
HS: If you had a new department coming in that wanted -- if you had a potential new merchant, how do they go about making this thing happen at University of Wisconsin? I'm a new department and I decide I want to sell tickets to something. What do I do to make this happen?
BB: Well, there's a couple of steps involved. One of the first things that we have a potential new department/merchant do is talk to our Business Services departments.
HS: That's part of DOIT?
BB: No, that's actually part of the university itself. They handle all the financial transactions for the university. And as such, even before e-commerce came along, they were responsible for setting up what's called a merchant ID, basically identifying a department as someone who was able to accept credit card payments.
HS: Okay. So this is somebody, like, out of the Treasurer's Office or something?
JD: Yes, that's right.
HS: Okay, so they go over to these folks, they convince the university that it's okay for them to sell stuff.
BB: Right. And basically, when that okay has been given, they fill out an application to obtain a merchant ID which identifies that they are a merchant now.
HS: They get that merchant ID from whom? Where does that really come from? Is that coming from a credit card company?
BB: Yes, it is. It's coming from a merchant service provider. Now, the state of Wisconsin has a contract with a bank, and that bank has a contract with a merchant service provider that does just what it says: It provides services to merchants, one of which is allowing them to take credit card transactions.
JB: All right, so you had mentioned this. It's the state of Wisconsin or the university that has the relationship with the bank?
JD: Yes, the state has -- since we're a public university, the state has the contract with the bank and we use that same contract.
JB: Okay, so the steps, then, is that the state has a contract with the bank, and then the bank has a relationship with the credit card.
BB: That's correct, with the merchant service provider.
HS: And that's a company you said was called ELAN.
BB: ELAN. In our case, it's ELAN.
HS: Right, so we talk about ELAN here, we're talking about this intermediary between the bank and the credit card company.
BB: That's correct.
HS: Okay, now, so that department now has this merchant ID and what do they do next? This hasn't quite gotten me on the web yet.
BB: Okay. In terms of here at UW Madison, their next step is to go to our payment processor, which is the link between the Internet and the banking network which allows you to authorize credit card payments. We happen to use a company called CyberCash for that piece.
HS: And you chose them because?
BB: Again, when we started about two years ago with this, based on the state contract, as you walked up the chain through our bank, through our merchant service provider, that was the company that was chosen by the merchant service provider to be the payment processor.
HS: So you end up choosing nothing. The bank was chosen for you, and the bank chose the merchant service provider, and they chose CyberCash.
BB: That's correct.
JD: Pretty simple, Howard.
HS: Yeah!
JB: It certainly reduces the amount of decision making that you're doing.
HS: Okay, but at any other university, you would probably do the same sort of thing, then. You would go out and find out what bank the university has kind of a strong relationship with, like probably where they deposit their paychecks and things, and you're saying that that bank would have some kind of merchant service provider.
JD: I would think typically that would be the case, Howard, and if I were in another university, I would certainly establish a good working relationship with the treasurer or the Business Services operation of the institution because this is a partnership operation. We're not going into competition with them by any means.
HS: Now again, if I'm this department and I want to sell these tickets but I don't have a website built, does DOIT build it for them? How --
JD: That's an option. One of the things that these people usually do first is to call Brian, and Brian helps walk them through the process he just described because you only do that once and there's no point in people learning it from scratch each time. And Brian's certainly familiar with the process and the people involved.
Then in terms of the website, if there's an existing website, Brian has application interfaces that people can simply call to take care of the cash handling part of the process or the money handling part. And if they have no website at all and want us to construct a website from scratch, he can take care of that as well.
HS: Okay, so now we have this website up. How do I get my money? People are out there using this website -- how does the money get in my pocket because I've just sold these tickets?
BB: Okay, well, let's finish off by saying what happens with CyberCash. In the case of UW Madison, our department/merchant is going to establish an account with CyberCash. At some point in time, typically within about five business days, the merchant ID that they signed up for is going to get filtered down to CyberCash and there's going to be a link between the CyberCash account and the merchant ID. One of the things that's on the merchant ID is what's called a DDA, the Draft Deposit Account, which bank account should money that's coming in through CyberCash be deposited into?
So basically, the flow of information through is you've got a website, it's got a web form on it. You're asking your customers to fill out that web form, including the credit card number and expiration date. It's all served out on a secure website. That transaction gets taken off of the web form, gets encrypted --
HS: Okay, can I -- I just want to interrupt you just for one second if I could to point out to people who happen to be listening that I assume what you're doing is taking us through this diagram from your slide show?
BB: Yes.
JD: Yes.
HS: Right. We should just point out to folks that that is available on the CREN website for this broadcast, so you could kind of follow along while -- is this Brian?
BB: Yes, it is.
HS: Okay, while Brian explains this to us.
JB: Yes, and just to tell you where it's at, it's under the Resources and where it has the link that says The CyberCash Transaction Flow. The first one of those is the flow from the customer to CyberCash that Brian is going through. Okay, great.
BB: Back on?
HS: Yep.
JB: Back on.
HS: Back to the thought.
BB: We're taking the information from the web form, along with the credit card number and expiration date. We capture all of that, just as you would typically capture information from a web form into a database. Once that information is captured, we are adding some additional configuration information that identifies the transaction as belonging to a particular merchant. That little bundle of information gets encrypted and sent to CyberCash.
HS: It gets encrypted how? How's that done?
BB: Through some encryption libraries that CyberCash -- that we've installed based on CyberCash's software.
HS: Okay, so you didn't have to develop that yourself? CyberCash just gave you these encryption algorithms. They gave you actually some software just to do this.
BB: That's correct. A very small footprint of software. It's basically an encryption library and a decryption library. So the encrypted bundle goes to CyberCash, CyberCash unbundles it, updates their transaction database and uses a gateway to get out into the same banking network that a credit card transaction that would be swiped, for example, uses to authenticate the funds or authorize the funds.
JB: Interesting!
HS: So from your side, this is strictly a web operation. You don't even have to know about this other network.
BB: No, that's correct. That's correct. I don't know -- the only thing I can tell you about that is that basically if the transaction gets into this network, it's going to the issuing bank of the credit card holder to authorize the funds.
HS: One question. When I saw this diagram, I wondered about it. I realized it was going out over the same network -- is that sometimes when I go to buy something in a store, it takes forever for me to get approval.
BB: That's correct.
HS: Do you get real delays here? What's happening to the user?
BB: The user is typically being presented with "The browser is still retrieving document" page.
JD: How long does that usually take, Brian?
BB: CyberCash will typically tell you it's about a 20-second turnaround time.
HS: Okay, so it's using exactly the same process as you're standing in line in some store and you've just bought something with a credit card.
BB: Exactly, yes.
HS: Okay.
BB: So basically, when it gets into this banking network loop and gets to the issuing bank of the cardholder, that transaction is either going to get authorized or denied. It comes back out of the banking network with that additional information, specifically the message about the transaction, and follows the loop back -- back through CyberCash where the transaction gets updated, re-encrypted and sent back to us where we now use CyberCash's decryption libraries to decrypt it.
And what we're looking for is the content of that message that got sent back from the banking network. Based on that content -- it's either going to say Failed or Successful -- we post the appropriate receipt page or denied service page back to the customer.
HS: Okay, if it's approved, then what happens? I mean, we went through this whole loop just to make sure that people could really pay for this and that they had the right credit card number and the whole thing. What happens now?
BB: In terms of how you get your money, if we're following that same path, these transactions are happening real-time and they're being captured at CyberCash for a nightly -- it's a batch process. So what we're really completing in that real time is the authorization itself. On a nightly basis, ELAN will come in and say, "Give me all those transactions that you authorized today," batch them all up and then capture the funds.
HS: Okay, but my other question, though, is, I'm this department selling tickets. Somebody just bought some tickets from me. I have to send those folks the tickets. What are you doing to let me, the department, know that I have to actually send some merchandise to somebody?
JD: We do a variety of things. It's a very good question and it's one of the more technical aspects of this is how do you do merchant messaging? We do very simple things where we send an e-mail to the merchant. We've got a website that does reporting on transactions that they can take advantage of, and we've also done some fairly sophisticated integration into their back office systems where we are -- at the same time we're updating our transaction database, we're also updating theirs.
HS: Obviously, you said you sold a half a million CD's in six months. Obviously, you didn't send e-mail.
JD: No, that was the back office integration!
HS: Right. So you actually have access to some kind of database. So in that case, I have some database or I have some system running off of that tells me what I have to do. Somehow you've captured this person's billing address and things like that, mailing address.
JD: That's correct.
HS: So I know where to mail these things to.
JD: That's correct. And we will -- obviously, the most important thing is we will tell you, regardless if it's a failure or success. You want to operate on the successful ones.
HS: Okay. One thing that happens with credit card transactions is sometimes people are unhappy with the merchandise and refuse to pay, or they're unhappy with the merchandise and they want to return it or something. How is that handled in your e-commerce thing?
BB: Well, e-commerce can be tricky that way because -- and mostly your merchant service providers will tell you this -- is that you don't have much of a leg to stand on in terms of people denying that they either received the product or that they didn't authorize the payment. So we sometimes get what's called a charge-back request. And you can contest that and you can provide as much documentation as you want to about the transaction, but without a signature, it's somewhat difficult to not have them take their money back.
So what we try to tell our merchants is, as much as possible state your refund policy, state your return policy on the web page. You've got a better leg to stand on at that point.
HS: And what kind of return policies? I actually read, I went to one of your merchant storefronts -- I believe the one that sells software -- and I think I saw something that said, "Software is not returnable."
JD: That's basically true, Howard. Now, in that particular system, as Brian mentioned, we integrate with the back office processing pretty tightly because it's a large volume operation. And it's one of the tougher ones because it does require that we ship some physical product.
And in this case, we have direct links to the UPS system, we have a computer and printers that are associated with the UPS system in our warehouse, and so that as a product is sold, a label is printed out there and we have staff who put it on the appropriate package and make it ready for UPS to pick it up. They, then, proceed to provide to our customers -- either students or staff who may have purchased these products -- the ability to track that particular shipment from the time it is ordered through the time it's actually delivered to someone's door. And they, UPS, of course, typically collects a signature if we ask them to do that, and so we have some evidence there as to shipping.
HS: Because you know there's no -- a student can't come back and say, "I never got my copy of Office 2000."
JD: Out of the tens of thousands that we've sold, I think we've had two or three people who've come back with that, and when we've gone back to the UPS records, it's turned out that someone -- typically a roommate -- has signed for this software and forgot to give it to the person to whom it was addressed.
JB: Jack, we were actually going to ask about one of the more, what you would consider your success stories in this e-commerce project that you've set up. Is this one of them?
JD: This is certainly one of them. It accounts for about a quarter of the total volume that we've done in our e-commerce infrastructure so far. And this is the system that distributes software for which we've purchased site licenses. And it distributes the media for that software to students and to departments, not only of the UW Madison campus, but the other 25 UW campuses and to people on 16 of the Wisconsin Technical College System campuses.
JB: That sounds like a lot of people. You're really talking about all of higher education in the state of Wisconsin, it sounds like.
JD: All of the public higher education, that's correct. And that amounts to about 250,000 students and about 50,000 people working in departments. So it's about 300,000 people who are eligible to participate in this in one direction or another.
JB: Have you been surprised at the volume that you've been handling in this project?
JD: Well, we anticipated that we'd have a large volume, especially early in the project, since we'd negotiated site licenses that in effect allowed us to provide the media to students and to departments at the cost only of distribution and copying of the media.
HS: The cost is unbelievably low! I looked at the cost and I was trying to think of how I could pretend that I was at University of Wisconsin.
JB: You need a digital certificate, Howard!
JD: And it happens, yes, we do have authentication built in to assure that it is only the eligible people who receive packages of the software.
HS: Right, I'll have to get to know one of them.
JD: But yes, this has been a tremendous success story. We shipped some two or three thousand packages of software the first day that the site was open and as you've indicated, we shipped 36 tons of it in the first six months of the operation.
HS: For folks who are listening who don't quite understand how cheap this is, if I could just read one thing off your site here. This says, "All prices include UPS Shipping," so shipping's included in this. And for 30 dollars, you can get Office 2000 Professional -- which is the wonderful version -- plus FrontPage 2000 plus PhotoDraw 2000 plus Office 2000 Interactive Training, all those things for $30, including shipping. I assume they don't pay sales tax, either. Why would they ever do that?
JB: Well, given that it's a university, they're okay, right?
JD: Any appropriate sales tax is included in that cost.
JB: Ah, okay!
HS: So I am not surprised that anybody who could read would order one of these things who is eligible.
JD: Note that the only people eligible to buy under this license (and it is one that we negotiated for about eight months with the particular vendor involved) are the students who benefit from it. This is not available to the public or other people in the environment, so it's specifically targeted --
HS: What about to departments, faculty and staff?
JD: We don't sell under that license to faculty or staff. We're not site licensed for their personal purchases of the software. However, departmental purchases for business reasons are covered, and for departments, we sell in ten-packs at an even lower price. Typically, I think it's $65 for a ten-pack of that same Office 2000 set of software. And for staff in departments that purchase it, they're allowed by the license to take a copy home and use it at home as long as they continue to be employed by the university.
And so we're very careful to notify people of what the terms of the contract are, what the terms of the license is, and before we allow them to access a copy of the media.
JB: Well, actually that commenting about who's eligible for that brings us to a question that had been -- that we received two or three days ago, Jack. Howard, do you want to ask that question?
HS: Sure. That is a question from Rick Miller, that one?
JB: Um-hum, yeah.
HS: Okay. Rick Miller says, "At Colorado State University, we are just starting to put together an e-commerce policy for the campus. Where can we find what other universities have drafted for policies? And what factors go into making a good e-commerce policy?
JD: That's an interesting question. I'm not sure what one would say in an e-commerce policy. The way I view it, we're doing commerce, and whatever policies apply to commerce apply to e-commerce. So if a department is authorized to sell manuscripts, if the department is authorized to host conferences and therefore to sell registrations, if the athletic department is authorized to sell athletic tickets, they can sell them by e-commerce as well as over the counter or any other way they want.
JB: You know, I think your response is really telling, Jack, because in many respects, we don't need to have special policies for e-commerce if we have the policies in place for just the regular commerce piece.
JB: We did get another question in -- and let me invite everyone who's listening to go ahead and send in some questions now. We do have a question from Mark Renner at the University Northern Iowa -- not too far from you, actually, Jack.
JD: That's right.
JB: And he's asking if Wisconsin allows students to pay tuition online as yet.
JD: That's an excellent question! We do have some courses that are offered for distance education where registration is taken over the web, and we're working with the folks in Extension who offer these courses to allow students who are registering to make payment for those courses as well.
But that doesn't pertain to our general payment of tuition for on-campus courses, and the reason is that the university in general does not allow the use of any credit cards for that purpose because of the cost involved to the university. With that particular contract right now, which I think is typical of an institution our size, we pay about two percent of the gross revenue to the credit card company. This is not e-commerce, this is a credit card even if it's over the counter. And that's just too large an amount in the opinion of the Treasurer's office, the Business Services folks, for the reduction in transaction costs from the labor standpoint or convenience and so forth from the standpoint of the students and their parents.
So we don't allow that at this point in time.
HS: Yeah, I think we'd like to talk about actually all the costs involved, but I'd like to mention something to Mark Renner. I mean, I don't know what the cost of tuition is at University of Northern Iowa, but tuition, room and board here at Princeton is $32,000 or so a year, not something that I could charge on my credit card. You mentioned the two percent cost. But what are the other costs involved here? What, for example, does DOIT get out of this thing?
JD: Okay, Brian can run through what the charges are that we ask a particular departmental merchant to pay. Well, let me just run through it here.
There's a set of costs that are charged by the credit card processing outfit, which in our case is $109 one-time setup. They have a $22 per month per merchant maintenance fee. They charge 30 cents a transaction and 2.1% of the sale.
Now, in addition to that, for our services, we add $150 setup fee for helping people walk through the process. We charge 50 cents per successful transaction and we have a $65 per month charge for the merchant. And that -- we're a self-supporting operation, so that covers our full cost of doing this from the standpoint of the original investment in developing the site and the service to the day-to-day operational costs as well as Brian's, the cost of having Brian deal with these customers and help them get started.
HS: When did you decide to do this?
JD: We decided to do this almost two years ago. It was in 1998. Brian and his manager came to me and asked for some money to get started in this project and it sounded interesting, so we funded it. They did their first sale, I believe, in December of 1998. And they started off, I think, simple in terms of trying to satisfy the needs of a particular customer or two or three and it's grown and become more robust, I think, ever since then.
JB: I think it would be good to just describe, like, the three or four components of your e-commerce server, Jack. I mean, just how do you get started and how much money does it take to get started to provide the kind of service you're providing to the department/merchants.
JD: The investment that we made amounted to something less than $40,000 in total. Most of that was for staff time -- Brian's time to work on this project and to understand the technology, discover the banking relationships that were involved, work with CyberCash, make the software work. We employed initially (and I think we may still do that) a used server that had been outgrown by some other application, and so the cost of the server was fairly modest and the cost of the software that we needed to purchase for that server were quite small, in a $2,000 range. So the bulk of the cost was simply the staff time to go about setting it up.
JB: Maybe you could just share the types of software that is residing on the server in support of this, because it's more than one application that comes together to build this e-commerce server, right?
BB: That's correct. This is Brian.
JB: Hi, Brian!
BB: I'm back.
JB: Are you back? That's good. Do you want to -- I think that one thing we haven't mentioned that we had talked about earlier was the role that the Oracle plays, the software that you have on the server, the role that that plays.
BB: Right, that is a critical role. And our current technical environment is that we are running the web server -- the secure web server -- with a Verisign digital certificate on an RS 6000. As our web server software, we're using Netscape Suite Spot Server. In terms of capturing the information that comes from our web forms and putting it into a database, we're using Perl CGI currently with DBI/DBD -- just interfaces between Perl and the Oracle database. And then we're using an Oracle database on the back end to capture all the information that comes from the web form into a transactional table.
JB: Okay. That's good, and there's more detail on those actually on the site, if people want to come back to that.
And let me just remind folks again that now's a really good time to go ahead and send in some questions while we go ahead and ask --
JD: And we won't get to them!
JB: And we may or may not get to it, right, but go ahead, send them in. And let's see.
I think we were going to have a follow-up question, Brian, on the various components that you have. Oh, yes, I remember. Some of that software came directly from one of the vendors, right?
BB: That's correct. As Howard mentioned earlier, there was a very small piece of software that comes from CyberCash that's basically the encryption and decryption libraries. And that's available for free from CyberCash, so really our only investment in software was to get the digital certificate to SSL-enable our web server.
JB: Okay, good.
HS: You said you only accepted MasterCard and Visa. Could you tell us why you don't accept everybody? I mean, some folks, when I mention this to before, they said, "Oh, we know they're not going to accept American Express because they charge too much."
BB: That is, it's twofold. First of all, there's no reason why we couldn't technically accept different types of credit cards. There are other merchant service providers besides ELAN (who deals exclusively with MasterCard and Visa) that the department is certainly able to go and negotiate a contract with.
In terms of CyberCash, they will accept those different credit cards and we know how to send the transaction through correctly so that CyberCash can accept them. The reason that we don't push the Discover Card or American Express, for example, is that it does require the department to get additional merchant IDs to support hose.
HS: So the department needs a different merchant ID for each different credit card?
BB: That's correct.
HS: And isn't this something that ELAN will just give them? I mean, they actually have to talk to the credit card company? I'm not sure who they have to talk to.
BB: They have to provide -- they have to talk to the equivalent of ELAN, and it might be American Express specifically for that instance. But they have to talk to a service provider to get that merchant ID.
JD: One of the reasons that we haven't done that at this point, Howard, is that the demand is relatively small for that. We've had -- of the 30 or 40 thousand transactions we've had recently, we've had just a small handful of folks who've contacted us and say, "Gee, I'd really rather you, you know, handled Discover Card or American Express." Most people have a Visa card or Master Charge and given that those are the two we accept, they seem to be pretty happy with that.
HS: Are there situations where you have merchants who are doing this kind of online transaction and people are unhappy about putting their credit cards online and things like that? I mean, do these departments then have any other way to do this? By going into e-commerce, have they made it so they can no longer do transactions any other way?
JD: Typically not. First of all, most people seem to be pretty comfortable about putting their credit card into a situation like this. I mean, after all, we hand it to a person at a restaurant whom we don't know also. So that's not a huge issue.
We do offer, in the case of our software sales storefront, for example, we offer the students who don't have any credit card the option of paying by check -- simply printing out the order form and attaching a check and we'll do the verification using the electronic system when the check arrives here. And that's used by some small percentage of students, and so there is an option, at least. We certainly don't want to lock people out who don't have easy access to a credit card.
HS: Right, but you're saying it's just a very, very small number.
BB: Right.
HS: Does the university do anything special to help students get credit cards?
JD: No, not at University of Wisconsin Madison.
HS: When you talked about your merchants, your merchants -- are they all university departments? Are there student groups or people outside the university that are merchants?
JD: Typically, since we're operating through the university, the typical merchant is a university department. Some student groups who register with the university become a part of the infrastructure, in effect, and receive some funding from the university, I imagine, would be able to make use of this infrastructure. But not private firms outside the university, for sure.
HS: Do you think you're done doing what you're doing? I mean, you have a system up, it's running. Are there improvements or changes that you're planning to make to it right now to finish doing what you're doing?
BB: I would say that yes, certainly there are. We've got some definite things. First of all, we'd like to get more merchants, obviously.
HS: How are you doing that?
BB: What's that?
HS: How are you going out and getting more merchants?
BB: It's becoming more known that we provide this service. Word of mouth has been very good. And we are starting to advertise, now that we've stabilized and have gotten a base of successes behind us. We're more comfortable going out and marketing the service.
HS: If I were a new merchant, how quickly could I get up on your system?
BB: If you didn't have to worry about a merchant ID, we could probably have you up in about five hours. Merchant ID is what slows you down.
JD: If you're already selling over the counter with a credit card or by mail with a credit card, we'll have you up by tomorrow afternoon.
JB: It really does sound like it's once you've got the basic process in place, it sounds like it's really easy to move forward with new people, Jack.
JD: I'd like to add a couple of things to what Brian said about the future. Certainly, we want more merchants, but I think other alternative forms of electronic payments ought to come into play and the possibility of direct charging checking accounts seems to be one thing --
HS: You mean debit cards?
JD: Well, it's something like a debit card, I would imagine, but it's something that we'd like to explore, at least. I don't know the possibilities that exist. We certainly want to, intend to develop our technical environment. I don't think that we have the last word in the technology here. We have something that works and it's pretty straightforward, but new things will come along every year, I'm sure.
JB: I do have one other comment that came in that maybe would be good to address and that is that we've talked about the various types of software that really focused -- that are residing on the server. What about, is there additional Unix expertise and people that are needed to support this, either getting started or running and operating it?
BB: I would say definitely that there are, that's a definite requirement. Obviously, in a CGI environment, you're going to need somebody who's got a good knowledge of the Unix environment, knows how to use CGI's, knows how to use a database back end off of a web. And then somebody who knows the banking network. That's the minimum requirement.
JB: Aha! Okay. So you really have quite the team that you have, then, at Wisconsin that is running this project. How many people does that take, then, to do it? It's more than you, Brian, right?
BB: That's correct. But actually, I've got a couple of guys who work for me who do the storefront creation, and I've got just an excellent programmer who does most of the CGI and the integration.
BB: We also have the end-user computing operational group that handles the day-to-day operations of the servers and the setups and assuring that we have adequate backups and the like. So --
JB: So you link into that whole system, then.
JD: All parts of our organization, of course, in this project like all projects.
JB: You mentioned the storefronts, and I think that when we start looking at the one storefront example that you provided, Jack, we found that you start seeing that there's really lots of work to be done in terms of setting up a large storefront. Did you have some special tools to do that?
JD: Let me just talk about the storefront rather than the tools right now.
JB: Okay.
JD: That storefront for selling software had to deal with a specific set of contractual language and license terms and so forth, and we wanted to be very careful that we abided by all the license terms for the different vendors that had the site licenses.
And so there are some 1,800 web pages supporting that application for 42 different campuses where we refer a person who is ordering from another campus besides Madison to the help desk on that campus. We provide customized screens that have the logo of that campus and so forth all customized along with frequently-asked questions. Again, customized in most cases to the particular campus environment the student is calling from. So that can get very complex if you want to do that.
HS: There are 1,800? I mean, I don't think I looked at four of them!
JD: That's smart, Howard.
HS: There are 1,800 web pages out there?
JD: Yes.
BB: Yeah, we should mention also that the storefront creation, if you wanted to make it as simple as possible, it could be as simple as that web form, in which case you wouldn't need much more of a tool than a text editor.
What we're finding, though, is that a storefront is much more than just that final "I'm going to pay now." It's all of the customer service, the customer support, the empowerment of the customer to track their orders. That's where it becomes a much bigger project.
JD: I mean, the key for this is really to provide good customer self-service -- the immediate response, the as-nearly-as-possible immediate delivery of the product in as smooth a way as possible. And that's really the advantage of e-commerce.
HS: When somebody does have a problem, who do they complain to?
JD: The websites do have feedback mechanisms built into them, so they can complain directly to the merchant involved, especially if it's a problem with whatever has been purchased.
HS: And that's sort of what you're trying to do, you're trying to make it the merchant's responsibility.
JD: Yes, that's right.
HS: Somebody claims, you know, I got tickets for the wrong seats or something like that. They discuss with the merchant.
JD: Absolutely.
HS: They're not blaming all this on you.
BB: The merchant does!
No, that's correct. Our role is more of just the centralized mechanism that they can take advantage of to do that, but it's what they're selling. It's their product.
HS: A lot more people are using these little palm-top things. Is there anything special you have to do to make this stuff work on palm-tops, or is that all behind the scenes?
BB: I guess the only thing that technically comes to mind is that the browser would have to support the SSL protocol. Other than that, I guess there might be issues of scalability and scaling down and being able to see the order form on the Palm Pilot.
HS: But you haven't really tried to do that or face that?
JD: No, we haven't.
BB: For all I know, it could have happened.
JB: Okay.
HS: But that's one of the things that you might see in the future with more and more people using those things?
HS: Are there any other things that you can see coming in the way of e-commerce? I mean, is there something down the road that is going to change what e-commerce has done in any way that you can see?
JD: Somehow, we would like to see that some of the more major transactions of the institution with our customers -- with students and their parents and so forth -- can be automated so they're made more convenient, but without imposing the huge costs today that credit cards would impose on paying tuition.
HS: Yeah, the two percent coming off $30,000.
JD: So clearly that's something that we would like to address, but there's not a good way to address it yet.
HS: Even the two percent, isn't that lower than a lot of people get? Is that some kind of special negotiated rate?
BB: Yes, we've taken advantage of the state of Wisconsin to have negotiated that contract.
JD: I believe the contracts are at different levels, depending on the volume of business that you do with that service provider.
HS: Okay, so 36 tons of software, that's kind of high volume.
JD: We thought it was! We have a --
JB: It's weighty, at any rate!
JD: We have an excellent group of folks that handle the distribution, the logistics of receiving the software by the semi-truckload and distributing it so that effectively within a half a business day, every order is out on a UPS truck. And in many cases around the state of Wisconsin, deliveries for orders that are made today are delivered outside Madison tomorrow morning. And that is really super service. We've gotten numerous comments from folks around the state on that service.
HS: I'm just used to thinking of software in terms of megabytes or even terabytes, but not in terms of tons.
JD: What we do is do electronic distribution, and we have the capability of doing that to folks who have a high speed line and we have a mechanism for testing whether you have a high speed line for that particular product, the size product you have. But most of the products are large enough that it would be many hours to download them.
HS: Oh, sure, you wouldn't want to download Office 2000 over a slow modem.
JD: Or even a fast modem!
JB: So that's just another thing that's still in our future.
JB: Well, as we start wrapping up for today, Jack and Brian, do you have any particular -- if someone were to come to you and say, "Gee, how do I get started?" do you have any particular piece of advice that you'd like to leave folks with?
JD: I would sure suggest that people start doing it, take a small customer, particularly someone who's providing a service that doesn't require physical distribution -- like the conference registration -- and go through the steps and figure it out. I think as Brian has indicated, yes, it takes some time. But it's certainly possible and it's just a matter of doing the work.
And once you've done it once, I think setting up the infrastructure to help different departments do essentially the same thing becomes a piece of cake. The cookie cutter works.
BB: Yep. I would probably add to that, to certainly explore what relationships your Business Services or Treasurer's offices already have. Chances are very good that there's already something in place, that some departments on campus are taking credit cards right now, be it over the phone or through a swipe mechanism. And if that's in place, you can take advantage of that to do e-commerce.
JB: Okay, so start small and leverage existing relationships, then.
JD: Right.
BB: Right.
HS: I know we're out of time, but if I could sneak one more question --
JB: I was wondering if you were going to do that, Howard.
HS: Something that we never touched on, and I know it's late to turn on a new topic, so I know you'll be brief. But I just wondered if the library, the university library was one of your merchants? And if it wasn't, it seems like a really good possibility for an e-commerce merchant. Are you doing anything with the library?
BB: We've actually had a few overtures from them. We're not doing anything directly with them right now, but we've had a few overtures that they would like to enable a document delivery service via e-commerce.
JB: That sounds like a great idea.
BB: I think it's a great idea as well.
JB: And listen, Howard, I thought you were just going to ask the other question that just came in that we didn't touch on but was very close to when we started talking about storefronts and tools.
HS: Oh, that was Craig's question! That wasn't my question!
JB: Oh, right, that's somebody else's question, right! Well, anyway, here we go, just very quickly, Jack and Brian, it asks, "Do you create your own storefronts or are they provided by a vendor?"
BB: Currently we are doing our own. Either we are allowing the department to create their own and then linking into our centralized service, or we do our own.
I guess if I had to add something that we might consider down the road is some sort of storefront creation software that we would host as well. But currently, we're doing it by ourselves.
JB: Okay, but that's an option that both you and others might look at in the future, then?
BB: That's correct.
JB: Okay, great. Howard, what about you? Do you have any other final questions?
HS: No, but I'd like to make a comment here. I think that we've covered, I think, just one corner of this whole issue on e-commerce. There's lots of other corners to cover, so I think that for folks who are listening, if you have lots of interest in other aspects of this thing, let us know and we'll consider putting together another TechTalk on the subject. I know that it's impossible in an hour to really cover the whole breadth of this very interesting subject.
JB: I'm really glad you mentioned that, Howard, because I was going to ask, too, as we started looking at this area. It's just a very rich area with many dimensions. And that if people have other websites, URL's that they would suggest that we add to the event page, in the meantime, they're to go ahead and send them in to our expert@cren.net and also they could vote for having more of this topic by sending notes in to the expert@cren.net.
Okay, also let me just ask you all to set aside time on your calendar for two weeks from today when we're going to have a session that actually I've been trying to get on the program now for almost a year and a half and we finally do. It's on Calendaring Systems and it is called "What We Know and What We Don't Know." Our guest experts will be Paul Hill and Robert Mahoney from MIT.
Howard, did you have something else right there that you wanted to say?
HS: No, I was just thinking about how much I don't know about calendaring systems which we'll be doing two weeks from now.
JB: It's a tough one and people did want to do it for a long time because they said, "There's so much we don't know." So we decided to at least have a conversation about it.
HS: Obviously, it'll be easy to come up with questions because just about any question will be something I don't know.
JB: Well, there you go! All right, good. Well, I hope that you will all plan on joining us then.
And also we want to thank all the institutions who do support the TechTalks. And also many thanks again to IBM's Global Education Group for sponsoring today's TechTalk. Thanks also to everyone else who helped make this even possible today: to our guest experts, Jack Duwe and Brian Busby; to our technology anchor, Howard Strauss; to Terry Calhoun, event page producer; to David Smith and Patty Gaul of CREN; to Julia O'Brien, Jason Russell, Gayle Terkeurth and the whole support team at the Merit Network; to Susie Berneis who transcribes these audio files; to Laurel Erickson, transcript editor and indexer; and finally, a thanks to all of you for being here. You were here because it's time.
Thanks, all, and 'bye, Jack and Brian and Howard.
JD: Bye-bye.
HS: Bye, Jack, bye, Brian. Bye, Judith.
JB: Thanks again. Bye-bye now.
