On 10/10/2016 11:29 AM, Michael Siepmann wrote: > On 10/10/2016 08:44 AM, Aaron Wolf wrote: > >> On 10/08/2016 09:58 AM, Patrick 'P. J.' McDermott wrote: >>> 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 >>> >> Right, so this is why gas stations don't charge a credit-card fee but >> instead offer a "cash discount". It's the same, but worded to avoid >> complaints from card processors. >> >> Of course, the idea that card processors and Stripe etc. have the legal >> ability to make merchants not pass on the fee explicitly in various >> cases is an unethical, corrupt, biased bit of bullshit. But it is there. >> >> In our case, we just need to word our fee something like "we take this >> fee for our services as a platform, but for reference, this fee is only >> set to the level that offsets our payment processing expenses and is not >> otherwise providing any profit to Snowdrift.coop". And in the long-run, >> we can offer a "Dwolla discount" or something like that. >> >> Of course, we'll be legally okay with no discrimination amongst >> processors during the time we have a single processor. By the time we >> add more, we'll consult with lawyers about how to best work around the >> unjust financial system. > > > Would it help to not even call it a fee, but rather something like a > "buffer" that is the same regardless of payment processor chosen, and > serves to ensure that the amount going to the project is /never less > than/ the crowdmatch. Rather than offering anything like a "Dwolla > discount" to patrons, we'd just let people know that their choice of > payment processor won't affect what they're charged, but choosing a > lower fee processor can result in a bit more of their money going to the > project(s) they're supporting - i.e. the crowdmatch plus a little > extra. If we describe it this way from the start, it will make it > simpler to add additional payment processors in future. > >

That sounds like a fine solution to me.

**
signature.asc**

*Description:* OpenPGP digital signature

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