Linden Lab has just revealed a nifty feature implemented on XStreetSL, the web-based shopping site for Second Life that they acquired a year ago. Following the downtime on March 3, two things were immediately apparent: firstly, a slight tweak on the design elements allows now XStreetSL to have a “fluid” layout, getting rid of the ugly, nasty horizontal scroll bars that were a hallmark of XStreetSL from the very beginning.
The much more interesting announcement, of course, was the ability to directly use your L$ stored in your avatar’s account on XStreetSL, and vice-versa, immediately transferring L$ from XStreetSL to your avatar. It might not seem much (it had been promised since last year), but there is some dramatic magic going on beneath this apparenly simple, yet useful, feature.
Most services that have L$ transactions associated with it — and this is not just XStreetSL; think about web-based rental systems or the many audio/video streaming providers that accept payments in L$, or, of course, the alternate currency exchanges (which offer a far wider range of payment systems beyond LL’s offer of PayPal and credit cards) — have a rather difficult time in swiftly moving L$ between avatars. The main issue is that, although Second Life is by far and large the vastest digital marketplace for virtual goods in the world (yes, it beats Apple’s App Store!), it has a very primitive programming interface to deal with money transactions.
Originally, I can very well believe that LL didn’t even intend to make “money transfers” more widespread. After all, just the ability to allow an item to sell itself, or sell its contents, was more than appropriate in the very early days of the SL economy; everything else could simply be transferring L$ by paying avatars directly (or from their profiles). Looking at the protocol that implements money transfers between avatars (you can look at the code yourself and correct me if I’m wrong ), at the early days this was simply a modified Instant Message with a “special status” flagging it as a payment — IMs in SL can be used for far more interesting things than merely sending text to other avatars; inventory offers and similar things also use the IM system.
At some point in time, however, I can imagine that LSL programmers asked LL to allow them to get them an event to tell the script that some money was paid to the object, and to transfer L$ from the object’s owner to another avatar. This would allow the creation of the ubiquitous “multivendor” — a device with few prims that would display textures for different items, allowing the user to select the one they wished to buy, and pay the device to get that item delivered to inventory. The major reason for having these functions was that each item would have a different price, and a way was needed to make sure that people paid the correct amount and got a refund if they made a silly mistake.
This interface is, though, particularly primitive. There are no guarantees that you actually get the event to be fired when an avatar pays the object — which might happen on an insanely laggy sim. If the script is rendered inactive for some reason (because it crashed), someone might pay to it but the script will never detect the transaction — which will make the buyer very unhappy. Both cases are very rare these days, but there are still no guarantees that this will work all the time.
Sending money from an object to another avatar is even more tricky. It requires the avatar owning the object to specifically give the item permissions to debit from their L$ account — a very reasonable demand, to avoid scamming (imagine an item that gets attached to you and sends L$ to someone else without you knowing about it!). But this also means that if a sim gets rebooted and is in a strange state (e.g. “forgetting” about what state each and every script is in), those scripts might have resetted and now require the object owners to manually log in, give the items permission to debit again, and fix things that way. While this manual step is not taken, residents will find that their money transactions are not being delivered.
To make things even worse, if the object owner doesn’t have enough L$ in their account, this function to send L$ to someone else fails silently. Neither the owner, nor the recipient, get any warning. In fact, even if the transaction is successful, nobody gets a confirmation message. To be very honest, this is at least — ridiculous. Even the most primitive form of “wire transfers” in, uh, 1830 or so, would require an operator to manually send a confirmation back to the sender. But in the strange, anachronistic world of SL money transactions, this was never implemented. The ever-resourceful Jacek Antonelli has contributed some code to implement at least a label for the transaction, so that it shows what the payment was for. This allows people to at least catch a successful L$ transfer on their Transaction History.
Before June 2004, communication in-and-out of world was only possible with email messages; June 2004 allowed at least XML-RPC calls to be made from outside the world to in-world objects. This was what permitted things like the Gaming Open Market (a currency exchange that pre-dated LL’s LindeX) and the SL Exchange (today known as XStreetSL, which was bought by LL) to be launched. Since these require L$ transactions between avatars to be automated (and bots didn’t exist in 2004!), designing such a gateway to the L$ money transaction infrastructure required a lot of patience — and redundancy. It also introduced the concept of the in-world ATM: a device that would accept a payment from an avatar, catch the payment (most of the time) in LSL, send an email message to an external server logging the transaction, and then flag an in-world object (in the case of XStreetSL, a box containing items) to do something.
So many things can fail along this complex route… the original payment might not have been catched. The email message might never get sent by LL because their email servers might have been down or too slow. If it is sent, it might never be received. If it is received, the external server might correctly process the transaction, but flagging the in-world object via XML-RPC (or email!) might fail, because LL’s XML-RPC servers might be down or slow, or the sim where the object is might be down… or the object might have crashed and is not accepting any external messages anyway. With such a long list of points of failures, it’s actually a huge surprise how we have developed this incredible economy of micropayments with such loose foundations!
These days, at least external communications are a bit easier, thanks to the LSL HTTP interface. Although messages are seriously limited in size, and there is a cap to the amount of messages you can send and receive per minute, this at least properly implements two-way communication via HTTP to an external server with a reasonably amount of confirmation. Most modern gateway systems using ATMs or “item boxes” to allow users to “deposit” L$ or “pay L$” to make a payment (for a service, like a rental facility or leasing an audio stream) or buy an item via a website use this method. You can add some redundancy having several objects scattered across the grid — the probability that all your objects on all the sims are down simultaneously would be very, very low (unless the whole grid crashes, but, in that case, you’d not need to transfer L$ anyway ). These communications can be encrypted, too, for added security. So at least on that side things have progressed well in the past 5 years.
Even more modern generations of payment gateways use bots. Bots will at least get alerted when money comes in, and this allows the programmers to act upon it immediately — and bots, of course, are not limited to the amount of HTTP requests they make or the size of the messages sent, since they’re not really running on the sims. Real life companies, like Multibanco and PayShop in my country, process L$ sales that way (article in Portuguese only, sorry). Still, bots can crash, or might be shut out of the grid for some silly reason, so this is not a 100% safe way to implement money transactions. And, of course, they’re also harder to programme, which means that the overall solution might be more expensive to develop…
But the actual money transaction is still at the same stage as early 2004 Linden Lab developers are fondly quoted (or misquoted) as having claimed that “it’s too difficult to implement” or “people really don’t need this”, or, well, “it’s a nice idea, but our transaction system doesn’t support it, and very likely never will — so use what we have today, but caveat utilitor“.
True or false, there seems to be hope on the horizon. Somehow, as if by magic, XStreetSL is now able to process instant L$ transfers between avatars without requiring an object as an intermediate step. Now, we might exclude the case that XStreetSL is directly interfacing with the LL central databases to do that (it would be a huge security risk!). It’s far more reasonable to expect that they have developed an internal API to allow quick, easy, and safe L$ transactions which come from a “trusted site”. If that’s the case, the question is only: when will this API be released to the public?
If you have never developed an interface to a payment gateway — be it PayPal or a myriad of gateways out there — you might not realise how important this is. General-purpose payment gateways are not easy to create for Second Life’s microcurrency. But it’s child’s play to add a donation button for PayPal — and it will take an experienced programmer an hour or so to quickly set up a shopping cart using any of the most popular payment gateways out there. The real world, once it implemented easy payments on the Web — since the early days of Digital River, who at some point dealt with almost all software sales via the Web — allowed for the web-based economy to be so commonplace that we don’t think twice about it any more. eBay or Amazon.com would have never existed if they had to process payments manually!
Some analysts predict that 2010 will be the year of premium content on the Web. It seems that finally the lessons learned during the dot-com bubble — “everything is for free” (and so companies never managed to get a return on investment and catastrophically failed) — is slowly being replaced by “everything should be incredibly cheap”. Major content from reputable sources like the Wall Street Journal, the Financial Times, Medline, or the IEEE have always sported premium content — it just gets cheaper over time. The model was sort of abandoned for several years because it was not successful in extracting enough money from the readers, and advertising was seen as a better way to cover the costs. But for 2010 this might change: some people think that if content is really very, very cheap, it might be far more successful than ads. After all, ad networks (like Google AdSense) are paying less and less, even though the model is still quite worthwhile for the sites with tremendous amount of traffic.
But imagine that you’d be able to pay just a cent per month to read, say, Massively. Massively has enough viewers to make this profitable enough to pay for their journalists. The question is, would you be willing to pay for that?
And the answer, not surprisingly, is “no”. Why not? Because no matter if it’s a cent or US$100, it means registering, putting your credit card there, and get charged for it every time. Credit card gateways are not targeted for micropayments, they have too high fees; even PayPal frowns at transactions of merely a few cents (I have tried that!). And, frankly, it’s a mess to set this up — not to mention that many people don’t really go through the whole routine. It’s far easier to look for some content or information that is free than to pay for high-quality premium content that costs a cent a month, just because it’s a pain to register. And what if you don’t have a credit card or mistrust PayPal or any of the other payment gateways? Micropayments never became ubiquitous.
Except in Second Life.
Let’s face it, the whole economy of Second Life is based on micropayments, and has always been so for at least 6 years and a half. It’s not a small market — worth US$ 0.6 billion, annually. It already reaches 18 million registered users, who might not use SL much, but who have a L$ account that can be used at any time. Yes, registration is a pain; but the point is, those 18 million users have been, at some point, exposed to a micropayment-based premium content economy. A million and a half are quite familiar, on a daily basis, with that model. Tens of thousands of content suppliers — we call them creators or designers! — make a living (or part of a living at least) by providing premium content using a micropayment economy. The model works. We have proved it works
Now imagine the next step: LL announcing their “money transaction API” to the public, allowing anyone, anywhere to transfer L$ between their avatar account and any other, without fuss or mess, and with true transactions, with all checks and confirmations — just like any other payment gateway. Unlike PayPal or other payment gateways, where you have only a single source of converting your credit card balance into “electronic money” (so you have to implicitly trust the company operating the gateway), Linden Lab allows anyone to create their currency exchange (and offers two of their own, the LindeX — and XStreetSL, which also has a currency exchange with better rates and less limits than the LindeX). They just act as a L$ broker, pushing L$ from an account into another.
So giving the above example again… no, you might not go through the whole registration procedure to get your credit card billed every month for a cent, but if you already have a SL account, you might be quite willing to pay one L$ to read, say, New World Notes, the SL section of Massively, or the Alphaville Herald. You might be happy to pay L$ 1 to get the PDF for this month’s issue of the Second Style magazine. And — why not? — WSJ and FT might set up some avatars in SL, and you might also be willing to pay L$1 to get access to their articles, too. What does it hurt, if it’s just clicking a button away? L$1 is something anyone can afford — except, of course, current payment gateways which charge insane rates for micropayments. But Linden Lab doesn’t!
Current micropayment gateways all lack a user base. Lots have been started and closed as the model was shown not to be worth the trouble. I can very well believe that content producers on the Web might see 2010 as the year of premium content — they just need to look at the Apple iTunes and App Store to see how well it works financially for Apple (and, if they’re bold, they’ll see how Second Life beats Apple’s transactions) to see that the model, well implemented, actually works. The trouble is to pick, among a selection of many, which one to support. Premium content producers trying to avoid credit card payments will have to support a plethora of gateways, as their clients will not use a single source. Each will require separate contracts, agreements, and expensive transaction fees — as well as licensing costs. And, of course, each will require specific programming. I find all of this too cumbersome.
But Second Life as a micropayment gateway has far more impressive credentials. Linden Lab, after a decade of operation, is not a start-up that is here one day, gone the next. Second Life is already the largest premium content marketplace with a working microcurrency, offering billions and billions of items for sale (let’s forget if they’re prims and clothes; who cares, so long as people are willing to pay for them? After all, an MP3 file downloaded from the Web is just bits and nothing else; but prims, textures, and music are nevertheless created by artists that love to get paid for their work, even if it’s just a few cents). It has been in operation for over 6 years using this model. It’s a profitable, successful company. 18 million residents have opened an account on SL, and over a million use it very regularly.
No other micropayment gateway in existence offers similar conditions, nor has the same reputation, nor a valid business model. Second Life has it all.
So, Linden Lab, what are you waiting for?
[UPDATE: There was a stupid mistake re: the GOM, which I've corrected. Thanks, Troy!]