This repository has been archived by the owner. It is now read-only.

change model to fit Stripe #3324

Closed
chadwhitacre opened this Issue Apr 10, 2015 · 23 comments

Comments

Projects
None yet
4 participants
@chadwhitacre
Contributor

chadwhitacre commented Apr 10, 2015

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 chadwhitacre added this to the Balanced shutdown milestone Apr 10, 2015

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 10, 2015

Contributor

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.

Contributor

chadwhitacre commented Apr 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@seanlinsley

seanlinsley Apr 10, 2015

Contributor

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.

Contributor

seanlinsley commented Apr 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 10, 2015

Contributor

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").

Contributor

chadwhitacre commented Apr 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 10, 2015

Contributor

Does Patreon have a minimum charge?

Contributor

chadwhitacre commented Apr 10, 2015

Does Patreon have a minimum charge?

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre
Contributor

chadwhitacre commented Apr 10, 2015

@seanlinsley

This comment has been minimized.

Show comment
Hide comment
@seanlinsley

seanlinsley Apr 10, 2015

Contributor

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.

Contributor

seanlinsley commented Apr 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 10, 2015

Contributor

@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.

Contributor

chadwhitacre commented Apr 10, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@seanlinsley

seanlinsley Apr 10, 2015

Contributor

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.

Contributor

seanlinsley commented Apr 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 10, 2015

Contributor

@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?

Contributor

chadwhitacre commented Apr 10, 2015

@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

This comment has been minimized.

Show comment
Hide comment
@bkrausz

bkrausz Apr 10, 2015

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.

bkrausz commented Apr 10, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 11, 2015

Contributor

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

Contributor

chadwhitacre commented Apr 11, 2015

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

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 11, 2015

Contributor

@bkrausz Possibly relevant: gratipay/inside.gratipay.com#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.

Contributor

chadwhitacre commented Apr 11, 2015

@bkrausz Possibly relevant: gratipay/inside.gratipay.com#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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 11, 2015

Contributor

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:

#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. :-)

Contributor

chadwhitacre commented Apr 11, 2015

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:

#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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 13, 2015

Contributor

From #3245 (comment):

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?

Contributor

chadwhitacre commented Apr 13, 2015

From #3245 (comment):

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

This comment has been minimized.

Show comment
Hide comment
@bkrausz

bkrausz Apr 14, 2015

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 commented Apr 14, 2015

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

This comment has been minimized.

Show comment
Hide comment
@bkrausz

bkrausz Apr 15, 2015

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.

bkrausz commented Apr 15, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 15, 2015

Contributor

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.

Contributor

chadwhitacre commented Apr 15, 2015

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 chadwhitacre referenced this issue Apr 21, 2015

Closed

pivot #180

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Apr 22, 2015

Contributor

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

Contributor

chadwhitacre commented Apr 22, 2015

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

@bkrausz

This comment has been minimized.

Show comment
Hide comment
@bkrausz

bkrausz Jul 1, 2015

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.

bkrausz commented Jul 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@rohitpaulk

rohitpaulk Jul 1, 2015

Contributor

@bkrausz - There's some context over at #67 (comment) and #67 (comment) :)

Contributor

rohitpaulk commented Jul 1, 2015

@bkrausz - There's some context over at #67 (comment) and #67 (comment) :)

@bkrausz

This comment has been minimized.

Show comment
Hide comment
@bkrausz

bkrausz Jul 1, 2015

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.

bkrausz commented Jul 1, 2015

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

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jul 9, 2015

Contributor

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! :-)

Contributor

chadwhitacre commented Jul 9, 2015

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! :-)

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.