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.

Attachment: signature.asc
Description: OpenPGP digital signature

Discuss mailing list

Reply via email to