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.

Attachment: signature.asc
Description: OpenPGP digital signature

Discuss mailing list

Reply via email to