Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism
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 match
Re: [Snowdrift-discuss] [Snowdrift-team] modifying donations to feed into the mechanism
[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 fee
