Closed chadwhitacre closed 9 years ago
Okay, this is materializing quicker than expected.
Just got off the phone with Stripe. They're (apologetically, professionally) letting me know that Gittip falls outside of what Stripe can support. I asked about option 2 above, and they're going to get back to me. But it doesn't look hopeful.
So! Plan C. Let's get that merchant account going with Braintree. At least this time we should be able to pull off a migration of user data.
Okay, so this isn't an emergency like with FeeFighters (#58). We've got a little breathing room to migrate away from Stripe, but we need to do so before we start seeing significant volume (p.s., they're going to update their marketplaces FAQ to be clearer).
Options!
I think we need to keep trying to support credit card payments, since that's so well-established. By off-loading the tax onto users we have the incentive in the right place to move to Dwolla, etc., just like gas stations of yore. :-)
I had a merchant account with Braintree for CloudFab, which was a marketplace. Expect like 3 months of paperwork.
@steveklabnik Can you operate while filling out the paperwork?
Nope.
The process is largely held back by the banks, not BrainTree. They're real skittish about marketplaces and such...
I estimate that in the best-case scenario, we've got three to six months before we outgrow Stripe.
Proposal
Your other options is Amazon Flexible Payment. They have a whole section dedicated to market place style transactions. You would set up your app as a marketplace and just take nothing off the top.
The only issue is that the recipients have to create an account for themselves in order to accept payment and it is limited to U.S. participants.
This is exactly the kind of problem I was running into when I was developing BitGifter.
Will look into Amazon, @akoumjian. Thanks (also @jacobian).
Also on the table: PayPal. I guess they have a micro-transaction offering now.
Had a phone conversation with our Braintree sales rep. FirstData doesn't underwrite marketplace accounts, period. So we're looking at a new account. His advice was to narrow the focus, i.e., explicitly target open source developers for the first phase of buildout. If and when that is proven stable we can adjust our account to expand further. Small transaction size doesn't really help. The big risk is chargebacks: Alice gives money to Bob, and then is confused when three weeks later a charge appears on her statement from GITTIP.COM GRATIPAY.COM. She complains, and we get hit with a $15 chargeback immediately, even if we work it out later: risk. I guess what they do is levy a "5% rolling reserve" for six months. I.e., you charge $1000, and (besides fees) they take $50 and put it into an escrow account, which they use in case you can't meet your chargeback obligations. After six months you start getting it back. After twelve months you're generally free and clear of that, I gather.
That said, Braintree handles some big, new marketplaces: Airbnb, Uber, and another one I don't remember. I've got the pre-screening questions (95% of the time "yes" to the pre-screening means you get the account) and it seems like it's worth a shot. I can't pretend my world-view is the same as a banker's, but it really seems that, in our model, it's clear that you're giving your money to GITTIP.COM GRATIPAY.COM. We shall see, I serpose.
It seems to me that becoming a legitimate, first-class marketplace would provide the best user experience. Paying with a credit card on a website is familiar, well-trodden, and friendly outside the US. Requiring an Amazon or a Dwolla account is an additional step. In the Dwolla case it's worth it for the cost savings. I guess Kickstarter gets away with requiring Amazon. It may even be that we get more people paying if they can use PayPal or Amazon, because of trust issues, though as @akoumjian mentions, Amazon (at least) is US-centric.
Another option that's not listed yet is google wallet/checkout. It's supported in a lot of countries and everybody who has bought an android app already has it.
Google Checkout ticketed as #187.
Closing this in view of our strong relationship with Balanced.
Reopening in view of Balanced shutting down. :-(
Talking with Stripe is #3245.
Talking with Braintree is #3287.
Another option is to partner directly with a bank. We don't get the nice APIs of Stripe or Braintree, but it may be the only way to find someone who will work with our use case. I've started building a relationship with Citizens here in town, and that's where I'd start: #3288.
Whichever route we go on this, I have to imagine that cleaning up our act is a prerequisite. Cleaning up our act means:
I really don't get how Gratipay is connected to banks. Is there a diagram of the structure somewhere?
I'd like to explore an integration with Dwolla - https://www.dwolla.com/about
@techtonik - Dwolla is ticketed as #65 and #726.
I really don't get how Gratipay is connected to banks. Is there a diagram of the structure somewhere?
@techtonik We're connected to banks via an intermediate payments vendor. This has been Balanced, but Balanced is shutting down.
Blech. We can only have one milestone at a time. :-/
I mean, that makes sense, but it means that sprint milestones and non-sprint milestones conflict.
Milestone discussion carried forward in #163.
This is an existential risk for Gratipay. If we don't have a payment processor, then we're effed. We're flipped. My current sense is that Stripe seems likely to reject us, Braintree might accept us, and Citizens is a wildcard (we just don't have enough experience at that level of abstraction; we're used to dealing with start-up-y abstractors instead of banks; but #417 is discouraging here).
If we can't find a credit card/ACH credit processor in time, then we have a few options:
Diversification is a good thing, and it is too bad that we didn't have this before, so I am for adding multiple inputs and outputs (writing issue already).
My current sense is that Stripe seems likely to reject us
In the short term I don't see a reason why we couldn't use their deprecated US-only API, it's only international payouts that are problematic.
In the short term I don't see a reason why we couldn't use their deprecated US-only API, it's only international payouts that are problematic.
If we migrate to Stripe's deprecated API, then we can be certain of facing this same existential crisis again in the future, either when they terminate the API in general, or when they ask us in particular to leave. They deprecated the API for a reason. I don't see that they state their reason, but it's not unlikely that it has to do with precisely the strictures we run afoul of with managed accounts. What's more, the short term could turn out to be very short, given that they've already asked us to leave once (see above, at https://github.com/gratipay/gratipay.com/issues/67#issuecomment-6553374). If this is truly our best option then we are in deep :hankey:.
Diversification is a good thing
Agreed. I've reopened #210.
At this point I'm feeling pretty good about Spreedly (#210). The biggest drawback I see is that they're only payouts, not payins, so they're not a complete solution for us. But for payins they seem to be a good fit for us, since our relationship with gateways is so uncertain. :-(
Review site for merchant services providers (recommended by a friend):
http://www.merchantmaverick.com/review-category/merchant-accounts/
Alright, so ... Gratipay requires four things: compliance, payins, escrow, payouts. Here's our current vendor landscape:
✝ Probably not legit, because they aren't covered by the regulatory compliance we enjoyed as a Balanced customer. See #3321 #3322 and also https://github.com/gratipay/inside.gratipay.com/issues/119.
✝✝ Also probably not legit, but we don't really store value there; we merely pass it through during payin/payout.
With Balanced going away, here's what we need to replace to maintain our current level of service:
Here's what our product looks like without Balanced:
That's not a very awesome product. :-(
Let's start with an ideal scenario:
What can we realistically get done how fast? We have 63 days.
I reached out to someone for a (soft) intro to IAFCU.
WePay (#69) and Braintree (#3287) are the remaining one-stop-shop marketplace offerings. I guess it would be even more ideal to simply drop one of those in for Balanced.
Even if we go with WePay and/or Braintree, I think we should take two steps to reduce the risk for the next time our gateway stops underwriting us for whatever reason (this is the third time now):
If we can't use WePay and/or Braintree then the only option I see is to fast-track 2 and hope for the best with companies like IAFCU and Trans-Pay ... and that seems really risky to me. :-(
If we can't partner with companies that can provide traditional credit card and bank account processing, then option 3 would be to use non-traditional options such as Coinbase and Dwolla.
Scenarios, best to worst:
Another option would be to more radically change our model so we could fit Stripe. Let's talk about that on #3324.
I'm starting to think of this whole process as a chance to clarify our product, refocus on open culture—open-source projects, open products, hackerspaces, cooperatives, etc., shifting the focus from tipping individuals to paying projects, with individuals behind the scenes splitting the money. I have in mind Braintree's advice a few years ago (above at https://github.com/gratipay/gratipay.com/issues/67#issuecomment-6566710):
[N]arrow the focus, i.e., explicitly target open source developers for the first phase of buildout. If and when that is proven stable we can adjust our account to expand further.
We got the green light from Braintree (https://github.com/gratipay/gratipay.com/issues/3287#issuecomment-93523753)!
We have a solution from Stripe! From https://github.com/gratipay/gratipay.com/issues/3324#issuecomment-93562216:
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.
This is the intention behind https://github.com/gratipay/inside.gratipay.com/issues/180.
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?
It looks like we only have two tips above $100, so we should be able to dial back to that level without too much trouble. Ironically, Stripe was the one for whom we upped the limit in the first place: https://github.com/gratipay/gratipay.com/issues/1378#issuecomment-44040763. :-)
3) You remain US-only for recipients for the time being.
Almost half of our payouts are outside the US, so this is going to be a significant obstacle for us. Let's dig in on #3287 to understand better what Braintree offers us here.
4) As previously stated, funds are paid out directly to bank accounts, no stored balances with redistribution.
Both Braintree and Stripe are requiring this. We're looking at zeroing out our escrow in #1383. It's going to be hard but at this point I think we have to do it, because both Braintree and Stripe are requiring it.
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.
This is the intention behind gratipay/inside.gratipay.com#180.
We don't need that with braintree, they haven't mentioned such a limitation.
they haven't mentioned such a limitation.
That could be because I put down "Sustainable crowdfunding for open-source projects" for "Business Description" on our application. I figured they'd have similar requirements as Stripe in this regard. I have a vague sense that other payments companies want this, too. Maybe I picked this up from Trans-pay? Anyway, we could/should scour the Braintree ToS and ask on #3287 (and/or email) to be sure, if we want to try to avoid this requirement.
That could be because I put down "Sustainable crowdfunding for open-source projects" for "Business Description" on our application. I figured they'd have similar requirements as Stripe in this regard.
Now that I think about it, I was also acting under the influence of their advice from a few years ago (above at https://github.com/gratipay/gratipay.com/issues/67#issuecomment-6566710):
His advice was to narrow the focus, i.e., explicitly target open source developers for the first phase of buildout. If and when that is proven stable we can adjust our account to expand further.
Almost half of our payouts are outside the US, so this is going to be a significant obstacle for us. Let's dig in on #3287 to understand better what Braintree offers us here.
Braintree marketplaces are also US-only for payouts.
Status report:
Not feeling warm and fuzzy. Patreon works around Stripe's US limitations in the same way we worked around Balanced's (via alternate services, PayPal and Payoneer in their case). Would Stripe let us get away with the same practice? I'm reluctant to trust that they would, but I'm also reluctant to press the point. :-(
We can't use their Marketplace product because they don't provide true escrow (https://github.com/gratipay/gratipay.com/issues/3287#issuecomment-96666583). We could potentially use a regular merchant account with them in conjunction with a separate ACH provider for payouts (e.g., #3366).
Nervous because they're small like Balanced was. They do provide true escrow, and they have better international payout support than Stripe or Braintree, but still not good enough (we couldn't pay @rohitpaulk, e.g.) [see below].
I'm currently leaning towards a tier-2 scenario, with Braintree for merchant services and Citizens for ACH. I have intro calls with lawyers starting this afternoon, I'll use those to start exploring what it would mean for us to own our own regulatory compliance.
we couldn't pay @rohitpaulk, e.g.
Unless we could? I can't tell, actually. Is IBAN enough, @rohitpaulk?
More evidence that what we were doing with Balanced was acceptable, from the MangoPay FAQ:
In order to accept payments via PayPal, you will need to implement PayPal outside of our solution and open a merchant account directly with them.
Unless we could? I can't tell, actually. Is IBAN enough, @rohitpaulk?
Yes, for India. I've been paid through Payoneer before, and IIRC they asked for my IBAN and my bank's SWIFT/BIC code.
GittipGratipay is technically a "third-party payment aggregator," which means it is a third party collecting money on behalf of someone else. Credit card companies are down on this:But of course TPPA's exist: PayPal, Etsy, Kickstarter, Flattr, etc. Somehow there has to be a way to "get it right." The above link concludes: "That is not to say that merchant accounts cannot get approved for TPP processing, it is just more difficult and the underwriting conditions will more likely include a reserve and other similar safeguards. " Do you have experience with this?
Here's Stripe's position:
Option one is Stripe Platform, and it doesn't work for us because of the high per-transaction cost of moving 8 cents at a time over the credit card network (see #58). Dwolla is basically Stripe Platform without the credit card network middleman, so adding Dwolla support (#65) would definitely mitigate the risk that we're kaiboshed by (Stripe because of) the credit card companies.
Option two sounds like what we're trying to do, so the low-hanging fruit here is to make it "very clear to any consumers that they are paying you, the marketplace, when making the transaction."