I had always just assumed that when you funded an account it was charged at the time. I guess I hadn't considered other possibilities. I'm not sure I know enough to actually make a decision on this, and think some professional help would be useful.
On Fri, May 6, 2016 at 6:55 PM, Bryan Richter <br...@snowdrift.coop> wrote: > [moving to discuss list] > > On Fri, May 06, 2016 at 12:57:41PM -0700, Aaron Wolf wrote: > > On 05/06/2016 12:10 PM, Bryan Richter wrote: > > > On Fri, May 06, 2016 at 11:31:52AM -0700, Aaron Wolf wrote: > > >> <snip> > > >> > > >> In short, I read your comments above as though you have assumed we are > > >> holding money. We cannot make that assumption at this time, except for > > >> the MVP stage where we are the destination project ourselves anyway. > > >> > > >> Given the need to work through these issues and get further legal and > > >> accounting professional assistance, my feeling is that this > interaction > > >> of actual payments is not the next step. I want to see everything > > >> working with fake money first to know that everything else is in > place… > > > > > > It is correct that I assumed we're holding money. But it's incorrect > > > to assume that I believe we'll be holding other people's money. > > > > > > But I think I'm being too hasty. Whatever mechanism we choose now will > > > be very hard to adjust later. > > > > > > Here's the situation: I don't think that having fake money first is > > > feasible. We need to know the realities of working with *real* money > > > in order to build a mechanism that has any practicality at all. > > > Honestly, the "mechanism" is the easy part. > > > > > > Aaron, you've done a lot of research in this matter. What questions > > > remain? Does anything prevent us from having a plan? > > > > > > > Given a goal of building the actual long-term system (not merely the MVP > > for ourselves), i.e. not having to redo it when we start adding > > projects, we have to choose between the two transaction approaches > > described on the wiki. > > > > Both are technically feasible. > > > > In summary: > > > > 1. charge in arrears > > 2. We hold funds. > > By far, the easier technical path is holding funds. If we're going to > charge in arrears, it will be because we *really* can't charge up > front. > > [This email is really long, because I ended up doing some > hypothesizing. But the first part is pretty directly related to the > question at hand.] > > One big confounding factor for charging in arrears is aggregating > charges and payouts. I've spent some time reading through the Stripe > API and docs, and I can't find anything that hints at such a thing. > So, that's a big technical challenge, because it involves technology > we don't control. :) Without that strategy, we're stuck doing lots of > micropayments. > > Another confounding factor is dealing with declines. Does a patron > with a recently-declined card count as a patron? If not, do we > recalculate the payout on the fly? What about all the patrons who > already paid at the higher rate? > > Also, just keeping track of "you paid but really you haven't yet" will > add complexity. Technically feasible, yes, but more complex, too. What > happens when they pull out after two months, without ever having paid > anything? Do they stop counting for all the other patrons who matched > them? Retroactively? But some patrons will have already paid... > > Finally, as a patron, it's already uncomfortable to give up control of > how much I donate to a project — but it's uniformly worse to give up > control of when and how much my card gets charged. (Kickstarter and > Gratipay have none of these problems.) I would like to know to what > degree this impacts a person's decision to join up. I am told it > certainly shrinks the likelihood of large, "institutional" patrons. > > So, while almost anything is truly "technically feasible", there is > one case that is certainly a LOT easier. For that reason, I'm still > inclined to use it, especially at first, when it's just us on the > platform. > > # A TRANSACTION FEE SCENARIO > > Relatedly, I wanted to see how much difference in transaction fee > there was between up-front or arrears accounting. So I made some > formulas (generally useful) and plugged them into one particular > scenario. This is probably a lesser concern, but still interesting. > > Some things to consider: > > - The number of patrons will be at least three orders of magnitude > larger than the number of projects, assuming a successful platform. > > - Charging up front doubles all transaction percentage fees, assuming > we use the same method for both top-ups and payouts. However, it > results in fewer transactions, decreasing the flat fee. > > tl;dr: In at least one scenario (below), up-front accounting results > in lower fees overall. > > ## Transaction fee formulas > > For the up-front case, let's say each patron tops up every three > months. Over a year, that means the number of transactions is > 4*numPatrons + 12*numProjects, or just 4*numPatrons once you round off > a couple zeros. But let's go worst case, where each patron is just > topping off enough for one more month. That takes us to > > 12*numPatrons (1) > > [# tx/year, up-front] > > Assuming all money is used up, that results in a total transaction fee > of > > 12*numPatrons*0.30 + 2*0.029*∑payout (2) > > [total fee, up-front] > > using Stripe's current fees of $0.30 + 2.9% per charge. > > Likewise for arrears accounting: The number of transactions is > 12*numPatrons, in the best case where we can bend Stripe to our will. > More likely, it is 12*numPatrons*pledgesPerPatron, since each patron > will have to be charged separately for each pledge. > > 12*numPatrons (3) > > [#tx/year, arrears, Stripe letting us combine charges] > > 12*numPatrons*pledgesPerPatron (4) > > [#tx/year, arrears, today's Stripe] > > So now total fees: > > 12*numPatrons*0.30 + 0.029*∑payout (5) > > [total fee, arrears, hypothetical Stripe] > > 12*numPatrons*pledgesPerPatron*0.30 + 0.029*∑payout (6) > > [total fee, arrears, today's Stripe > > ## Scenario > > Let's say Snowdrift is working! for six projects, by which I wave my > hand and say each project is getting $4000/payout. That's 2000 patrons > per project. Let's say that each patron is pledged to three projects. > That gives us 2000*6/3 = 4000 total patrons in the system, and > 4000*6*12 = 288000 total payout. Using (2), (5), and (6), the total > transaction fees paid by the system in a year are: > > 12*4000*0.30 + 2*0.029*288000 = 31104.0 (7) > > [fees in scenario, up-front] > > or > > 12*4000*3*0.30 + 0.029*288000 = 51552.0 (8) > > [fees in scenario, arrears, today's Stripe] > > or > > 12*4000*0.30 + 0.029*288000 = 22752.0 (9) > > [fees in scenario, arrears, hypothetical Stripe] > > Suffice to say that, even paying double the percentage, using up-front > accounting can save the system money — unless we can convince Stripe > to combine charges. > > I would be interested in seeing more analyses like this. What does it > look like with just one project, which is underfunded? That is > obviously what things will look like on day one, so it would be good > to know. > > _______________________________________________ > Discuss mailing list > Discuss@lists.snowdrift.coop > https://lists.snowdrift.coop/mailman/listinfo/discuss > > -- @@@@@@@@@@@@@@@@@@@@ @ james sheldon @ http://www.jamessheldon.com @ "those who fail to reread @ are obliged to read the same story everywhere" @ -- Roland Barthes, S/Z (1970) @ voyager...@gmail.com @@@@@@@@@@@@@@@@@@@@
_______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
