

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.<p>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.<p>2) I could split each transaction into two parts, with my cut going into my account and the rest going directly to the user.<p>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.<p>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!<p>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...](http://www.braintreepaymentsolutions.com/blog/high-risk-mechant-
account-third-party-payments-aggregation) More information about payments and
risk: [http://www.braintreepaymentsolutions.com/services/new-to-
pay...](http://www.braintreepaymentsolutions.com/services/new-to-payments)

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

~~~
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!

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

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

