Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism

[Peter Harpending]

On Tue, May 17, 2016 at 03:48:54PM -0400, Stephen Michel wrote:
> To me, it seems like arrears is the clear superior option for MVP. Holding
> funds adds significant legal complexity for what seems like a small benefit
> -- and it's something that we could transition to later anyway.
> 
> Imagine we're doing arrears, because that's the easier way. Then, because we
> think the benefits of holding are worth it, we invest in a lawyer and figure
> out a legal way to do it. It should be relatively easy to modify the
> existing system to simply pay into the arrears system from the bank account
> where we're holding funds instead of from a patron's own credit card.
> 
> So we want to offer gift cards? Same deal, or we can partner with a bank
> that already offers something like that (similar to
> http://www.walmart.com/c/kp/visa-gift-cards -- but more morally palatable
> than walmart :P).
> 
> The only disadvantage I can see with arrears that absolutely could not be
> worked around would be if no payment processor met our moral standards.
> Except -- imagine in a few years when snowdrift.coop has become wildly
> successful: maybe now it's time to start our own ethical payment processor
> (or gnu taler, or ethereum/maidsafe as discussed elsewhere, is up and
> running and stable/trusted).
> 
> BOTTOM LINE: When comparing a thing that we know will work for us on launch
> to a thing that needs further exploration, I need to pick the former.

This might be a case of "complicated for programmers" v. "complicated and
expensive for lawyers". In that case, I would vote for the option that makes
things complicated for the programmers, because it's much easier and less
expensive.

I actually have no idea how to actually go about arranging a transaction between
any of these third-party payment systems, especially from a Haskell program.

> BOTTOM LINE: When comparing a thing that we know will work for us on launch
> to a thing that needs further exploration, I need to pick the former.

All of these options need further exploration. None of them are very easy.

> 
> Other bottom line: ---

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


-- 

Peter Harpending 


signature.asc
Description: Digital signature
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism

[Stephen Michel]

To me, it seems like arrears is the clear superior option for MVP. 
Holding funds adds significant legal complexity for what seems like a 
small benefit -- and it's something that we could transition to later 
anyway.


Imagine we're doing arrears, because that's the easier way. Then, 
because we think the benefits of holding are worth it, we invest in a 
lawyer and figure out a legal way to do it. It should be relatively 
easy to modify the existing system to simply pay into the arrears 
system from the bank account where we're holding funds instead of from 
a patron's own credit card.


So we want to offer gift cards? Same deal, or we can partner with a 
bank that already offers something like that (similar to 
http://www.walmart.com/c/kp/visa-gift-cards -- but more morally 
palatable than walmart :P).


The only disadvantage I can see with arrears that absolutely could not 
be worked around would be if no payment processor met our moral 
standards. Except -- imagine in a few years when snowdrift.coop has 
become wildly successful: maybe now it's time to start our own ethical 
payment processor (or gnu taler, or ethereum/maidsafe as discussed 
elsewhere, is up and running and stable/trusted).


BOTTOM LINE: When comparing a thing that we know will work for us on 
launch to a thing that needs further exploration, I need to pick the 
former.


Other bottom line: ---
___
Discuss mailing list
Discuss@lists.snowdrift.coop
https://lists.snowdrift.coop/mailman/listinfo/discuss

Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism

[James Sheldon]

I had always just assumed that when you funded an account it was charged at
the time.  I guess I hadn't considered other possibilities.  I'm not sure I
know enough to actually make a decision on this, and think some
professional help would be useful.

On Fri, May 6, 2016 at 6:55 PM, Bryan Richter  wrote:

> [moving to discuss list]
>
> On Fri, May 06, 2016 at 12:57:41PM -0700, Aaron Wolf wrote:
> > On 05/06/2016 12:10 PM, Bryan Richter wrote:
> > > On Fri, May 06, 2016 at 11:31:52AM -0700, Aaron Wolf wrote:
> > >> 
> > >>
> > >> In short, I read your comments above as though you have assumed we are
> > >> holding money. We cannot make that assumption at this time, except for
> > >> the MVP stage where we are the destination project ourselves anyway.
> > >>
> > >> Given the need to work through these issues and get further legal and
> > >> accounting professional assistance, my feeling is that this
> interaction
> > >> of actual payments is not the next step. I want to see everything
> > >> working with fake money first to know that everything else is in
> place…
> > >
> > > It is correct that I assumed we're holding money. But it's incorrect
> > > to assume that I believe we'll be holding other people's money.
> > >
> > > But I think I'm being too hasty. Whatever mechanism we choose now will
> > > be very hard to adjust later.
> > >
> > > Here's the situation: I don't think that having fake money first is
> > > feasible. We need to know the realities of working with *real* money
> > > in order to build a mechanism that has any practicality at all.
> > > Honestly, the "mechanism" is the easy part.
> > >
> > > Aaron, you've done a lot of research in this matter. What questions
> > > remain? Does anything prevent us from having a plan?
> > >
> >
> > Given a goal of building the actual long-term system (not merely the MVP
> > for ourselves), i.e. not having to redo it when we start adding
> > projects, we have to choose between the two transaction approaches
> > described on the wiki.
> >
> > Both are technically feasible.
> >
> > In summary:
> >
> > 1. charge in arrears
> > 2. We hold funds.
>
> By far, the easier technical path is holding funds. If we're going to
> charge in arrears, it will be because we *really* can't charge up
> front.
>
> [This email is really long, because I ended up doing some
> hypothesizing. But the first part is pretty directly related to the
> question at hand.]
>
> One big confounding factor for charging in arrears is aggregating
> charges and payouts. I've spent some time reading through the Stripe
> API and docs, and I can't find anything that hints at such a thing.
> So, that's a big technical challenge, because it involves technology
> we don't control. :) Without that strategy, we're stuck doing lots of
> micropayments.
>
> Another confounding factor is dealing with declines. Does a patron
> with a recently-declined card count as a patron? If not, do we
> recalculate the payout on the fly? What about all the patrons who
> already paid at the higher rate?
>
> Also, just keeping track of "you paid but really you haven't yet" will
> add complexity. Technically feasible, yes, but more complex, too. What
> happens when they pull out after two months, without ever having paid
> anything? Do they stop counting for all the other patrons who matched
> them? Retroactively? But some patrons will have already paid...
>
> Finally, as a patron, it's already uncomfortable to give up control of
> how much I donate to a project — but it's uniformly worse to give up
> control of when and how much my card gets charged. (Kickstarter and
> Gratipay have none of these problems.) I would like to know to what
> degree this impacts a person's decision to join up. I am told it
> certainly shrinks the likelihood of large, "institutional" patrons.
>
> So, while almost anything is truly "technically feasible", there is
> one case that is certainly a LOT easier. For that reason, I'm still
> inclined to use it, especially at first, when it's just us on the
> platform.
>
> # A TRANSACTION FEE SCENARIO
>
> Relatedly, I wanted to see how much difference in transaction fee
> there was between up-front or arrears accounting. So I made some
> formulas (generally useful) and plugged them into one particular
> scenario. This is probably a lesser concern, but still interesting.
>
> Some things to consider:
>
> - The number of patrons will be at least three orders of magnitude
>   larger than the number of projects, assuming a successful platform.
>
> - Charging up front doubles all transaction percentage fees, assuming
>   we use the same method for both top-ups and payouts. However, it
>   results in fewer transactions, decreasing the flat fee.
>
> tl;dr:  In at least one scenario (below), up-front accounting results
> in lower fees overall.
>
> ## Transaction fee formulas
>
> For the up-front case, let's say each patron tops up every three
> months. Over a year, that means the number of 

Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism

[Aaron Wolf]

On 05/06/2016 06:55 PM, Bryan Richter wrote:
> [moving to discuss list]
> 
> On Fri, May 06, 2016 at 12:57:41PM -0700, Aaron Wolf wrote:
>> On 05/06/2016 12:10 PM, Bryan Richter wrote:
>>> On Fri, May 06, 2016 at 11:31:52AM -0700, Aaron Wolf wrote:
 

 In short, I read your comments above as though you have assumed we are
 holding money. We cannot make that assumption at this time, except for
 the MVP stage where we are the destination project ourselves anyway.

 Given the need to work through these issues and get further legal and
 accounting professional assistance, my feeling is that this interaction
 of actual payments is not the next step. I want to see everything
 working with fake money first to know that everything else is in place…
>>>
>>> It is correct that I assumed we're holding money. But it's incorrect
>>> to assume that I believe we'll be holding other people's money.
>>>
>>> But I think I'm being too hasty. Whatever mechanism we choose now will
>>> be very hard to adjust later.
>>>
>>> Here's the situation: I don't think that having fake money first is
>>> feasible. We need to know the realities of working with *real* money
>>> in order to build a mechanism that has any practicality at all.
>>> Honestly, the "mechanism" is the easy part.
>>>
>>> Aaron, you've done a lot of research in this matter. What questions
>>> remain? Does anything prevent us from having a plan?
>>>
>>
>> Given a goal of building the actual long-term system (not merely the MVP
>> for ourselves), i.e. not having to redo it when we start adding
>> projects, we have to choose between the two transaction approaches
>> described on the wiki.
>>
>> Both are technically feasible.
>>
>> In summary:
>>
>> 1. charge in arrears
>> 2. We hold funds.
> 
> By far, the easier technical path is holding funds. If we're going to
> charge in arrears, it will be because we *really* can't charge up
> front.
> 

I recognize how much easier and more straightforward holding funds is
technically and conceptually, but the legality and related issues need
professional guidance with serious questions about how that will be
interpreted on that side.

> [This email is really long, because I ended up doing some
> hypothesizing. But the first part is pretty directly related to the
> question at hand.]
> 
> One big confounding factor for charging in arrears is aggregating
> charges and payouts. I've spent some time reading through the Stripe
> API and docs, and I can't find anything that hints at such a thing.
> So, that's a big technical challenge, because it involves technology
> we don't control. :) Without that strategy, we're stuck doing lots of
> micropayments.
> 

Oh, that's not an issue per Stripe at all. It matters not that you can't
find the docs per se. It may not be documented well. I've already been
in touch with Stripe folks and know precisely that this is a method they
support and they can just tell us exactly what to do. Effectively,
there's some part of their API where we just tell them certain numbers
and they make the charges we request.

The "technology we don't control" is any payment processing anyway. The
only quirky part that we need that not all payment processors would
support is the ability to take a list of charges and a list of payments
with both sides adding up to the same amount and process them all. Yes,
that does make us dependent on services that can handle that. However,
we can easily determine the numbers for each patron and each project on
our side. Again, this is just a matter of asking Stripe support which
API commands to send, and they'll guide us, I've already talked to them.


> Another confounding factor is dealing with declines. Does a patron
> with a recently-declined card count as a patron? If not, do we
> recalculate the payout on the fly? What about all the patrons who
> already paid at the higher rate?
> 

The way this works in general is pre-authorization. A card gets a
pre-authorization charge for the monthly budget initially but the final
charge goes through at the end when we know what the total charge will
be. This is standard stuff, and it's how Kickstarter and others operate.
The number of cards that will have successful pre-authorization but then
end up somehow not going through at the end is nominal and can be
disregarded as an issue. We'll still count everyone, and the existence
of a few failed payments isn't any different than if someone paid us
fully and then went to their credit card company and demanded a
charge-back refund. It's just outliers and quirks of doing business.
Obviously, if someone fails to actually pay one month, they won't stay
in good standing later.

> Also, just keeping track of "you paid but really you haven't yet" will
> add complexity. Technically feasible, yes, but more complex, too. What
> happens when they pull out after two months, without ever having paid
> anything? Do they stop counting for all the other patrons who 

Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism

[Bryan Richter]

[moving to discuss list]

On Fri, May 06, 2016 at 12:57:41PM -0700, Aaron Wolf wrote:
> On 05/06/2016 12:10 PM, Bryan Richter wrote:
> > On Fri, May 06, 2016 at 11:31:52AM -0700, Aaron Wolf wrote:
> >> 
> >>
> >> In short, I read your comments above as though you have assumed we are
> >> holding money. We cannot make that assumption at this time, except for
> >> the MVP stage where we are the destination project ourselves anyway.
> >>
> >> Given the need to work through these issues and get further legal and
> >> accounting professional assistance, my feeling is that this interaction
> >> of actual payments is not the next step. I want to see everything
> >> working with fake money first to know that everything else is in place…
> > 
> > It is correct that I assumed we're holding money. But it's incorrect
> > to assume that I believe we'll be holding other people's money.
> > 
> > But I think I'm being too hasty. Whatever mechanism we choose now will
> > be very hard to adjust later.
> > 
> > Here's the situation: I don't think that having fake money first is
> > feasible. We need to know the realities of working with *real* money
> > in order to build a mechanism that has any practicality at all.
> > Honestly, the "mechanism" is the easy part.
> > 
> > Aaron, you've done a lot of research in this matter. What questions
> > remain? Does anything prevent us from having a plan?
> > 
> 
> Given a goal of building the actual long-term system (not merely the MVP
> for ourselves), i.e. not having to redo it when we start adding
> projects, we have to choose between the two transaction approaches
> described on the wiki.
> 
> Both are technically feasible.
> 
> In summary:
> 
> 1. charge in arrears
> 2. We hold funds.

By far, the easier technical path is holding funds. If we're going to
charge in arrears, it will be because we *really* can't charge up
front.

[This email is really long, because I ended up doing some
hypothesizing. But the first part is pretty directly related to the
question at hand.]

One big confounding factor for charging in arrears is aggregating
charges and payouts. I've spent some time reading through the Stripe
API and docs, and I can't find anything that hints at such a thing.
So, that's a big technical challenge, because it involves technology
we don't control. :) Without that strategy, we're stuck doing lots of
micropayments.

Another confounding factor is dealing with declines. Does a patron
with a recently-declined card count as a patron? If not, do we
recalculate the payout on the fly? What about all the patrons who
already paid at the higher rate?

Also, just keeping track of "you paid but really you haven't yet" will
add complexity. Technically feasible, yes, but more complex, too. What
happens when they pull out after two months, without ever having paid
anything? Do they stop counting for all the other patrons who matched
them? Retroactively? But some patrons will have already paid...

Finally, as a patron, it's already uncomfortable to give up control of
how much I donate to a project — but it's uniformly worse to give up
control of when and how much my card gets charged. (Kickstarter and
Gratipay have none of these problems.) I would like to know to what
degree this impacts a person's decision to join up. I am told it
certainly shrinks the likelihood of large, "institutional" patrons.

So, while almost anything is truly "technically feasible", there is
one case that is certainly a LOT easier. For that reason, I'm still
inclined to use it, especially at first, when it's just us on the
platform.

# A TRANSACTION FEE SCENARIO

Relatedly, I wanted to see how much difference in transaction fee
there was between up-front or arrears accounting. So I made some
formulas (generally useful) and plugged them into one particular
scenario. This is probably a lesser concern, but still interesting.

Some things to consider:

- The number of patrons will be at least three orders of magnitude
  larger than the number of projects, assuming a successful platform.

- Charging up front doubles all transaction percentage fees, assuming
  we use the same method for both top-ups and payouts. However, it
  results in fewer transactions, decreasing the flat fee.

tl;dr:  In at least one scenario (below), up-front accounting results
in lower fees overall.

## Transaction fee formulas

For the up-front case, let's say each patron tops up every three
months. Over a year, that means the number of transactions is
4*numPatrons + 12*numProjects, or just 4*numPatrons once you round off
a couple zeros. But let's go worst case, where each patron is just
topping off enough for one more month. That takes us to

12*numPatrons   (1)

[# tx/year, up-front]

Assuming all money is used up, that results in a total transaction fee
of

12*numPatrons*0.30 + 2*0.029*∑payout(2)

[total fee, up-front]

using Stripe's current