Integrated micro-donations

[John Sennesael]

I had a brief conversation with Davi about the integration of a micro donation 
system into the GNU Herds application.
Currently I am the server administrator of a project that has such a system in 
place.


Importance of the integrated donation feature:

        An integrated donation feature would enable users to deposit any given 
amount of money into a virtual account, and spread it over any number of 
projects in any amount. This makes it possible to donate small amounts without 
having the money eaten up in fees by banks of services such as PayPal.
        One could argue that it also lowers the psychological barrier of 
actually donating to a project, as no complicated procedures are required to 
donate to each separate projects. (Only have to log into PayPal or the bank 
account once, as opposed to once for each donation to each project.)

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.

        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:

(10:58) <mouser|{cbc}> regarding bank api
(10:58) <mouser|{cbc}> manually processing the cashouts is very important 
          security wise in my view
(10:58) <mouser|{cbc}> you could still automate it 99% if you wanted, but i 
          say leave a human in the loop checking each cashout
(10:58) <mouser|{cbc}> because:
(10:59) <mouser|{cbc}> 1) it is a great security step that will prevent any 
          other attack
(10:59) <mouser|{cbc}> this was a major consideration for me -- since it's 
          hard to anticipate every kind of attack
(10:59) <mouser|{cbc}> at least this way i know no money leaves the system 
          without my approval
(10:59) <mouser|{cbc}> i cant wake up one day to find bank account drained
(11:00) <mouser|{cbc}> 2) good to see exactly where money out is going
(11:00) <mouser|{cbc}> ---
(11:00) <mouser|{cbc}> though i do have to say that one of the reasons it's 
          feasible for dc is
(11:00) <mouser|{cbc}> most people's money never leaves the system
(11:00) <mouser|{cbc}> they just dont give it out to others or
(11:01) <mouser|{cbc}> those they give it to intend for it to go the site and 
          stay in
(11:01) <mouser|{cbc}> or those they give it to
(11:01) <mouser|{cbc}> are just a few small people who collect a lot of 
          donations and then cashout rarely, with big amounts
(11:01) <mouser|{cbc}> so its basically
(11:01) <mouser|{cbc}> MANY people donate -> very few cashout
(11:01) <mouser|{cbc}> if it were
(11:01) <mouser|{cbc}> MANY people donate -> MANY people cashout
(11:02) <mouser|{cbc}> then that would be too hard to do manually
(11:04) <mouser|{cbc}> one thing that helps prevent MANY -> MANY cases
(11:04) <mouser|{cbc}> is that the overhead charges
(11:04) <mouser|{cbc}> to withdraw actual money
(11:04) <mouser|{cbc}> are high enough that no one wants to cash out small 
          amounts
(11:04) <mouser|{cbc}> so in practice everyone waits quite a while before 
          cashing out
(11:04) <mouser|{cbc}> you wouldnt want to cash out 10 times for $10 each
(11:05) <mouser|{cbc}> youd pay too many fees
(11:05) <mouser|{cbc}> so you wait until you have received $100 and cash out 
          once
(11:05) <Gothi[c]|{cbc}> except, in their situation you have many people 
          donating to a particular project
(11:05) <Gothi[c]|{cbc}> so the total is almost always going to be alot
(11:05) <mouser|{cbc}> yeah but same thing holds
(11:05) <Gothi[c]|{cbc}> so it's probably safe to say that you have a 1 
          project = 1 cashout ratio
(11:05) <mouser|{cbc}> that project wouldnt want to cash out every day and eat 
          that fee
(11:05) <mouser|{cbc}> you could put limits
(11:05) <mouser|{cbc}> like 1 cashout per month max
(11:05) <mouser|{cbc}> and minimum cashout amount
(11:06) <mouser|{cbc}> dc has something like that you know
(11:06) <mouser|{cbc}> every donation coming in can be used and given out
(11:06) <mouser|{cbc}> but
(11:06) <mouser|{cbc}> cant leave system for 30 days
(11:06) <mouser|{cbc}> thats to handle refunds and fraud reversals
(11:06) <mouser|{cbc}> and in general dc says minimum $25 cashout
(11:06) <mouser|{cbc}> though those 2 things can be ignored
(11:07) <mouser|{cbc}> but the point is those also serve to reduce the 
          frequency of cashouts
(11:07) <mouser|{cbc}> but not the overall cashout amount
(11:07) <mouser|{cbc}> so you see its not hard to limit the frequency of 
          cashouts to be a level that a person can manage
(11:08) <mouser|{cbc}> you might want to look at MicroPledge
(11:08) <mouser|{cbc}> they recently stopped what they were doing for Free 
          software
(11:08) <mouser|{cbc}> but they had a more automated system setup
(11:08) <mouser|{cbc}> or at least more formal
(11:09) <mouser|{cbc}> though i think dc was still one of the first