gnuherds-app-dev
[Top][All Lists]
Advanced

[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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]