If I may, I'm going to just jump in here with a mathematical solution and a legal concern.

On 2016-10-07 at 16:20, Aaron Wolf wrote: [...] > > 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. If you want the amount a project receives to be exactly equal to the amount a patron intends to donate, here's the math to determine the extra fee to add. Remember that Stripe's fee is 2.9% + $0.30, and begin with an equation that yields the final donation after fees ($0.30 less than 100%-2.9% of the payment): donation = total_payment * (1 - 0.029) - $0.30 Do some algebra, first adding $0.30 to both sides: donation + $0.30 = total_payment * (1 - 0.029) And then divide both sides by 100%-2.9% to isolate total_payment and get a formula to calculate it: donation + $0.30 total_payment = ---------------- 1 - 0.029 This is the formula to determine how much a patron must pay to donate the amount they intend. First you add in the flat 30-cent fee, then you divide that by the percentage of the transaction that will actually pass through after the 2.9% fee. And here's a demonstration to prove this, with a $100 donation: $100 + $0.30 total_payment = ------------ 1 - 0.029 total_payment = $103.30 (rounded to the nearest cent) The patron must pay $103.30. Now extract the fee to verify this: donation = $103.30 * (1 - 0.029) - $0.30 donation = $100.00 (rounded to the nearest cent) So the project receives the exact amount the patron intended to donate. And I believe the rounding at both ends (calculating the total payment and then calculating the actual donation after fees are deducted from that payment) balances out, as it did here, but there may be some donation amounts for which it doesn't quite balance out perfectly. So if you want to add on the fees, this is the math to do it (almost/usually?) exactly. But there's a bit of a legal issue here: see below. > 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). They do not, as far as I know. The fee is subtracted from the amount of the transaction, so in effect the account to which the funds are transferred is the one that pays the fee. And this makes sense when you consider the terms of use of Stripe and other payment processors, as well as card network (e.g. Visa) rules and the laws of various jurisdictions. If you add on a payment processing fee to the total someone pays, that's called a surcharge. Stripe and other payment processors say that "merchants" (i.e. anyone receiving payments through their service) "may not discriminate by card type or charge surcharges for acceptance of payment cards" [1]. Card networks like Visa allow surcharges (pursuant to a 2012/2013 legal settlement over surcharges and interchange fee fixing [2]) but require that merchants that intend to surcharge credit transactions must give advance notice to the card network and their payment acquirer [3][4]. Although this does not apply in ten US states that prohibit credit surcharges. To summarize the above paragraph, payment processors like Stripe forbid it, even though card networks allow it (as required by a court), even though some states still forbid it anyway. It's a mess. Now, if every transaction, regardless of payment method, is charged the same fee, that might not legally be considered a surcharge. It /might/ just be considered some kind of general overhead/processing fee if it doesn't discriminate by payment method. Of course, if only one payment method is accepted in the beginning, that can be hard to actually prove. Standard IANAL and TINLA disclaimers apply, and I would recommend some further research into (and/or lawyer consulting on) surcharges to see how they're defined (e.g. in state laws) and if general processing fees can be added without being considered payment surcharges. If multiple payment methods, all with the same fee, are made available at launch, that could help. Stripe may also be able to offer some insight, since Snowdrift.coop's situation is rather unique in "customers" wanting exact amounts to pass through to projects. [1]: https://stripe.com/us/legal#specific-payment-methods [2]: https://en.wikipedia.org/wiki/Payment_Card_Interchange_Fee_and_Merchant_Discount_Antitrust_Litigation [3]: https://usa.visa.com/Forms/merchant-surcharge-notification-form.html [4]: https://usa.visa.com/dam/VCOM/download/merchants/surcharge-considerations-and-requirements.pdf -- Patrick "P. J." McDermott: http://www.pehjota.net/ Lead Developer, ProteanOS: http://www.proteanos.com/ Founder and CEO, Libiquity: http://www.libiquity.com/

**
pgpeUbuSnBwyK.pgp**

*Description:* OpenPGP digital signature

_______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss