On Fri, Oct 7, 2016 at 12:44 AM, Bryan Richter <br...@snowdrift.coop>
wrote:
On Thu, Oct 06, 2016 at 06:46:10PM -0700, Aaron Wolf wrote:
First, the premise: As a financial system trying to get people
focused
on how public goods actually work and are actually funded, we don't
want fees hidden and absorbed. We want people to see and experience
the costs of the tools they use.
I agree with this. Sharing the responsibility for fees is good.
Besides, it would be impractical to do anything else when there are
many
projects.
Is there a reason we can't just add the fee amount to the total
that we charge everyone? That should be baked into our mechanism
calculations. The charge is: base * patrons + fee.
For clarity, we should use "crowdmatch" instead of "base * patrons".
It's the same thing for the Futurama milestone but vague when you try
to extend it to multiple projects.
--Bad--
charge: base * patrons + fee
total_charge: sum(charges)
--Better--
crowdmatch: base * patrons
total_crowdmatch: sum(crowdmatches)
total_charge: total_crowdmatch + fee
Here's the problem: Stripe calculates the fee themselves. If we try to
charge the fee upfront, we effectively increase the fee by another 3%.
(math below).
That's true, but I don't think we actually care about that. I think we
care about what % of the charge is fee. If you follow your intuition,
it says that Stripe always takes the same rate, which is a smaller % of
the whole as the whole goes up. Therefore, the larger charge (ie, when
we charge the fee up front) means a smaller % of the charge is going
towards the fee. I did some math (below) to try to prove this, but got
too tired to trust my work (I kept mixing up 1.029 and 0.029) so I'm
just going to leave it incomplete and maybe someone will care.
I see four possibilities right now.
1. Charge up front to cover the fees.
This results in the increased fee percentage just discussed.
2. Swallow the fees.
There is only one project right now: Snowdrift. All donations are
going to Snowdrift. It is actually financially feasible to just
accept the losses on the Snowdrift side as long as all remaining
money is actually going to us.
But we don't like this option, since it sets poor expectations. It
also means that the crowdmatch amount is not equal to what the
project receives.
3. Set up a second, connected Snowdrift account using Stripe Connect.
With a second account, we can "charge through the platform"[1] and
add an application fee that is equal to the processing fee. This
is
by far the cleanest mathematically. Conversely, it is the hairiest
legal option.
We will probably have to do this eventually, assuming it's even
possible. But it's a big barrier to "shut up and take my money".
[1]:
https://stripe.com/docs/connect/payments-fees#charging-through-the-platform
Charging through the platform is a little confusing to me, but I think
it means that a user's stripe history / credit card history will show
the fee and the crowdmatch separately, without increasing fees? It
would be awesome if that were the case, so the stripe/credit card
history matches what we display on the Dashboard>History page.
MY SUGGESTION:
As much as we want to set expectations, I think the most sensible
course
for the Futurama milestone is (2). It is very easy to describe what it
is doing, as well as what our eventual goals are.
I am VERY WEAKLY against (1) just for the sake of principles, as well
because I think it's slightly harder to explain than (2). That's
subjective, and I'm open to consensus overruling.
I am against (3) because it adds trickiness and delay when we just
want
to have some freakin' cash flow.
I am against (4) because it's a nightmare.
I am in favor of (1). My intuition says it has a lower fee compared to
the amount of crowdmatch.
I think the additional simplicity of (2) is so slight that it is not
worth basing our decision on (unless we hide fees entirely, which we
won't do).
Agreed on (3) and (4). Awesome as (3) would be we should not let it
block the Futurama milestone.
Side-note: if we made it possible to use Dwolla instead or other
no-fee options, this would be a non-issue for those cases.
This will happen many months from now, at best. We shouldn't think
about
it until we have more than half a dozen projects being supported.
+1
---- MATH LOL ----
---- MATH LOL ----
Here's the math for my claim that we would increase the fee by 3% if
we charge the fee upfront.
Let's call the amount we charge the patron up front "epsilon". If we
want Snowdrift's net balance to be `original + crowdmatch`, the
equation
we want is
(crowdmatch + epsilon) - fee = crowdmatch (0)
or just
epsilon = fee (1)
But since we would charge `crowdmatch + epsilon`, the fee is:
fee = 0.029 (crowdmatch + epsilon) + 30 (2)
Combining (1) and (2),
epsilon = 0.029 (crowdmatch + epsilon) + 30
--> epsilon = 0.029 crowdmatch + 0.029 epsilon + 30
--> 0.971 epsilon = 0.029 crowdmatch + 30
Now the right hand side is equal to Stripe's original fee calculation,
`0.029 crowdmatch + 30`.
0.971 epsilon = original fee
--> epsilon = 1.030 original fee
QED.
It's confusing to use (1) to refer to both formulas and possibilities,
so I'm going to refer to possibilities by letter of who absorbs the
fee, the (p)atron or (s)nowdrift.
In (0), you're missing a variable. The left crowdmatch is not actually
the same as the right crowdmatch.
crowdmatch: base * patrons
fee: amount stripe receives (duh)
income: the amount we actually receive
charge: income + fee
We're interested in what % of the charge that is fee, and how that
compares between possibilities.
fee(s) fee(p)
-------- = x * ----------- (3)
charge(s) charge(p)
Just move things around so it's easier to substitute & simplify later
fee(s) charge(p)
x = ------ * --------- (4)
fee(p) charge(s)
Figuring out what the fees and charges are. Just algebra here.
fee(p) = 0.029 * crowdmatch + 30 (5)
charge(p) = crowdmatch + fee(p)
charge(p) = 1.029 * crowdmatch + 30 (6)
charge(s) = crowdmatch (7)
In the section below, you'll notice I get the exact same answer as
Bryan above. Which makes sense, since we both calculated the same thing.
fee(s) = crowdmatch - income(s) = 0.029 * income(s) + 30
1.029*income(s) = crowdmatch - 30
income(s) = (crowdmatch - 30) / 1.029
income(s) = crowdmatch/1.029 - 30/1.029
fee(s) = crowdmatch - crowdmatch/1.029 + 30/1.029
fee(s) = (1-1/1.029)crowdmatch + 30/1.029
fee(s) = 0.29*crowdmatch + 30/1.029 (8)
__Now let's plug in (5-8) into (4). __
(1.029 * crowdmatch + 30) (0.29*crowdmatch + 30/1.029)
x = ------------------------- * ---------------------------- (9)
(crowdmatch) (0.029 * crowdmatch + 30)
Simplify a little. The trick is that 30 = 30.87 - 0.87
x = (1.029 + 30/crowdmatch) * (1 - 0.87/(.029*crowdmatch + 30) )
This is gross and does not simplify further. If you take the limit as
the crowdmatch goes to infinity, you get x converging to 1.029. This
doesn't really make sense to me, since my intuition says x should go to
1, so I'm doubting my math, so I'm just gonna drop it here and change
what I wrote above.
QEB (B for bedtime)
~Stephen
_______________________________________________
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss
