WARNING:
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.
Finally!
Need I say more than lets test?
Rock On, Adam Frisby!
Cheers
James
Hiro Protagonist
16 Oct 09 at 12:38 pm
In cases where you expect a user to make several purchases (e.g. of virtual goods), the Amazon Flexible Payments Service (FPS) might be a better fit. It offers Aggregated Payments – https://payments.amazon.com/sdui/sdui/business?sn=devfps/aggregated – which means you can combine several purchases into one transaction, and pay the transaction fee only once.
FPS has a few other benefits, such as using just one account for both large- and micro-payments (PayPal requires two accounts), and allowing postpaid payments (i.e., send a bill at the end of the month).
On the downside, Amazon’s fees are a little higher than PayPal’s.
Disclaimer: I’ve only actually used PayPal for accepting payments. But I’m considering using FPS for a future project.
Oren Hurvitz
17 Oct 09 at 9:48 am
Yep, I’ve had a look at aggregated purchases myself already – I would really like to integrate a payment module using it next; since as you said – it does make for better fees on lots of small purchases. There’s just a lot of extra info the module needs to keep track of (especially in case of sim crash), so it’d also need to integrate a reliable local database.
Adam Frisby
17 Oct 09 at 10:09 am
Instead of using this module to go through PayPal each time a transaction takes place, could it be adapted to allow for a secure way to deposit money into the game like we do in Second Life (either directly to the user or into the banker account). Then use the money ingame like we do in SL before using the module again to withdraw money out.
The reason I ask is because of the charge put on each transaction by PayPal. It might only be a few cents per time, but think about how many transactions in SL are less than say L$10 and if you have to add US$0.20 or more to each such transaction then the only group benefiting from this would be PayPal rather than the buyer/seller.
Anyways, a great start to get a secure system for payment available within OpenSim based worlds.
Friendly Harbour
18 Oct 09 at 4:02 pm
Friendly,
Yes – thats why I suggested using the microtransactions account which eats a lot less per transaction on transactions under USD$12.
Adam Frisby
18 Oct 09 at 8:05 pm
This is very interesting. I still think the web mashup type ideas with a portal for selling goods coupled with a paypal micro account etc.. would be a good idea. I always liked purchasing from a page and having it delivered in-world. Something like this with google checkout would be neat as well, although I don’t believe they do micro payments.
Where there is a will, there is always a way..
Great ideas Adam.
Tracy Welles
20 Oct 09 at 7:14 am
hi, i am having compile with
“Error 231 ‘DeepThink.PayPal.DTLPayPalModule’ does not implement interface member ‘OpenSim.Region.Framework.Interfaces.IRegionModuleBase.ReplacableInterface’ C:\opensimdev\opensim\addon-modules\dtl-paypal\DTLPayPalModule.cs 51 18 DeepThink.PayPal
Error 233 ‘OpenSim.Server.Base.ServerUtils’ does not contain a definition for ‘ParseQueryString’ C:\opensimdev\opensim\addon-modules\dtl-paypal\DTLPayPalModule.cs 272 63 DeepThink.PayPal
Error 234 ‘OpenSim.Framework.Util’ does not contain a definition for ‘FireAndForget’ C:\opensimdev\opensim\addon-modules\dtl-paypal\DTLPayPalModule.cs 354 22 DeepThink.PayPal
”
can u please help me
i am on opensim 0.6.8
Andrew
25 Oct 09 at 12:40 am
You need to be running against trunk there – the PP module was developed against what will be 0.6.9 (sorry!)
Adam Frisby
25 Oct 09 at 9:51 am
Adam,
this is a great option sounds more secure than what we can currently offer i will be testing it in my small grid +1 thank you very much and could you please post a tutorial on how to do this whether i need to just place the files in or if i have to build from source. if placing the files in that is easy enough but if having to build from source i would get a bit confused still new at all of this
TA
26 Oct 09 at 7:28 pm
Adam,
Can you give us some info on compiling the code? Anything special I need to do?
Also thanks for your work in this area! I really think that the ability to buy and sell thru a trusted system as paypal will help draw more interest to Open Sim.
Tmos
27 Oct 09 at 2:38 pm
After talking with Adam, I have created a forked git repository for the PayPal money module. It contains the latest extensions and bug fixes.
This page explains the current status of that Mod-PayPal module:
http://wiki.github.com/SnoopyPfeffer/Mod-PayPal/current-status
The repository can be found here:
http://github.com/SnoopyPfeffer/Mod-PayPal
Snoopy Pfeffer
17 Nov 09 at 10:40 am
wow! simply wow Adam! i like the straight PayPal way as opposed to the mention above about depositing money like we do with Linden lab. as soon as you start holding money, all sorts of international laws come into play and so does escrow and a massive logistic nightmare (ie, you become an international bank)
of course, PayPal fees prevent small transactions like most people are used to in Second Life. but that is a change that is easier to make than becoming a bank.
as a grid owner, I could work a system of credits, using a PayPal subscription model, for my clients rather than putting that burden on OpenSim. with a little thought, the same could be done by shop owners
this isn’t, and shouldn’t, be an attempt to be “like Second Life”
good job Adam and “holy cow!” – massive kudos! =)
Ener Hax
30 Nov 09 at 5:43 pm
While it is always good to have payment options, the difficulties and expense of using PayPal for in-world (or even web-based) purchases seems to me far greater than the leading alternative: a central “banking” repository company to serve the purpose of handling C$ / V$ / L$ transactions.
Yes, such would be held by a central company. That is why it would require a highly-professional, certified and trustworthy agency to perform such a task. I think with the potential of high profit involved, we can expect such an entity to appear over time. Surely such an agency would charge far less in fees than PayPal or Amazon– and would be directly tied in to in-world sales.
While there are as stated, certain obstacles to overcome, I have to believe such highly preferable to the difficulties and costs involved with trying to integrate expensive and cumbersome services such as PayPal or Amazon into the process.
The biggest obstacle I see at this time to any kind of OpenSim-based sales is the total lack of security for merchants. With many sim owners having “God rights” to their sims, this creates an environment ripe for plundering of anyone foolish enough to bring their product into the wrong area.
Until the issues of OpenSim security are dealt with and merchants better assured of the safety of their creations, most merchants with whom I’ve spoken have no intention of bringing their products into the OpenSim environment.
So as a merchant of several years experience, I would point out that for OpenSim to become a viable marketplace… we will need a centralized V$ banking system and security for our products. Both are large hurdles that, considering the nature of the beast, may be in reality too large to overcome.
Wayfinder
14 Dec 09 at 4:34 pm
I disagree – I think the problem is there’s a large disconnect between where merchants are now, and where they will end up — the content industry outside of SL has been fine with the concept of “royalty free” content for quite some time. I think the long term model is going to look more like Turbosquid than Second Life, especially for OpenSim.
As for a “V$” merchant – the problem simply is those currencies are fiat; and easy to skim – LL for example prints a huge chunk of money each month which is basically skimming from the virtual economy; when the economy shrinks (as it eventually will), don’t expect LL to start buying back; and you’ll end up with a serious economic problem that using real currencies avoids. I would only trust micropayments if they were done in a hard currency (or had a TOS that didn’t disclaim any fixed value.)
Adam Frisby
14 Dec 09 at 6:33 pm
Great solution, Well done Adam. Perhaps an inworld script to accrue items and tally combined purchase totals then pass the total to paypal may be of use? Rather than just one at a time? On receipt of funds sellers inventory is accessed and items transferred to buyer inworld?
Aleron
4 Jan 10 at 2:58 am