[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Integrated micro-donations -- Implementation
From: |
Davi Leal |
Subject: |
Re: Integrated micro-donations -- Implementation |
Date: |
Mon, 22 Dec 2008 21:27:41 +0100 |
User-agent: |
KMail/1.9.9 |
John Sennesael wrote:
> Implementation:
>
> * Establish a non-profit entity in the US, and get an EIN (obtainable
> on-line for no cost at the IRS website)
>
> * Use the EIN to register a dedicated bank account for the virtual
> currency.
The idea to establish a non-profit entity in the US, and use it to
create the GNU Herds bank account is great!
> In the project I'm currently involved with, the actual payouts are
> handled manually by the site owner. It may be possible to automate
> this through a Bank API or similar method, however, for security we
> have been more comfortable having it reviewed and handled by a human.
>
> The site has over
> 150000 registered users, with anywhere between 200 and 500 on-line at any
> given moment. A server load of between 12 and 34 requests per second
> depending on the time of day. Not all of these users are constantly
> requesting cash-outs of course, and so far it has been no problem at all
> for one person to handle.
>
> For that particular project, most of the time it
> has been user to user donations, which get paid out via PayPal 99% of the
> time.
>
> Current statistics show 50 actual cash-outs per year on average.
>
> The GNU-Herds project whoever, will most likely have a different rate of
> cash-outs, as you don't have the user-to-user donations. It's more
> user-to-project donations. However project workers may decide to not
> cash-out their donations all the time, and keep them in the
> virtual-currency form, to donate on projects themselves, so you may not
> have a 1 project = 1 cash-out ratio. Yet it may be best to estimate it that
> way, when considering the workload of the person handling these cash-outs.
>
> Below is an IRC conversation with the creator of the micro-donation project
> I am currently involved in (pasted to the mailing list with permission),
> explaining some of the reasons why it is important to keep a human in the
> loop, and raises some possible solutions to reduce the workload of the
> person handling the cash-outs:
>
>
> <mouser> Regarding bank API,
>
> Manually processing the cashouts is very important
> security wise in my view.
>
> You could still automate it 99% if you wanted, but i
> say leave a human in the loop checking each cashout
> because:
>
> 1) It is a great security step that will prevent any
> other attack
>
> This was a major consideration for me -- since it's
> hard to anticipate every kind of attack
>
> At least this way i know no money leaves the system
> without my approval
>
> I cant wake up one day to find bank account drained
>
> 2) Good to see exactly where money out is going
>
> <mouser> Though i do have to say that one of the reasons it's
> feasible for donationcoders.com is most people's money
> never leaves the system
>
> They just dont give it out to others, or those they
> give it ... stay in,
>
> or those they give it to are just a few small people who
> collect a lot of donations and then cashout rarely, with
> big amounts.
>
> <mouser> So its basically,
> MANY people donate -> very few cashout
>
> <mouser> If it were,
> MANY people donate -> MANY people cashout
> then that would be too hard to do manually
>
> <mouser> One thing that helps prevent MANY -> MANY cases
> is that the overhead charges to withdraw actual money
> are high enough that no one wants to cash out small
> amounts.
>
> So in practice everyone waits quite a while before
> cashing out.
>
> <mouser> You wouldnt want to cash out 10 times for $10 each
> youd pay too many fees. So you wait until you have
> received $100 and cash out once.
>
> <Gothic> Except, in their situation you have many people
> donating to a particular project,
> so the total is almost always going to be alot.
>
> <mouser> Yeah but same thing holds.
>
> <Gothic> So it's probably safe to say that you have a
> 1 project = 1 cashout ratio
>
> <mouser> That project wouldnt want to cash out every day and
> eat that fee.
>
> You could put limits, like 1 cashout per month max,
> and minimum cashout amount.
>
> donationcoders.com has something like that you know
> every donation coming in can be used and given out,
> but cant leave system for 30 days.
>
> Thats to handle refunds and fraud reversals
> and in general donationcoders.com says minimum
> $25 cashout, though those 2 things can be ignored.
>
> But the point is those also serve to reduce the
> frequency of cashouts, but not the overall cashout amount
>
> So you see its not hard to limit the frequency of
> cashouts to be a level that a person can manage.
>
> <mouser> You might want to look at MicroPledge,
> They recently stopped what they were doing for Free Software,
> but they had a more automated system setup or at least more
> formal.
>
> Though i think donationcoders.com was still one of the first
The implementation based on manual confirmation is good. The project
will just need a first volunteer to carry out this tasks.