Ecommerce in Second Life

hello,

We havea client who wants us to be build an ecommerce system inside second life in which the user will not use the website at all. Registration and purchasing all has to be done in SL.

Does anyone have experience with this? Would it be possible capturing information like location and name (via the chat or other options) and connect that with the website after which orders are processed?

Hope anyone can help me

Thanks

Certainly it's possible. But as usual, one of the hardest steps is taking vaguely stated requirements and turning them into a set of well-defined functional requirements. Obviously
llHTTPRequest will come into play.

You can probably get more detailed answers by presenting more specific problems to solve.

Perfectly possible, if you would like I can get you in contact with someone who can build the system for you, encryption and all.

thank you all for answering my question. A problems we face is the following:

On the website of our client people will have to fill in their location on basis of which the costs of the delivery will be calculated. This can be different for brazil thsn for china for example.

This now had to be done completely inside SL where the buyer will get the price in Linden Dollars. On the website you would use a preselected scroll bar to choose your country.

In Second Life, how would it be possible to capture this specific info, then ket it connect with their databse and get the price back in Linden Dollars? In other words how do you let theit databse know which location it is. We are thinking of capturing the information in SL by ways of chat.

Any suggestions?

I'd have it prompt the user for the name of their country, or the standard shorthand for that country ( Theres an "official" list somwhere ) like CA, US, BR, NZ, ect. If its not on the list, ask them to re-enter, or to choose "Other." If its other, have it ask for contact details, send the information thats already complete, and have someone in-world get back to them.

This is possible, but it raises an important question about usability.

Somewhere along the line, somebody decided that this all had to be done within SL. It seems obvious that the difference in features, and the resulting difference in usability, really wasn't studied before making this decision. And while there could be some strategic marketing decision or other business motivation for wanting to do it all within SL, it seems possible that someone said "it will be easier if it could all be done within SL, instead of making users go back and forth between SL and a web browser."

If that's a significant part of the motivation, it's clearly wrong, and you need to rethink the decision about doing it all in SL. If not, then you at least need to report back that while this stuff is functionally doable, it risks creating a user experience that will be much worse than simply linking people to a web page.

thank you all for answering.

@kidd, how do you know it decreases usasbility perse? If people can handle it by the chatfunction in SL it might be even more convenient?

Do you know of any examples where it already has been done?

If you are selling real-life products, then using SL will decrease usability.

I'd say 99% SL users are familiar with the web and e-commerce sites (in fact they have to be, in order to sign up for SL), so they'll buy from a website. On the other hand, most non-SL users will find it a _real_ pain to have to download and install SL just to buy from you.

Also, using the chat function to specify real world information opens up a major privacy hole.

SL is funny. Part of the marketing hype is all about the commerce going on inside it, yet it's bereft of most of the tools one would need to really do real commerce. It's a bit surprising, given that SL emerged at a time when e-commerce was quite established, but perhaps it's more a reflection of its gaming-type software background, dunno.

In my mind, three of the many requirements required to do e-commerce are security (some might stop there and say security, security, security, but I'll just pretend that the word security there is bold with a squiggle under it).... security, a database structure, and a way of collecting and validating the data that you're collecting. (There are of course many more requirements one might add to a top 5 or top 10 must have list.)

I'm just researching the security aspect now, so I won't speak to that.

We have no way to store data in SL (not really, not on any kind of it's really happening folks, basis.) So while SL might be the interface, we have to be tied into a bigger-iron backend that can store the data.

And there is no such thing as forms, in which you can control the data or present choices to the user in an easy fashion. While presenting a choice to a user via a menu controls the spelling of their response to you, it isn't very usuable for this beyond what colour would you like? Can you imagine presenting a choice of countries to a user via an SL blue menu , 7 countries at a time (allowing 2 buttons for forward and back in the list.) Unless you cheated and put United States and United Kingdom at the very start of the menu, you could kiss any yank or British customers good bye -- they'd get carpal tunnel syndrome long before they got to the U's :} grin.

But I've had an idea on how to collect data. It's not a very good one, and there are a zillion caveats that would one would have take into account. But I'm tossing this out just as grist for the mill.

You know config cards?
Text: Off
Second Owner Name: Larry Leary

etc.

kk

User clicks somewhere to get a notecard to fill in. They fill it in, typing stuff after the "enter param here: " in the notecard lines. [1]

They then drop it into a bin that accepts inventory via llAllowInventoryDrop, using ctrl- drag and drop (they of course have to be told somehow in advance how to do this, and we cross our fingers and hope for the best about their fine motor skills so that the notecard doesn't end up in the potted fern beside the bin.)

Upon inventory change, we process the notecard. Read it and parse it. Validate it a bit here -- such as, this line is missing, please fill it in and redrop, etc. Then fire it off to the bigger iron off world via llHTTPRequest (others more knowledgeable on this will advise about https requests and HTTP_VERIFY_CERT; I'm just starting researching this today which is how I found this thread). You could also email it, and have an agent in the database at the other end trigger upon incoming email and parse it out.. but the llHTTPRequest might be a tidge more secure than email.

So we got the data in the RL database somehow. We parse it, and validate it there further. Here, with access to RL coding abilities and data tables, we could validate a zip code. If it isn't right, http response or email a response back in world saying "you said you're in the US but that isn't a valid zip code by any stretch of the imagination.. pls verify and redrop the notecard..." etc...

Have run out of time now, have to end here.


[1] What can you collect this way? Well, would I collect credit card numbers this way? My spidey sense tells me I wouldn't touch that with a 10 foot pole. Address info? Well, less confidential given that any telephone directory will have it, but people will still freak if someone is able to find out what street they are on -- never mind that a quick flip through a phone book which has been in everyone's homes for decades on end will do the same. Sigh. So but yeah, prolly address, but not credit card. No idea how you'd do the credit card thing. Maybe it would be okay, dunno?

Or, do we have to bother with credit card at all? If a person has his/her SL account tied to a credit card, and wants to buy something for say 40 bucks US, you could just buy 10,000 L and then pay the 10,000 Lindens for it, and you're done, and the whole freakish security nightmare around credit card numbers in SL becomes taken care of by Linden Labs (and, as an added bonus, their problem if something goes terribly wrong .... grin)