Here's my question on this: is it better to have your marketplace collect all the payments and then ACH out funds to sellers? OR is it better to have each seller create their own Stripe account via Stripe connect and have the payments go directly to their Stripe account?
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.
To add on this, I would advocate you to think more in terms of user experience (which pc addressed very well) rather than fraud liability when making your decision.
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.
The type of fraud that is endemic to many marketplaces is exactly what can be prevented by going with the Stripe Connect approach. In a nutshell, what happens is (a) fraudster creates a fake "store" in your marketplace, (b) they run purchases through that store with stolen credit cards, (c) they attempt to have the funds transferred to a bank account. Your own founder even talked about it [1] and I've had to deal with this quite a bit at http://nextproof.com
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 ;)
Oh, I completely agree -- I am well aware of this (in fact as you can guess we have a similar challenge problem with fraudulent even organizers). Which is why I precised I was talking about buyer fraud and not merchant fraud, and that one should only undertake risk if he has the capability to do so.
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!
If you're dealing with a lot of marketplace fraud, you might take a look at Sift Science (http://siftscience.com). We're a YC company that uses machine learning to detect fraud, and we have a number of marketplaces using us successfully (including AirBnB, Uber and Kickstarter).
Pathwright just uses Stripe Connect. As pc mentioned, this lets them handle their own refunds and get their hands on their data. It's worked well so far!
We ask sellers to create their own Stripe accounts via Connect on JobBoard.io. It's crucial that they be able to control their own refunds, the $ amounts on transactions tend to be quite high which means they want the money quickly, and it is much easier from a Tax perspective.
It would also matter if your customers are in one of the 4 countries that can have stripe merchant accounts. I'm running into that issue with manualviableproduct.com.
I really wish a payment processor other than Amazon could offer a separate microtransaction rate[0]. For anything under $10, Amazon reduces their regular rate of 2.9% + $.30 to 5% + $.05.
Is this new? Anyone know if Stripe supports transactional escrow yet? E.g. when a credit card charge clears, are those funds available immediately in my account balance, for payout or withdrawal? Balanced does this and it's one of the most valuable features IMO.
I've used the Stripe Transfers API, and am considering using it on another project soon, but I've also been looking at Balanced.
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.
Thank you! That is what I needed to hear. The 7 day transfer delay needed to go bye bye. Do we have an eta on that? Also want to say I would love to pre-pay into the balance to avoid overages as well.
I can't wait for Stripe to have escrow capabilities. The hack is to delay the time to capture but there are many marketplace scenarios where the duration of the transaction is longer than a week and it's great to be able to hold onto funds so that if/when the seller finally delivers they get paid and the buyer feels safe that the money isn't in the hands of the seller until then.
Stripe was always going to release this. Balanced however, has more advanced tools to deal with marketplaces (i.e: you need to write less code to power a marketplace on Balanced than Stripe).
This is not a big deal though, the battle will end up being who can scale globally faster.
> ..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-... ).
Spent 15 minutes playing with the background on this page: you can push circles around by moving your mouse nearby, if you push circles apart connections break, if you push them together they forge new connections. Rather fun little piece of interactivity.
(bill from wepay here)
competition in payments is a good thing for the market & I believe that Stripe has had these APIs for some time.
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.]
Hi there, I hadn't seen wepay before and it looks really interesting. Do you have a page that sets out exactly what risks there are when building a marketplace with your system? I see that you guys say you protect from fraud with an anti-fraud system but presumably fraud will happen sometimes and I'm wondering who gets the bill when it does.
Sure, there are a lot of unique risks involved with building a marketplace. My cofounder Rich wrote a pretty extensive overview here: https://www.wepay.com/api/payments-101
Two quick questions:
* does payouts also work for european bank accounts? The linked blog post specifically mentions 'anyone with a us bank account'
* If I only want to do payout via stripe, how would I get money in? Just bill myself?
Stripe needs to incorporate being able to remove bank accounts from their recipients. Right now if a recipient wants to change their bank account, all their past transfers get erased.
Hi! I work on product at Stripe. We're currently working on better API for managing recipients.
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.
I don't see any new features being launched here, but it's a nice landing page that sets out the value proposition and use cases for marketplaces more clearly. Yet again making me wish that the Transfers API was available in Europe!
I'm frequently trying to explain to people that Stripe has all the features to run one's marketplace on but folks somehow think that they should be using another product merely because of the marketing. Good to have a centralized marketing experience targeted toward marketplaces, even if the feature set didn't change. It is very smart -- PC and the whole Stripe team did a great job here.
I love Stripe, I love the continuous improvements, but since Stripe also accepts different currencies, I'm still waiting for a way to localize all that standard stuff Stripe comes with, e. g. "Stripe checkout". Can't use it, since labels are not in German and not all of my users speak English and not all labels can be customized/translated yet.
I agree. The rate of innovation is very impressive and I'm sure with the engineering talent they already have, these improvements are more feasible than say expanding from country to country. But I would love to see increases in the rate of adaption of existing features for international users as my company (and many others) would greatly benefit from Stripe in LatAm for example.
Have any of you had experience with user Credit accounts - in the fashion of Fanduel.com. In this system, users use Credit/Debit cards or Paypal to pre-fill up their accounts. They can then use this money to make purchases/bets on the website.
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.
That could definitely save on transaction fees, but my observation is that customers want their spending money in their most liquid account possible, which for many is their bank account.
Even something ubiquitous like PayPal isn't usually available at retail locations.
I wonder if I could do the following... Any help would be appreciated.
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?
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.
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.
We are in the process of launching a service that would utilize a marketplace feature and currently looking into options available. I am wondering how is Stripe Marketplace different compared to Balanced marketplace with the escrow feature. I believe the escrow functionality is pretty much the same with what Stripe has to offer as "Dashboard?
Not really impressed, why would you want to put your marketplace at the whims of Stripe or credit card companies?
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
Because depending on your industry the vast majority of people have never used bitcoin and have no intention of working the whole thing out. Most of everyone interested in buying online though can use one of a credit card, PayPal or a bank transfer.
Maybe there are niches where it is feasible to operate in bitcoin at this time. For almost everyone though this isn't an option.
I don't really have pony in this race, but one thing I'll say is "ease of use for users" is paramount.
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.
Any plans to enable ACH payments? My industry deals with very large sized payments (>$1000), and people currently use paper checks - $30+ is too high for the convenience. Having stripe offer ACH would enable some fantastic stuff.
It appears they use ACH for payments, but not debits (credit card only it appears). We run a marketplace with 5-6 figure transactions and use Balanced Payments. Their documentation is fairly terrible, but they cap ACH fees at $5, which is key, because we are passing the money through and would go out of business if we had to give 3% or whatever to a 3rd party.
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/
Oh that's nice. $5 still might be a barrier for the use case I have in mind, though. I wonder if there's any higher level of identity verification that one could do to reduce it further.
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.
Hey Steve, thanks for the clarification. I understood, but it's probably useful for others. My transactions would all be maxing out that cap, just not sure if users will be willing to replace their paper checks if they have to pay $5 more.
Totally. Our experience around checks has been interesting: basically, there are some customers who absolutely do not want anything but a check. They've been using checks their entire life, and they don't want to change. Fair enough.
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...
They have very pretty docs, but in the case of ACH their sample code and directions did not work. Luckily their dashboard uses their API and keeps logs, so I was able to reverse engineer the proper way to set up a customer and bank account.
Steve mentioned below that they have new docs, I have not had the chance to check them out yet.
Is a way to ACH money from my bank using Stripe so that I can pay people via ACH? I am looking for a simple solution for outbound ACH payments via an API. If Stripe doesn't have this does anyone else?
We do custom pricing at scale; the fees depend on the breakdown of card types used with your service (and hence the underlying costs). Want to drop us an email at sales@stripe.com?
Basically, all this does it make it so each "seller" doesn't have to create a whole Stripe setup. It introduces a middleman who collects a fee. Useful for some applications, I guess so.
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.
What is the value proposition you can build on top of this? create marketplaces but for what? is it common to use a business model to skim percentage for each transaction?
Yes it is a common business model, and great work if you can get it.
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.
This is for products like TaskRabbit, Lyft, Postmates, HomeJoy, OrderAhead, and so on -- products that happen to involve some amount of each charge going to a third party. They generally aggregate the demand and build the UI themselves, though -- without them, there is no product.
[Edit: yep, what Zac said in the sibling comment.]
It's a pretty common model -- create some valuable way for buyers and sellers of some service to connect. That's AirBnb, Uber, Lyft, Ebay, Postmates, etc. It can be a hard business to start because of the chicken and egg problem but often leads to a very defensible business because of the network effects.
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).