change model to fit Stripe

[chadwhitacre]

Balanced is going out of business and so far it looks like Stripe can't take us as we stand today. Could we tweak our formula to be Stripe-compatible? What might that look like?

[chadwhitacre]

I went looking at Patreon to see how they handle payments. They use Stripe!

@bkrausz Are you able to speak to how Patreon does things that enables them to use Stripe? If I support two artists on Patreon, am I charged once or twice? I can't tell from their FAQ.

[seanlinsley]

Patreon only makes one charge, but they don't hold onto a balance. It seems the fundamental issue is that Gratipay is weekly, and therefore tries to hold a balance for users to offset the costs of credit card transactions.

[chadwhitacre]

Hmmm ... that's one source of our escrow, yes. The other is on the seller side: we don't require receivers to have a withdrawal mechanism attached. We could potentially tighten up the receiver side, especially if we refocused more on project receivers instead of individual receivers (requiring a bank account adds a lot more friction to "tip your friends a quarter" than to "pay your favorite open source project").

[chadwhitacre]

Does Patreon have a minimum charge?

[chadwhitacre]

We implemented escrow for all pledges of $100 or more.

https://patreon.zendesk.com/hc/en-us/articles/203913749-Why-did-I-get-charged-immediately-Will-you-charge-me-again-

[seanlinsley]

Certainly the majority of supporters on Patreon pledge less than $100, so I wouldn't be surprised if that keeps them within Stripe's 90% guideline.

[chadwhitacre]

@seanlinsley But probably a lot of people pledge $2 per month. Are they really charged $2 every month? That'd be 36¢ (18%) in processing fees, doesn't seem right.

[seanlinsley]

That wouldn't seem right, except they charge you once for all of your pledges.

I'm supporting a number of things on Patreon (increasingly since Subbable shut down). On the first of the month I was charged once for $49.

[chadwhitacre]

@seanlinsley Yeah, but I'm saying that not everyone pledges as much as you do. What about all the people that only pledge $2/mo total?

[bkrausz]

Wanted to ACK this thread: I'm digging into two questions here: 1) What Gratipay could change about their model to allow Stripe to support them 2) The delta between Gratipay and Patreon

I'm unlikely to be able to comment on the latter given that it's about a different Stripe user, but I will to whatever extent I'm able to.

I've started digging, but I likely won't have a response until Monday.

[chadwhitacre]

Thanks @bkrausz. I'll also reach out to Patreon directly to see if they can help us identify the delta.

[chadwhitacre]

https://twitter.com/whit537/status/586690026026610688

[chadwhitacre]

@bkrausz Possibly relevant: https://github.com/gratipay/inside.gratipay.com/issues/180. ← Bigger convo about narrowing Gratipay's focus to just be about funding open-source projects, open products, and cooperatives (to the exclusion of both individuals as well as other kinds of projects). Implications of that could include requiring a bank account attached before we move money, thus reducing escrow.

[chadwhitacre]

Sent to Jack:

Following up from Twitter (hope this is still the right email?).

Gratipay (née Gittip) is trying to migrate to Stripe (because our old processor is going out of business). Stripe has told us they can't support us because of our business model. Since Gratipay is so similar to Patreon, and Patreon uses Stripe, we're trying to figure out what the difference is and what tweaks we could maybe make to get the green light from Stripe.

I've got Stripe sales talking with us on this GitHub issue:

https://github.com/gratipay/gratipay.com/issues/3324

Would it be possible to have someone from Patreon join that discussion to provide info on how Patreon uses Stripe?

Thanks for any help you can provide. Hope you're well. :-)

[chadwhitacre]

From https://github.com/gratipay/gratipay.com/issues/3245#issuecomment-91112973:

The crux of the problem is the stored value: holding funds in a balance that can then be redistributed

What if we require a functioning withdrawal mechanism in order to receive money? (We'd still have some escrow but it would be greatly reduced. We can dig further into numbers if need be.)

There are other compounding factors that would make it hard to reason around this property, for example the lack of a concrete product or service being provided.

What if we require receivers to identify a specific reason why they should receive money (e.g., for writing open-source software, running a hackerspace, etc.)?

@bkrausz Would these two changes enable Stripe to give us the green light?

[bkrausz]

We'd still have some escrow but it would be greatly reduced. We can dig further into numbers if need be.

We don't actually have API support for taking money back from a managed account's balance except in the form of refunds (this was a deliberate decision). The workaround for some kind of "stored balance" equivalent would be to use ACH-in to collect funds: there's no problem with simultaneously pulling funds into a bank account and pushing them out. The current cost here is $0.25 (though this may change slightly as we move out of beta with ACH-in).

Regarding the reason, I do think having receivers identify their cause that's being supported would help, though practically it all falls under some kind of generic donation to a non-charitably entity, so it's not materially different AFAIK.

Here's the minimum that Stripe could definitely support:

• Incoming contributions are each single charges per receiver
  • I know this is cost-prohibitive with $1 donations, @edmilliano may be able to work with you to find a pricing setup that's working (though it depends on the specific breakdown of cards coming through your platform: Eeke can tell you more).
• Funds are sent to bank accounts, not re-transmitted to other parties (see ACH-in comment above).

I'm exploring a few remaining avenues to loosen the first condition there, which I will update you on tomorrow.

[bkrausz]

Thanks for your patience while we explore the compliance concerns here. We've come to the conclusion that we would be able to support Gratipay using split charges (i.e. a single charge being paid out to multiple organizations on your platform) if:

1. You make it clear that this is intended to support actual services, even if they're provided to the community and not to the payer (for example, ongoing open source development). We cannot support people using this to just pay out individuals for arbitrary usage.
2. You cap contributions from a single payer to a single receiver at $100/wk (as opposed to the current $1,000 limit for organizations). It doesn't look like anyone currently goes above $100 anyway, correct?
3. You remain US-only for recipients for the time being.
4. As previously stated, funds are paid out directly to bank accounts, no stored balances with redistribution.

The API mechanism for doing this would be charging on the platform account with special case transfers using the source_transaction parameter. We would send you a 1099K at the end of each year for total funds processed.

I hope that works for you, please let me know if you'd like any clarification here.

[chadwhitacre]

Thanks for working with us to find a solution, @bkrausz! We already have a Stripe account, so we'll proceed with exploring implementation in more detail.

[chadwhitacre]

I have a contact at Patreon. Waiting to see what comes of it before saying more here ...

[bkrausz]

Hi @whit537 - I see you've switched over to Braintree. For the sake of closing the loop here, I'm curious why you chose them, if you wouldn't mind sharing. Unofficially, at first glance, it looks like your new model would work with Stripe. I'd love to learn where we could have better helped you out, given the compliance constraints you were working under.

[rohitpaulk]

@bkrausz - There's some context over at https://github.com/gratipay/gratipay.com/issues/67#issuecomment-93580252 and https://github.com/gratipay/gratipay.com/issues/67#issuecomment-96669913 :)

[bkrausz]

Ah yes, I did see that second comment (should have mentioned that), but missed the point about US-only being a major issue. I'm under the impression that both options would be US only, and the decision came down to the belief that we would be more strict about taking possession of payments yourselves for distribution via a 3rd party internationally. I do not (again unofficially) believe we would have been, but that's certainly a valid concern.

Please let me know if I misunderstood the situation at all.

I think the lesson here is for us to be much more transparent about the underlying decision process on what we can and cannot support. Unfortunately the payments world is full of difficult to pin down and rapidly changing gray areas, so this is not always possible, but it is something we are working to bring more clarity to.

[chadwhitacre]

For the sake of closing the loop here, I'm curious why you chose them, if you wouldn't mind sharing.

@bkrausz Thanks for circling back. Yes, we've landed on Braintree for credit card processing, with funds settling to our credit union, and PayPal MassPay for payouts. We modeled our options in terms of three tiers:

1. All-in-one "marketplace" offerings such as Stripe Connect, Braintree Marketplace, WePay, and MangoPay—drop-ins for Balanced, basically.
2. A DIY marketplace built on "plain old" credit card processing and payout vendors.
3. A DIY marketplace built on non-traditional payments companies such as Coinbase or Dwolla.

The promise of Tier 1 is simplicity, both technical and regulatory. On the one hand, we found that our model—aggregating micro-transactions on both payin and payout, with half our users outside the U.S.—was too complex for these one-size-fits-all products. We actually signed up for Braintree's Marketplace product, but they steered us into their main merchant account offering when they heard more about our model. On the other hand, since your comment that Gratipay 1.0 may have qualified as money transmission, Gratipay has developed ... shall we say ... a rather more robust understanding of our regulatory standing. ;-) As a result, the "painless compliance" proposition of the Tier 1 options no longer holds much value for us.

By the way: thank you, genuinely, for ripping off the band-aid. In my view, it's an anti-pattern of closed companies that they seem incentivized to get away with as much as possible, to adopt an adversarial relationship with regulators, let alone other companies in the marketplace. Had Gratipay not been so vocal and public, we probably could've flown under the radar for a good deal longer. I consider it a vindication of Gratipay's open company identity that our openness resulted in our having to clean up our act sooner (at least from a business scale point of view) rather than later. Openness is great for corporate hygiene! Thank you for sharing in that with us. :-)

Tier 3 was a back-pocket option. We want to be on the credit card network, because it's much larger than the alternatives.

That left us looking at Tier 2, where Braintree's standard merchant account offering is roughly comparable to Stripe's. It's interesting to hear you say that Stripe would've been open to us "taking possession of payments" for non-U.S. distribution. I guess I took your third point above at face value: "You remain US-only for recipients for the time being." In the end, Braintree's product solved our problem, and we were able to get online with them pretty easily.

I think the lesson here is for us to be much more transparent about the underlying decision process on what we can and cannot support. Unfortunately the payments world is full of difficult to pin down and rapidly changing gray areas, so this is not always possible, but it is something we are working to bring more clarity to.

Well, I'm certainly all for more transparency and clarity! :-)

For what it's worth, here's our current best attempt to communicate about our own regulatory situation.

Thanks again for working with us to find a way that Stripe could accept Gratipay, and for your and Stripe's part in catalyzing the major Gratipay 2.0 transition we've undergone over the past few months. Perhaps in the future it will make sense for us to revisit the possibility of working with Stripe ... and perhaps we'll be able to welcome Stripe back as a Gratipay customer, too! :-)