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!

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

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

[vgurgov]

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