Choosing a Marketplace Payments Structure

For marketplaces, choices about payment processing are often really about business models and product strategy. How a company builds in payments impacts the ways it can capture value, create trust, and even achieve product-market fit.

In this essay I’ll cover the different options marketplace companies have for building payments into their product and how to choose.

Types of marketplace payment solutions

The different ways a marketplace can enable supply and demand to transact fall into three categories:

• No payments: when the company directs supply and demand to exchange money outside of the marketplace.
• 3rd party referral: suppliers are required to obtain a merchant account with a payment processor and link that account to the platform to transact.
• Embedded payments: a variety of different solutions where suppliers onboard as merchants with the marketplace. Control over how merchants get paid and how funds flow through the system are up to the company.

No payments

The first thing to consider is whether a transaction on the marketplace needs to involve an on-platform payment at all. If facilitating a payment transaction is not high on the list of problems that customers need you to solve for them, there are real advantages to offering no in-product payments solution; it means that a company takes on no payments risk and has no integrations to build or maintain. That translates to development, operations and additional resources that can be spent focusing on other things.

Of course no in-product payment limits the product’s utility. Not only does the transaction itself have to happen off-platform, but related functionality for both demand and supply, like order management and financial tools, won't exist either. Other downsides are that there’s no opportunity to monetize payment processing and no way for the company to control the transaction.

Creating trust without payments

With no control over the transaction, a company is limited in its ability to arbitrate. It can’t prevent bad transactions, force refunds, or withhold payouts from suppliers. Just compare the confidence consumers have purchasing from sellers on Amazon Marketplace with the learnt vigilance Craigslist customers must adopt to avoid being scammed.

But certain types of marketplaces can achieve a sufficient level of trust without controlling the movement of funds. Thumbtack uses high quality ratings and reviews, pricing information, structured leads and other tactics to create enough trust so that pros and consumers connect initially. If they can do that, it’s via chat, on a subsequent phone call or at an in-person meeting, where consumers and pros really size each other up. And the value exchange takes place off platform -- a common pattern for a Light Marketplace. 

Third party referral

A marketplace can direct suppliers to get a merchant account from a 3rd party payment provider and connect it to the platform. So, for example, when Substack writers want to offer a paid newsletter they link a new or existing Stripe merchant account. When a supplier’s merchant account is linked in this way, the company gets limited control to do things like make a transaction and take a fee. As for everything else -- payouts, chargebacks, reporting, support -- that’s all between the merchant and the payment provider directly.

The leading solution of this type is Stripe Connect Standard. But there are others and many processors will offer an OAuth solution that can grant a platform permission to take action on a merchant's behalf.

When is 3rd party referral the right fit?

For many marketplaces, the limited control over the way funds flow makes the referral model too restrictive. For others it’s the goldilocks ‘not too hot, not too cold’ balance between offering payments in-product with little investment or risk. If the following are true, it’s a good sign that this model may be ‘just right’:‍

Simple transactions and simple fees: Because the transactions are actually happening on linked merchant accounts that belong to each supplier respectively, there are only very specific things that the company is authorised to do with the money. So you should only consider this setup if transactions are going to be between one buyer and one seller at a time (i.e. you don’t need consumers to fill their cart with the merchandise of several suppliers), and if you expect to charge a simple predetermined fee per transaction. Generally speaking, anything more elaborate than that won’t work well.‍

Building trust through payments is not critical (at least not on day one): A 3rd party referral setup lets a buyer make a purchase through the platform. However, consumers still have to deal directly with the supply side to get resolution for things that go wrong after the purchase; like disputes for example. The company has more visibility and can intervene to a degree, but it’s limited and doesn’t ultimately control the exchange of funds. For this reason a 3rd party referral setup is not a fit for a marketplace where trust vis-a-vis payments is key to the value prop. For example, StockX -- where trust is the value prop to both sides of the marketplace -- couldn’t exist with a referral solution.

For marketplaces where trust via payments is not a blocker for getting off the ground, a 3rd party referral setup can help avoid or defer a lot of development work and payment risk. For Airbnb and Eventbrite, trust is obviously incredibly important. But both still started out directing the supply side to create a PayPal merchant account and link it to the platform. The two marketplaces later graduated to an embedded payments model where they could broker trust and really control the transaction.‍

Your suppliers ‘get it’: By choosing a 3rd party referral setup, you’re requiring suppliers to manage a merchant account in order to use your product. That works if your supply side can handle the complexity. But if they are mostly casual sellers or a user type who would find that burdensome or confusing, then you may want to go another way. That’s one of the reasons that Facebook Marketplace offers both ‘no payments’ (i.e. pay off platform) and an embedded solution to sellers, but no 3rd party referral option. For the type of supply they’re targeting, managing a merchant account is a barrier and overhead.

Embedded payments

With an embedded setup, the supplier’s experience—from onboarding through processing to payout—is so tightly integrated (or say, embedded) into the product that they can’t tell if there’s a 3rd party in the mix at all. An embedded solution allows the company to determine the timing of payouts to supply, split the funds more flexibly (whether its between multiple parties, or across complex fee logic), and to make a margin on payment processing. 

With control comes risk

With the added control over the flow of funds, the company can arbitrate between supply and demand. That makes an embedded solution a good fit for a Managed Marketplace. 

But with that control come added risks: the company is ultimately responsible for disputes and chargebacks. As opposed to the 3rd party referral option, where chargebacks are between the suppliers and the 3rd party processor. Here the marketplace is in the middle. That means that the company has to build fraud detection as well as tools and operations to resolve disputes, and chargebacks and fraud losses become a part of doing business.

Full stack vs. mix-and-match

Stripe Connect Custom or Express, and Adyen for Platforms are examples of a full-stack embedded solution -- one product that provides an end-to-end embedded infrastructure. But a company may also choose to use several payment partners and piece together it’s embedded solution to varying degrees. For example, instead of using Stripe as a sole partner, a company could use Hyperwallet for onboarding and payouts, and separate partners for payment processing. Etsy uses primarily Adyen and Worldpay for accepting payments, has built its own onboarding and KYC program, and pays out sellers through different banking partners.

An embedded solution already requires a larger development cost than a referral solution does. Piecing together that embedded system with multiple vendors is even more of a technical and operations lift because the company has to worry about the connective tissue bridging the different components. Things like reconciliation systems, logic for routing transactions to different processing partners, a vault, working out a compliance program, tracking balances, funding accounts, and reporting, are all things that you could rely on a single full-stack solution for, and may become more complex with multiple partners. For mature, Heavily Managed Marketplaces -- some of which are basically a vertical specific neo-bank -- it may be a relatively small investment in the grand scheme of their fintech aspirations. But for most companies, supporting this added complexity can be challenging.

So why would a company today consider piecing it together rather than just using a full-stack solution? There are two main reasons:

• Flexibility to choose and customize: When evaluating payment partners you may find that certain capabilities justify the complexity of a separate integration (or even building certain components of the system yourself). For example, Stripe might be hands down the best solution for your product, except that in order to serve your customers well, you must offer PayPal or some new payment method that Stripe hasn’t integrated. It will add some complexity to your system and operations, but it may be worth it.
• Redundancy in the system: Some companies have a particular vulnerability to single-sourcing payments and need redundancy. For Patreon this type of problem came up when the company’s payment partner, Stripe, determined that creators on the platform were selling pornography (in fact, it was Wells Fargo -- a party up stream of Stripe -- but the consequences were the same). To solve this problem and protect the creative freedom of its supply side, Patreon integrated another payment partner, and selectively routed transactions through them and to a separate merchant ID (MID).

What about payment facilitation?

Becoming a Payment Facilitator (PayFac) is a special type of embedded approach. You can register to be a “Payment Facilitator” and onboard merchants on behalf of a sponsoring acquirer. It’s simpler than it sounds. Basically, as a PayFac, instead of using a 3rd party payments provider, the company steps into that role itself and becomes responsible for merchant onboarding, merchant screening, settlement, risk and compliance.

The work to build all the infrastructure, apply for the licenses, and create the compliance programs that are required to operate as a PayFac is large, expensive, and slow. There are companies like Finix and Infinicept that are making it simpler by providing infrastructure and tools, but it’s still a huge investment.

Payment Facilitation wasn’t built with Managed Marketplaces in mind. It enables card processing, but no alternative payment types, no transaction splitting, no compliance shortcuts, and no access to the other financial services that embedded 3rd parties provide out of the box. Simply put, Managed Marketplaces should not choose a PayFac setup. 

In a previous essay I defined a SaaS-like Networks as a software company that supports interaction between business customers and their end consumer.  That’s who the PayFac model is really better suited for.It’s best for large SaaS-like Networks, like Shopify or Quickbooks, that want to provide sellers a competitively-priced, white-labled payments solution. 

But even for the SaaS-like Network use case, it’s much harder than integrating an embedded 3rd party solution. So, why do it?

• For better economics: Being a PayFac can save a company ~40-100 bps on processing costs. But only if a company has a large enough GTV will the added margin justify the fixed costs associated with becoming and operating a PayFac. And even then, the opportunity cost may be too large.‍
• To compete with payment providers: If the payments component of a company’s business is competing against other payment providers, that’s a good clue that it may want to consider being a PayFac. By creating Shopify Payments, the company started going head-to-head with other payments companies both on and off the Shopify Platform. Simply embedding another 3rd party solution wouldn’t do -- to compete at that level a company needs to get closer to the bare metal. So, while Shopify Payments uses Stripe APIs and infrastructure, it operates as a registered PayFac.‍
• To ‘own’ the sub-merchants relationship: Certain companies value having a direct relationship with their sub-merchants without a 3rd party in between. That way they can avoid being in the position where someone else could deactivate their customers’ accounts or limit them. And when the company is doing onboarding itself, there’s no need to re-onboard sub-merchants or create discontinuity for them if the company ever wanted to change providers.

Choosing the right payments solution

A company’s business model is the primary driver of payment processing choices. As the business model evolves, a company may also need to change its approach to payments. Early on, Thumbtack had an in-product embedded payments solution, which was later removed once it decided to focus on a lead-gen model. Care.com started out monetizing via a demand side subscription. That model fits its senior care business well. But for the babysitting business -- a more frequent, shorter term use case with less disintermediation risk for the company -- Care.com chose a transaction fee model and, to enable that, built an embedded 3rd party solution.

Most other considerations are related to product experience. How much control over payments does the company need to create trust? What payment tools and experiences are required for product-market fit? What payment solution will make sellers most successful?

The answers to questions like these aren’t the same for every company and even for a given company they may change over time. Airbnb started with a referral solution for payments, and that enabled early success. But as the company grew and could invest more development and operations towards payments, it phased to an embedded solution that allowed it to govern marketplace dynamics and trust more effectively and to provide a simpler product experience for both sides of the marketplace.

As a company optimizes for product experience, it’s got to also set itself up for long term maintenance and improvement. Payment products are getting better and the industry is moving pretty quickly. So ensuring that you have the right partners and editing out integrations or customizations that have become unnecessary is an ongoing endeavor. At Eventbrite, we’ve updated our payment stack in some meaningful way every few years. It’s not necessary or wise to jump at every minor improvement or new payment method right away. But as payments companies innovate it’s smart to take note and ensure your product and customers aren’t left behind.

--

Thanks to Yael Barak and Casey Winters for feedback on drafts of this post.