gratipay / gratipay.com

Here lieth a pioneer in open source sustainability. RIP
https://gratipay.news/the-end-cbfba8f50981
MIT License
1.12k stars 310 forks source link

find a payments partner #67

Closed chadwhitacre closed 9 years ago

chadwhitacre commented 12 years ago

Gittip Gratipay 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:

There are a few reasons why TPPA's are considered higher risk in the credit card processing industry: 1) The merchant has reduced control over the quality and delivery of the product being sold, and 2) The merchant is being trusted to pay the third party for the money they've collected on their behalf. 3) The business that owns the merchant account is responsible for all transactions charged by that account even though a majority percentage is passed onto a third party

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:

Stripe can only transfer to one bank account; we don't support transferring to many different users or splitting transaction proceeds among different people. Marketplaces on Stripe work in one of two ways:

One option is to have the marketplace's users (so the merchants on top of the marketplace) each set up their own Stripe account. This can be done entirely online. Then you, as the marketplace owner, will need to collect the users' API keys and make transactions on their behalf with their API keys. Stripe will then transfer directly to these users' bank accounts. If you want to collect a fee on the transactions, you can charge your users with your API key using Stripe.

The other way marketplaces use Stripe is by simply collecting all their users' payments. In this scenario, Stripe will transfer to the marketplace owner's bank account. You will then need to transfer to your users using programmatic ACH transfers (most business bank accounts allow you to set this up). The caveat in this scenario is that it needs to be very clear to any consumers that they are paying you, the marketplace, when making the transaction. Additionally, in this scenario, you will be liable for any chargebacks or disputes.

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

chadwhitacre commented 12 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.

chadwhitacre commented 12 years ago

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

steveklabnik commented 12 years ago

I had a merchant account with Braintree for CloudFab, which was a marketplace. Expect like 3 months of paperwork.

chadwhitacre commented 12 years ago

@steveklabnik Can you operate while filling out the paperwork?

steveklabnik commented 12 years ago

Nope.

The process is largely held back by the banks, not BrainTree. They're real skittish about marketplaces and such...

chadwhitacre commented 12 years ago

I estimate that in the best-case scenario, we've got three to six months before we outgrow Stripe.

Proposal

akoumjian commented 12 years ago

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.

chadwhitacre commented 12 years ago

Will look into Amazon, @akoumjian. Thanks (also @jacobian).

Also on the table: PayPal. I guess they have a micro-transaction offering now.

chadwhitacre commented 12 years ago

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.

chadwhitacre commented 12 years ago

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.

dekkers commented 11 years ago

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.

chadwhitacre commented 11 years ago

Google Checkout ticketed as #187.

chadwhitacre commented 11 years ago

Closing this in view of our strong relationship with Balanced.

chadwhitacre commented 9 years ago

Reopening in view of Balanced shutting down. :-(

chadwhitacre commented 9 years ago

Talking with Stripe is #3245.

Talking with Braintree is #3287.

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

Whichever route we go on this, I have to imagine that cleaning up our act is a prerequisite. Cleaning up our act means:

techtonik commented 9 years ago

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

rohitpaulk commented 9 years ago

@techtonik - Dwolla is ticketed as #65 and #726.

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

Blech. We can only have one milestone at a time. :-/

chadwhitacre commented 9 years ago

I mean, that makes sense, but it means that sprint milestones and non-sprint milestones conflict.

chadwhitacre commented 9 years ago

Milestone discussion carried forward in #163.

chadwhitacre commented 9 years ago

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:

techtonik commented 9 years ago

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

Changaco commented 9 years ago

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.

chadwhitacre commented 9 years ago

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

chadwhitacre commented 9 years ago

Diversification is a good thing

Agreed. I've reopened #210.

chadwhitacre commented 9 years ago

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. :-(

chadwhitacre commented 9 years ago

Review site for merchant services providers (recommended by a friend):

http://www.merchantmaverick.com/review-category/merchant-accounts/

chadwhitacre commented 9 years ago

Alright, so ... Gratipay requires four things: compliance, payins, escrow, payouts. Here's our current vendor landscape:

  1. compliance—Balanced
  2. payins—Balanced (credit cards), Coinbase (bitcoin)
  3. escrow—Balanced, New Alliance✝, Ally✝, PayPal✝, Coinbase✝✝
  4. payouts—Balanced (U.S. bank accounts), Coinbase (bitcoin), PayPal

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:

  1. compliance
  2. payins—credit cards
  3. escrow
  4. payouts—U.S. bank accounts

Here's what our product looks like without Balanced:

  1. payins—Coinbase (bitcoin)
  2. escrow—New Alliance✝, Ally✝, PayPal✝, Coinbase✝✝
  3. payouts—Coinbase (bitcoin), PayPal

That's not a very awesome product. :-(

chadwhitacre commented 9 years ago

Let's start with an ideal scenario:

  1. We find a credit union that's willing to underwrite us as an MSB agent of theirs (#3322). They provide compliance (we'll probably need to do things like https://github.com/gratipay/inside.gratipay.com/issues/155 #3289 #2449) and escrow.
  2. We find a merchant services provider to provide payins (credit card), while probably revaulting our cards at Spreedly (#210) as insurance against future gateway uncertainty.
  3. We convince Trans-Pay that we're good to go (#417), and they provide bank payouts. We vault bank account details ourselves.

What can we realistically get done how fast? We have 63 days.

chadwhitacre commented 9 years ago

I reached out to someone for a (soft) intro to IAFCU.

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

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

  1. Migrate to Spreedly ASAP.
  2. Improve our compliance story via #3321 #3322 gratipay/inside.gratipay.com#155 and whatever else may come out of https://github.com/gratipay/inside.gratipay.com/issues/119.

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. :-(

chadwhitacre commented 9 years ago

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:

  1. compliance, payins (credit card), and payouts (bank account) via WePay and/or Braintree
  2. DIY compliance, payins (credit card), and payouts (bank account) via other partnerships
  3. DIY compliance, payins (non-traditional) and payouts (non-traditional) via other partnerships
chadwhitacre commented 9 years ago

Another option would be to more radically change our model so we could fit Stripe. Let's talk about that on #3324.

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

We got the green light from Braintree (https://github.com/gratipay/gratipay.com/issues/3287#issuecomment-93523753)!

https://twitter.com/Gratipay/status/588421397606707200

chadwhitacre commented 9 years ago

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.

rohitpaulk commented 9 years ago

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.

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

https://medium.com/gratipay-blog/balancedshutdown-3a9fdb32e9c6 https://twitter.com/Gratipay/status/588825910956130304

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

Status report:

Stripe (#3324)

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. :-(

Braintree (#3287)

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

MangoPay (#891)

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

chadwhitacre commented 9 years ago

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.

chadwhitacre commented 9 years ago

we couldn't pay @rohitpaulk, e.g.

Unless we could? I can't tell, actually. Is IBAN enough, @rohitpaulk?

https://docs.mangopay.com/api-references/bank-accounts/

chadwhitacre commented 9 years ago

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.

rohitpaulk commented 9 years ago

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.