Ask HN: How to do payments between users on my site?

[grasshoper]

I'm building a site where users will be paying each other, with the site taking a cut out of each transaction. I'm having some trouble deciding on how to handle payment processing and could use some advice. I think there are really two ways to handle these payments.

1) I could accept payment into my own account and credit the users on my own system. I can then pay them when they request a withdrawal.

2) I could split each transaction into two parts, with my cut going into my account and the rest going directly to the user.

The first way seems the most reasonable and seems to be the way most sites do this, but I am scared of essentially storing other people's money in my account (especially after reading stories of Paypal accounts being frozen). I am also unclear about the legal issues of doing either method.

Any tips on how to proceed? Any payment processor recommendations? I am a poor college student, so cost of setup is a major issue for me. Thanks!

Edit: the site is a marketplace, not some type of money-transferring service

[dan_manges]

The business model that you explained is a true peer to peer payment system. As you know, it's essentially what Paypal is to ebay. It's presents perhaps the highest form of risk in the payments industry. This is especially true with new businesses because there is no track record and typically very little financial stability or backing. There is a graveyard in the payments industry dedicated to peer-to-peer payment startups, including some extremely well funded and connected companies, which is why it's so hard to find any payment provider willing to accept the risk. A lot of money has chased this for a long time now. Last time I checked, even Paypal won't allow provide payment services to other peer-to-peer providers, because, as they've stated, the "excessive risk". To date we've (Braintree) not approved any true peer to peer payment method as you described above, but we do process for a lot of merchants that use an aggregation model similar to Groupon, whereby the merchant accepts payment on behalf of another merchant. It's a small but significant difference.

In terms of revenue. It's always helpful if a business already has a track record and some external funding for validation as well as some stability. That also clearly presents a catch-22. Some providers are wiling to take substantial risks: new business, peer-to-peer track record and no funding while others are only willing to consider this type of high risk businesses who have an established track record.

I would offer a friendly word of caution. All too often new companies will find a provider to approve this type of business model only to be shut down at the worst possible time. This happens because sometimes the sales rep doesn't properly explain the business model to the underwriters, the underwriters don't understand it, and/or an application gets auto approval because it's new and has low expected volumes. I'm not suggesting that there are not providers that won't approve this type of business, and I'm also not suggesting that everyone approved for this type of payments model will eventually get shut down. What I am suggesting is that we see merchants getting shut down too frequently, so I'd be cautious if I were you.

Best of luck to you.

Aggregation more fully explained: http://www.braintreepaymentsolutions.com/blog/high-risk-mech... More information about payments and risk: http://www.braintreepaymentsolutions.com/services/new-to-pay...

[patio11]

Amazon Payments was created for this use case. I would suggest thinking long and hard about doing this as a poor college student, though: this business model will complicate everything you do, and for a first business you have plenty of things to worry about without the extra complications.

[cscotta]

Strong second.

You would have a very difficult time establishing a proper merchant account as the fraud risks are incredibly high. While many might be willing to discuss it, it is unlikely that the account would be approved by the processor's sponsoring bank in the underwriting phase.

Amazon's FPS service, while far from ideal in that it requires all parties have Amazon accounts, and requires the transaction occur off-site in Amazon's payflow, is very well-suited to this use case. It's the only quick, affordable, easy to integrate service I can think of that allows for a merchant to broker transactions between two parties (while skimming a percentage).

If you push forward with this, I'd definitely recommend launching with FPS rather than plunking down a large personal guarantee with Authorize.net or Braintree.

Good luck!

[barmstrong]

I attempted something similar in the past.

Quick summary of my experience:

1. Billing credit cards is easy, paying people through an API using direct deposit is pretty hard to find

2. Lots of companies won't know what you're talking about. The ones who do will say you are an "aggregator" and high risk.

3. BrainTree payment solution is a possible exception to this. They "get it" but they also have rejected everyone I know who has applied. They rejected my app also. You need a mil in sales and a track record.

4. I finally stumbled upon AchDirect.com. They are a two-bit no-name processor in Texas, but they approved my app, and give you an API to do direct deposit. Their customer service was incompetent, documentation was sub-bar, and generally didn't seem like they knew what they were doing. But i did finally get the thing to work.

I had to write a custom ActiveMerchant plugin for AchDirect (if you want the code get in touch with me).

I think WePay is using AchDirect too (not sure).

Anyway, Amazon FPS is much simpler. But your customers experience is much worse. It confuses people because they don't think of Amazon like they do Paypal. And (at least when I tested it) there were too many screens to go through to complete a simple transaction.

Anyway, that was my experience.

[jmathai]

I pretty much agree with everything this user said. We were rejected by BrainTree as well. We didn't want to use Amazon because the user experience wouldn't have been all that great. Requiring users to go offsite and have an Amazon account was a deal breaker for us.

We did find a merchant that worked with us. Contact me via email (jaisen(at)textbookrevolt.com) and I can get you in touch with the account rep we worked with.

[dan_manges]

I'm unsure of the specifics of your business, but we (Braintree) posted above about risk assessment generally. http://news.ycombinator.com/item?id=1494102

[barmstrong]

Cool to see BrainTree participating here. Thanks!

[djb_hackernews]

Do you think the niche is big enough to support an achdirect.com competitor?

[barmstrong]

Definitely, they are sucking it up big time.

[grasshoper]

Thanks, guys! I don't know why I hadn't even seriously considered Amazon for this. FPS Marketplace seems to have all the pieces I'm looking for. It does seem to involve a few more steps than Paypal. barmstrong's point about people not thinking of Amazon as a third-party payment service also seems valid.

Thanks for pointing me to Amazon though. I'll look into it some more.

[dkuchar]

PayPal Adaptive Payments is pretty solid.

[dabeeeenster]

We used this when building http://www.jigsawbox.com and it does work pretty well. The documentation is shockingly bad, however. Really terrible.

[dkuchar]

agreed about the documentation.

[Vitaly]

The problem with the model (1) and one of the reasons its hard to find someone willing to take the risks with it is that it allows for a not that difficult to pull off money scam. essentially you sell to yourself and then you chargeback on the original payment once you received the money on the seller's side. The "easy" solution to this problem is to have a very high fee on transactions so that the average loss on chargebacks will be less then the total fees, or holding seller's money for 3 to 6 months to make sure there wont be chargeback on it. The harder much better way to solve it it so have better fraud detection and prevention, and not everyone can pull this off. you certainly can't on your own, you need someone else doing the heavy lifting.

[braindead_in]

A lot of companies follow model 1. Eg. Google Adsense, oDesk, Elance, etc. and anybody who has a affiliate program.

Also in the long run you'll have to support more than few modes of withdrawal: checks, payoneer, moneybookers etc. PayPal is still very popular and your users will eventually demand it. If you have international users then it adds another layer of complexity.

[pwim]

Is the main focus of your site transferring money between users? If not, why not just use paypal or some other 3rd party service? If it is, you are opening a whole can of worms with regards to the legality of your service. You should consult a lawyer about it, but I'm guessing you won't be able to come up with a cheap solution to the problem.

[grasshoper]

It's a marketplace, not a money-transferring service or anything like that. Thanks for reminding me to clarify that.

Paypal is definitely very easy to set up, but I keep hearing stories of accounts getting frozen. If I do opt to use it to hold the earnings of sellers, and that account got frozen, it could be disastrous. The second way would be far less risky because it would just be the site's cut frozen, but splitting up payments doesn't seem to flow well with Paypal (maybe I'm wrong about this?).

[imp]

Having your PayPal account frozen is only a problem if you don't move your money OUT of PayPal after you receive it. If you regularly transfer money into your company checking account, then you won't have any real problems. In the worst case if PayPal freezes your account then you can still mail people checks. Keeping your money in PayPal is kind of dumb anyways, since it doesn't earn interest. I've been using PayPal for two years without any problems.

[Aaronontheweb]

You're always going to be at the mercy of a third party with any e-commerce system unless you happen to be a major financial institution.

[vgurgov]

check out new paypal APIs - adptive payments and another one that allows managing accounts. more info @ www.x.com