[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.
signature.asc
Description: Digital signature
_______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
