On 10/06/2016 09:44 PM, Bryan Richter 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. > > 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). > > 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 > > 4. Charge the donation amount, but only register a 'crowdmatch' equal > to the net transaction balance. > > The goal is that the patron is still paying exactly the minimum > fee. They are simply matching a "virtual" crowd that is slightly > smaller than the "actual" crowd. > > The problem with this is that it's WAAYY confusing, and prone to > weird rounding errors converting backwards and forwards. I was > excited about this method until I realized how crazy it would be. > > 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. > > ------------- > >> 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. > > > ---- 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 > > 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. > >
If I understand right, you're just pointing out that the fee we would need to charge increases by 3% **of the fee**, not doubling the 3% fee to becoming 6%. I see no problem charging an extra 3% *of* 3%. That's fine. I get it, the fact that we'd be charged a fee *on* the *pass-on-the-fee* portion of our charge means this tiny increase, but it's it's negligible. And it's easy to explain. We basically just say that the entire epsilon is a fee we charge to pass on the Stripe fee. In practice, we're talking a donation of $100 getting charged $3.30 from stripe, and if we pass it on, we have to add 3% of $3.30 or an extra 10ยข on a $100 donation, a 0.1% extra. It's negligible. I strongly prefer option 1, just pass-on the fees. We state that the fee merely covers the Stripe fee, and no further explanation is needed unless anyone asks, in which case we can express that the tiny difference is because stripe adds a fee on our passing-on-the-fee. Think of it this way: we could just make it a 4 or 5% total fee to say that it covers the stripe fee and a tiny bit for our administrative costs. Nobody would complain about that, given not being charged both 5% platform fee *and* a Stripe fee. And any fee we take would increase the Stripe fee, that's just how it goes. Let's just add on the fee, accepting the tiny fee increase that causes. The only thing better than this would be if Stripe actually offers a mechanism to specify that the account being charged should pay the fee instead of taking it out of the funds we receive. That would be the truly correct approach and something Stripe *ought* to offer as a standard option (whether they do, I don't know).
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
