The shift from desktop/web to mobile/app is creating new opportunities for commerce. Everything from the way we book travel to have our groceries delivered is up for grabs as commerce moves to mobile. When building an app or service that connects suppliers and consumers you quickly run into the issue of collecting payments on behalf of your merchants/sellers.
There are three major challenges: PCI compliance, who will act as merchant of record, and sharing/splitting revenue. Stripe Connect (and other platform offerings from Braintree and WePay's white label) has a really impressive approach to solving this challenge along with one major drawback. On the positive side, Stripe helps minimize your PCI compliance scope with card data never touching your environment. It also provides the ability for sellers to each have their own unique merchant account (under the marketplace's overarching umbrella) so that a marketplace can route payments made from buyers directly to each seller without ever touching the funds.
Perhaps of most value though is the fact that Stripe's API allows you to split a payment into two while only showing as a single transaction on the cardholder's statement. This allows marketplaces to deduct a fee and deposit it directly into their own account with the rest routed into the seller's account all in a single transaction. The major drawback is that every seller in your marketplace has to accept a Stripe account. This can be an unwanted drag on adoption/usage of your service (unless you rely on revenue share from processing as your primary revenue stream). And it only gets worse the bigger the opportunity; larger sellers are generally more attached to their existing payment processor for a variety of reasons including often substantially better processing rates.
There's a lot of simplicity in working with just one payment provider. At Spreedly we support Stripe Connect so there's really no "right" answer. Someone launching a new service may decide to only work with Stripe Connect and believe the simplicity of one solution outweighs the lost sellers who have an established processor relationship. Or you could work with Spreedly and Stripe Connect from the very beginning and incur Spreedly fees as an "insurance policy" so that when the moment comes to add that new gateway there is no technical gating factor to winning the seller/supplier.
Lately we've seen an uptick in interest from existing Stripe Connect marketplaces and platforms wanting to support more choices. It makes sense too; the longer Stripe Connect is around the greater chance some of those earliest customers are reaching a size where they are ready to support more than just a single payment choice.
Whether you decide to go with just Stripe to begin with and change later or have options up front we're happy to support.