-
Notifications
You must be signed in to change notification settings - Fork 308
change model to fit Stripe #3324
Comments
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. |
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. |
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"). |
Does Patreon have a minimum charge? |
|
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. |
@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. |
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. |
@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? |
Wanted to ACK this thread: I'm digging into two questions here:
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. |
Thanks @bkrausz. I'll also reach out to Patreon directly to see if they can help us identify the delta. |
@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. |
Sent to Jack:
|
From #3245 (comment):
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.)
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? |
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:
I'm exploring a few remaining avenues to loosen the first condition there, which I will update you on tomorrow. |
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:
The API mechanism for doing this would be charging on the platform account with special case transfers using the I hope that works for you, please let me know if you'd like any clarification here. |
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. |
I have a contact at Patreon. Waiting to see what comes of it before saying more here ... |
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 - There's some context over at #67 (comment) and #67 (comment) :) |
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 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:
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.
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! :-) |
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?
The text was updated successfully, but these errors were encountered: