Stripe: Marketplaces
stripe.com
stripe.com
I ask because I've done both in different projects and I'm still not convinced which is better. Having all the payments come into your account means you'll definitely be dealing with more Fraud. Plus the accounting is more of a PITA in my opinion. But the user-experience is smoother and you can allow for purchases from multiple sellers (on a site like Etsy).
- If your users are "in control" of their own business -- if they handle refunds and customer service issues themselves, if they'd like to log in to their own dashboard, etc. -- I think Connect[1] makes more sense. This is what, say, Squarespace uses.
- If your sellers are providing a service to another company, and expect that the company will take care of everything (a la Lyft and Postmates), I think the transfers API is a better fit.
Does that make any sense?
Of course it depends how big your customers are, how well-educated about fraud your users are, and your own tolerance for risk, but in my experience transferring the risk liability onto your customers is a very bad idea if you can avoid it.
Even if you're not technically liable, your users will blame you and hold you responsible if they end up losing money to fraud, even more so if their online stores are hosted on your website (which is probably the case if you're referring to your product as a marketplace).
Because they are potentially much smaller than you are (if you are offering a self-service platform, this is the kind of users you'll tend to get), they are extremely sensitive to risk and they are at high risk of incurring a catastrophic (to them) loss. If that happens, leaving them to their own device will be extremely bad PR and will potentially cost you more business than if you had absorbed the loss. I was talking to a friend who works on the fraud team at Square (who use Stripe Connect), and I recall they reached this same conclusion after one of their merchants on SquareSpace was attacked by fraudsters. We don't use Stripe at Eventbrite but I can guarantee we could even never suggest passing the fraud losses onto the event organizers without losing a lot of business.
So don't imagine that by having your users register their own Stripe account you will be cleared of fraud issues (at least for buyer fraud -- merchant risk is another issue). Instead, just pick the solution that makes the most sense in terms of product and ease of accounting.
Also, because as the owner of the marketplace you have much more data than any individual merchant, you are better equipped to detect and fight fraud than they are -- if you have the capability and are able to assume the risk I would highly encourage you to do so, even if it means increasing fees for your users to cover your costs. As a nice side-effect, you'll even be able to advertise a "no fraud liability" policy for your users which may sway potential customers that were hesitant with trusting some online platform to handle their money.
Actual merchants in the marketplace are rarely affected other than the user experience. But when all the chargebacks come back to you, it severely affects the bottom-line. I also think the user-experience has improved quite a bit (with Stripe Connect, you can have users provision their own Stripe account during signup).
I would also argue, given how how "lean" many startups and MVPs are, many marketplaces are actually smaller and more at risk than the sellers they serve. Most marketplaces don't have $200M in funding and data scientists like EventBrite ;)
[1] http://techcrunch.com/2011/06/16/founder-stories-eventbrite-...
When you run a marketplace you are sensitive to risks both from the merchant and the buyer. The first kind would be what you are describing and you are right that Stripe Connect mitigates this. But the latter is not a threat to ignore either, especially with the increasing number of high profile credit card breaches. What happens is that fraudsters attack legitimate merchants by purchasing goods using stolen credentials and reselling them later for full profit.
I just saw your marketplace was a platform for photographers -- in this case you are right my point doesn't really apply to you, because photographs have little resell value so such platforms will indeed not be a big buyer fraud target. Hopefully though my advice will be relevant for other people. For some platforms losses due to buyer fraud are able to potentially dwarf those due to than merchant fraud, mostly because the latter tends to be much easier to detect: for a merchant, you have many data points to figure out if they're fraudulent; for a single purchase you only have one!
[0] https://payments.amazon.com/help/Checkout-by-Amazon/Creating...
One of the pain points for me was that funds are only available to be transferred 7-ish days after the charge is cleared, same as when Stripe would normally transfer it to the bank account of the Stripe account owner. I ended up having a table of "scheduled" transfers that would be queried each time the balance.available webhook was run. Any transfers that were scheduled 7 days prior would then be sent to Stripe. If I messed up, transfers would fail because there wouldn't be enough to cover them in the Stripe balance.
It would have been much nicer if the balance.available event could tell you which associated charges had been cleared and made available. Also, Stripe has no way to pre-fund your account to provide a buffer for possible overages.
Also, you can't turn on the Transfers API until you associate a bank account, which I don't want to do with the account I use just for development/testing.
(The 7 day transfer delay is going away.)
edit: made into a question
This is not a big deal though, the battle will end up being who can scale globally faster.
I think there's more to it than this. The cost of switching from one payments provider to another is decreasing all the time. Competition appears to have driven costs (i.e. the fee/commission per payment) down to roughly the same level for everyone. There's some room for differentiation on the product (not so much ease of set-up - which is a one-off thing - as the admin UI and featureset), quality of customer service (I know someone here in the UK who switched from Paypoint to SagePay for precisely this reason) and the accuracy of fraud detection (i.e. minimising both chargebacks due to the use of stolen cards and erroneous rejections of legit payers).
However, I think that there's a strategic competitive advantage to be gained through operational efficiency (i.e. reducing the cost per transaction to as close to zero as possible) and generating revenue from sources other than the fee/commission (for an example of this, see my blog post on how Paypal makes money on cross-currency payments: http://jackgavigan.com/2013/03/12/how-paypal-makes-money-on-... ).
I believe that our model (which removes marketplaces from the flow of funds & shields them from risk) is a better fit for some folks, but not all - there are tradeoffs. I have a ton of respect for the guys at stripe and would consider us good friends. (We were actually both in YC S09 when Stripe was called /dev/payments)
[Edit/addition: Marketplaces are an especially valuable segment for payment companies because they touch a lot of payment volume relative to their company size. i.e. a software company selling $100m of revenue is usually a relatively large & established company, but a marketplace processing $100m of GMV can be quite small.]
However, I can't seem to reproduce the issue you're seeing--could you provide a bit more context? If you change a recipient's bank account, their past transfers will still appear on their page in your Stripe dashboard and when listing transfers via the API and filtering by recipient ID.
Edit: Feel free to PM me as well :). I'm michelle@stripe.com.
Are there any drawbacks to using this system? It seems like a much simpler model than Stripe if it could be implemented to a marketplace, especially in cases of fraud. Transactions could be held in escrow until they were sufficiently completed.
Similarly, wouldn't this help avoid transaction fees? Maybe Fanduel is saying all account credits are essentially payments and then they allocate the money to its correct place on the site as credit? So the website is still using Paypal/Stripe, for all payments.
Forgive my ignorance about this stuff.
Even something ubiquitous like PayPal isn't usually available at retail locations.
Here's the scenario: a seller is selling something expensive. Some buyers may prefer purchasing by credit card (simple) but others may prefer to wire money to the seller. To guarantee the transaction, we would take an authorization on a credit card for, let's say 10 days and if the buyer transfers the amount during that time, we remove the hold on the credit card. If he hasn't transferred the money after the elapsed time, then we would charge the card.
Would Stripe or Balanced support such a scenario and if so, what would be the fees? Is there any impact of having a lot of CC holds that don't go through?
We won't be supporting wire transfers: https://github.com/balanced/balanced-api/issues/267
As our CEO says in that thread, given that we do same-day payouts to Wells Fargo and next-day payouts to all other banks, we think ACH debits are a better use-case than a wire transfer in this scenario.
To handle your case with ACH debits, you would debit the bank account, it would go into our escrow, and then when the seller ships, you would pay them out.
Now, for one or two other things:
We absolutely support the ability to do an authorization and then a capture: we call it a 'hold', since we provide both ACH and credit card processing. Holds are free, and you pay the same price when you capture as when you do a regular charge: https://www.balancedpayments.com/pricing
And we put a limit of seven days for a hold. As you've asked, credit card companies don't like seeing lots of voided holds: you've basically frozen someone's funds for a period of time. Doing it often generally means something else is going wrong.
You can't currently accept payments with Stripe via wire, but you can accept payments via ACH-in (currently in beta: email amber@stripe.com for access) as well as debit/credit card. You could certainly do exactly what you describe with ACH-in and a separate authorization/capture process via credit/debit card, however authorizations expire in 7 days, so you may want to keep that in mind.
I suggest doing a separate authorization and capture via credit card (https://stripe.com/blog/auth-capture) OR accepting payments via ACH-in, rather than attempting to do both at the same time which can lead to customer confusion.
Stripe only charges upon a successful transaction (https://stripe.com/pricing), so the uncaptured authorizations will not cost you money.
One thing though...I hate the website. I had no idea I needed to scroll down. I know its web 3.0ish but it's stupid.
I am currently working on a bitcoin marketplace, while it would restrict the ease of use for users, it would also cut out alot of fraud and chargebacks crap
I would rather have a large part of a rapidly growing pie than fighting ebay or amazon on their turf
Perhaps bitcoin will go mainstream and everyone will be using it sometime in the future. Perhaps. But until then, the marketplace you're building isn't really even competing in the same space as this.
Maybe there are niches where it is feasible to operate in bitcoin at this time. For almost everyone though this isn't an option.
The price of ACH debits is 1% + 30¢, _capped_ at $5. So a $10 debit would cost you 40¢. I know you've said you're doing high-dollar transactions, just wanted to make sure that it was super clear, as we try to be with all of our pricing.
Some other people just simply don't understand how _quickly_ they can get money via ACH. It's a matter of venturing into the unknown vs. what's tried and true. So when we say "You'll get your money today, in your bank account, if you use Wells Fargo, and tomorrow otherwise," they say "really?" And decide ACH is good enough for the cost. Then again, that's on the payout side rather than the pay-in side, though I guess if your website accepted payment via check, it'd be much faster there, too.
There are also all kinds of other complications in dealing with paper checks that may make it worth the $5. Here's the issue where we talk about Balanced and paper checks, and this comment in particular is very insightful: https://github.com/balanced/balanced-api/issues/69#issuecomm... Checks are also not reversible, which we feel is a significant drawback.
Anyway, no matter what you do, feel free to ping me if you have any questions payments related: I've really enjoyed learning this domain, there's so many details, and they're all so important...
We actually just rolled out a new version of our API last week, and put a _significant_ amount of effort into improving the documentation. Check it out: https://docs.balancedpayments.com/1.1/overview/
Steve mentioned below that they have new docs, I have not had the chance to check them out yet.
I'm happy to give you access if you'd like to try it out -- just email me at amber@stripe.com.
That's not currently possible with our marketplace products (Connect or Transfers).
Balanced does: https://www.balancedpayments.com/ach-debits
I can see this mostly used on smaller-scale projects or businesses. Otherwise it just makes too much sense to set up your own Stripe, especially considering how easy it is to set up Checkout.
We list more at https://stripe.com/docs/integrations.
[Edit: yep, what Zac said in the sibling comment.]
To be successful at it you need to be more than just a middle man; you provide value by solving an impedance mismatch between sets of buyers and sellers.
For example: eBay provides a reputation system, a search engine, and a payments processor (PayPal). Those are all arguably difficult things for individual buyers and sellers to provide. As a result eBay attracts a large audience of both, making the marketplace for goods more efficient, and extracts a small cut of lots of transactions.
Stripe is providing a way to make the payment provider part of the marketplace equation more easily available to developers. In theory you can focus more on the other hard parts of making a successful market.