What is being described below is dealing in real currency – you owe it to yourself if you plan to use this, to understand how it works, and perform your own risk assessment. The module is completely unsupported and unwarrantied. Use it at your own risk.

Suppose you are a user of one of the Open Grids or Hypergrid system – and you want to purchase an item, pay into an object, or otherwise transact business where a real currency transfer occurs somewhere down the line. Up until now, in all environments you are reliant on trusting a third party to act as a middleman, providing some currency-equivilent (such as say V$, L$ or whatever.).

The problems with this scenario is that that currency is at best backed by a single corporate entity (and even then they may not choose to ‘back’ it at all) – leaving you exposed in the event something goes wrong. This is compounded by the general trading size of these operators – tending to be sole-traders or small-business; the best scenario is one where neither the user nor the merchant needs to rely on a third party beyond the credit card processor.

Which is where DTL-PayPal comes in, this is a free (3-Clause BSD), open source module we’ve developed to solve this explicit problem. It uses PayPal as the backend for the transaction, and prices inworld goods in US cents. You pay me, OS$100 – and you get a bill for US$1.00 from PayPal. Every transaction needs to be confirmed by you with PayPal thus adding security into the system; in addition you don’t need to carry existing balances of ‘currency’ in order to buy items – each item can be bought individually with a seperate transaction on your Credit Card for each purchase.

The transaction is a 2 step process for the user – which is illustrated in the diagram below. Step one, you ‘negotiate’ the payment size — this is basically filling out the payment or ‘buy’ dialog that the vendor or merchant has setup already. Step two is you will be asked to visit a special webpage (which links to one at PayPal) which sets up and pays the transaction. From a users perspective you need to do nothing more.

Steps 3 and 4 occur when PayPal has confirmed the transaction for you – once the payment is confirmed (usually within 10 seconds), PayPal notifies the module, which in turn completes the transaction, finally PayPal deposits the balance in the vendors account for immediate use.

Obviously the problems with inventory server issues, vendor malfunctions, etc still exist – but to a customer PayPal does allow you to dispute charges on non-delivery grounds (however beware doing this to scam the system – the merchant gets a chance at rebuttal and it can be a complicated process)

From a vendor perspective – the main drawback to this solution is cost, PayPal will charge you roughly $0.28 plus 2.2% for a standard account in order to process the transaction. On tiny transactions (such as one for $0.50, fee would be $0.31) this can add up to a significant portion of the transaction. For users using this exclusively, I highly recommend using a PayPal MicroTransactions account which has much lower fees (but certain additional terms & conditions).

So, where can I get the code for this? It’s on my personal GitHub account (along with a few of my other goodies) – http://github.com/AdamFrisby/DTL-PayPal – I will add some further notes, first this module is currently somewhat hard coded to present a warning to the user about it’s experimental nature, remove this at your own risk. Second – OpenSim is still alpha software, you may run into other issues, so be prepared to handle them if you want to accept payments from users in it. This software has only been tested on the PayPal sandbox so far (and I recommend you do the same), however should work with the live version fine.

Enjoy.

The flexibility of this design allows us to setup currency systems that could work on a completely user-supported environment like OSGrid, rather than relying on a “walled garden” ala Second Life(R). It also could be used for multiple grids simultaneously – that is, several independent grids agree to utilize a single “bank”, and are then capable of grid to grid user transactions (most likely supported over a hypergrid link).

How does it work?

The basic method of operation is fairly simple – in both cases, the user attempts to make a payment from within the viewer (such as to another avatar, into a vendor, etc). Where the HG version differs is, it then sends the user to a website operated by the “bank” to confirm the action. The user is authenticated against the bank (via a password or other login), and is presented with the transaction details (amount, who to, etc). If the user is happy with the transaction, they approve it – and it continues to process on the server like any other normal transaction. If the user denies the transaction, then it reverses itself as if it had never been requested.

The basic process

If you examine the module we ship by default with OpenSim, the “SampleMoneyModule” – it is fairly straight forward when operating in a grid environment. When you make a payment in the region (1), the simulator can check and process the payment via the money server (2), then finally confirm the transaction with the seller (3). The biggest limitation here is that it requires trust on most parties involved – for instance if the simulator went ‘rogue’, then it would be possible to just say you made a payment, without your involvement.

This is essential for some types of payments (eg, llGiveMoney), but completely unpractical in an open environment. Eg – it allows for the ‘credit card fraud’ situation, whereby if the seller knows you exist and your account number, then it is entirely possible to debit from it without your permission. Credit cards are badly designed on this respect – there is no ‘confirmation of identity’ with the bank required. (Something there has been some work into fixing.)

By comparison, the DTL currency processor is a lot more complicated – it requires some “handshaking” between the parties before the transaction can proceed. To the user this is transparent mostly, however on the backend there is a more complicated web of data flow, of which there are six major steps.

The first step is the negotiation step – in this step, the user initiates a payment to an object or user (requests a money transfer). The simulator will contact its registered money server and ask for a link that the user can confirm their intent with (1). The user is then given that link via an IM (we’ve also made it possible to configure so that you can get that link sent to you via email from the moneyserver directly.).

The user should at this point (for anti-”phishing” purposes) check that the link they are given is sent from the money server (we strongly recommend using a recognizable domain with an SSL certificate). This link acts as a verification of intent – the money server will present the user with the details of the transaction, and ask them to login to confirm the transaction (2). Eg, see the picture below:

If the user aborts the transaction, then it simply stops all further processing – only a request for payment was made, and no funds have exchanged hands. However, if the user approves the transaction, then the money server notifies the simulator that the transaction was approved (3), this acts in a similar way to PayPal Instant Payment Notification. At this point, the simulator can execute money() events in scripts, approve an object purchase, or send notifications to buyer (5) or seller (6) that their balance has been updated. The money server also updates the sellers account balance with the new funds (4).

To the end user, the exchange can be shown in the following screenshot (the user webpage is a slightly old version now, also ignore the spelling mistake.)

Disclaimer of liability

The above does not guaruntee security – we’ve made as many steps as possible to make this usable in a public environment, however OpenSim is alpha software, and this code does not provide any kind of guaruntee of mechantability or usefulness. If you are planning on starting a virtual bank with “Real Money Trade” allowed, then you need to do a lot more work into fraud prevention and audits of this code before thinking about using it. You use this strictly at your own risk.

Final notes

This is not the final version yet, we still have work to do in that department, however you can access a alpha version on the OpenSimulator forge (Please note, there are no NAnt build files for this project yet – it’s on the TODO list, but Linux users will need to generate them if you want to use this, or get a Visual Studio user to compile for you.)

http://forge.opensimulator.org/gf/project/currency/

Credits

This was developed with funds provided by Michael Huntington – credit to him for sponsoring this project.

Development was done by DeepThink’s Shanghai development team (Korey Wan, Leon Zhu and Jed Zhu [in our plush SH office shared with SineWave]), planning was done by Korey and Leon, with the master architectural design done by yours truly. We’re planning on finishing this project up this week, once we have done so – we will be moving onto a Groups implementation, also sponsored by Michael Huntington.