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

> 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

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
[3]: https://usa.visa.com/Forms/merchant-surcharge-notification-form.html

Patrick "P. J." McDermott:  http://www.pehjota.net/
Lead Developer, ProteanOS:  http://www.proteanos.com/
Founder and CEO, Libiquity: http://www.libiquity.com/

Attachment: pgpeUbuSnBwyK.pgp
Description: OpenPGP digital signature

Discuss mailing list

Reply via email to