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: >>>> <snip> >>>> >>>> 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 matched > them? Retroactively? But some patrons will have already paid... > We don't keep track of "you paid but really you haven't yet", we track "this is your balance owed", which is not a strange thing to have. Again, this has to do with pre-authorization. Yes, it basically means there's a small potential amount of bad-pledges. That number will never be enough to make an important difference in the pledge costs. Think of the actual numbers. If someone is a patron to projects with thousands of supporters, (A) their impact on the cost for everyone else is still minimal but (B) their total will already be high enough to make monthly charges, so we won't have to keep a running balance. The only time we need to keep a balance for anyone more than a month is when their pledge is so low it's not worth charging and having the fee. In that situation, the number of other patrons affected is small and the differences we're talking about are pennies. > 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. > The budget we could set in the arrears approach could be a cap on the amount anyone would be charged in a given month. As we've already discussed, when someone hits their budget limit, we'd count them one last time even though they'd put in less than a full pledge. This is just an alternate variation of the zero-ing out concept. Institutional patrons will not accept an unknown budget, but if they accept our system at all, they'll be okay with this approach. Concerns about institutional patrons is a later post-MVP, post-launch issue anyway. So, everyone knows in this system that they will either have too small a balance and pay $0 this month or they will reach a point where they pay as much as their set monthly budget limit. That's adequate reliability for us and for most people, even if it's a bit different than "here's $100 in my wallet". I have spoken to *some* people who, for whatever reason, find the monthly-budget approach more expected and intuitive than the wallet approach (although I think the wallet approach is simpler, I'm just saying they are both reasonable and fine by people). > 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. > If the ease of implementation is *that* easy, we can simply do the wallet approach for us alone just so that we can push ahead. We can then decide, given more legal advice etc. whether we need to work with Stripe (or others) to do the split-charges/arrears approach. I'm fine with that idea. If legal issues were non-existent, I would clearly prefer the wallet approach. I know there are no legal issues during the initial time of just us as a project at least. The concerns I can think of are (A) whether the wallet approach will be extra work we don't otherwise need to do if we don't go that way and (B) whether presenting the wallet approach to initial users and then changing approaches for other projects is a problem from a UX perspective. > # 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. > I'm not sure that there would be fewer transactions, that depends on how much people would do one-time large deposits or one-time large payouts. We could certainly choose to set the arrears/balance-owed to a point where the number of charges is similar to what we'd see with the wallet approach. > 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 > If we did the wallet approach, the most straightforward option is to hold the payouts to projects too, and let them get fewer but larger payments. That may or may not add further legal concerns. However, consider that regardless of far more patrons than projects, there will likely be projects that only have a few patrons and thus do not have enough coming in monthly that getting a payout even makes any sense. So, for projects with few patrons (perhaps in the early part of their participation, as they slowly grow), we wouldn't do payouts every month *regardless* of the wallet vs arrears approach. The wallet approach would *require* that we hold the funds for the project until it reaches a payout worth actually sending. The arrears option would mean the same for the project, we just don' have the funds in escrow, we have to rely on the patrons following through with past obligations at the time the payout amount becomes adequate to process. > 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 fees of $0.30 + 2.9% per charge. > > Likewise for arrears accounting: The number of transactions is > 12*numPatrons, in the best case where we can bend Stripe to our will. As I said, this isn't even bending. They explicitly described to me how this works and can set us up to do it. > More likely, it is 12*numPatrons*pledgesPerPatron, since each patron > will have to be charged separately for each pledge. No. That is not necessary, it's not any likelihood at all. We simply won't do a setup where there has to be a separate charge for every patron-project pair. <snip> I can forward you the emails, but just take my word for it. We didn't even propose the combined-charges idea to Stripe. It's already what they do for Patreon. It's not a novel or hypothetical idea. It's literally just something I don't know where in any docs to point you to for how to run the API, but they can just tell us.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Discuss mailing list Discuss@lists.snowdrift.coop https://lists.snowdrift.coop/mailman/listinfo/discuss
