Sharetribe Marketplace Payments: Stripe Connect, Payouts, Refunds, and Alternatives

Last substantive review: August 2026.

A marketplace payment decision is not just a gateway decision. It determines who can sell, when providers are paid, how commission is collected, where refunds and disputes land, what operators reconcile, and how the transaction state in Sharetribe stays aligned with the money state in the payment provider.

For most new Sharetribe marketplaces in supported countries, the built-in Stripe Connect path is the sensible baseline. It combines customer card payments, provider onboarding and bank payouts, marketplace commission, and Sharetribe’s transaction process. Move to custom Stripe work, another provider, or no online payment only when a documented business constraint justifies owning more of that lifecycle.

Choose the payment architecture first

Sharetribe’s current overview of payments with Stripe describes the built-in configuration: Stripe Connect Custom accounts for providers, card payments from customers, bank payouts to providers, delayed transfer until the transaction reaches the relevant state, and commission charged to the customer, provider, or both. The no-code path supports cards; additional payment methods such as Apple Pay or iDEAL require custom code.

How the built-in Stripe Connect flow works

1. The customer starts a transaction and pays by card in the marketplace.
2. Stripe processes the payment within the marketplace platform configuration.
3. Sharetribe’s transaction process records the payment-related transition and controls what can happen next.
4. The marketplace keeps its configured customer and/or provider commission.
5. When the transaction reaches the payout trigger, Stripe pays the provider’s connected account balance to the provider’s bank account according to the configured flow.

The important architectural boundary is step three. Sharetribe transaction states are the business record: requested, accepted, delivered, completed, canceled, or whatever a custom process defines. Stripe records the financial objects. Operators need both records to agree. A refund entered only in Stripe, for example, can leave Sharetribe showing a completed or paid transaction that no longer matches the funds.

Do not describe the built-in hold as escrow. Sharetribe and Stripe delay the provider payout under their platform and connected-account flow; an escrow arrangement has a specific legal meaning and may require licensing.

Countries and currencies: check the provider, not just the buyer

Customers can generally pay by supported card from many countries. The tighter constraint is the provider: the seller needs a bank account and verification documents in a country supported by Sharetribe’s specific Stripe Connect configuration. Sharetribe’s list is narrower than Stripe’s broad country availability because its implementation requires a particular set of Connect capabilities.

As of the review date, the official Sharetribe country and currency list names provider payout support in Australia, Austria, Belgium, Bulgaria, Canada, Cyprus, the Czech Republic, Denmark, Estonia, Finland, France and specified French territories, Germany, Greece, Hong Kong, Ireland, Italy, Japan, Latvia, Lithuania, Luxembourg, Malta, Mexico for marketplaces operating within Mexico, the Netherlands, New Zealand, Norway, Poland, Portugal, Romania, Singapore, Slovakia, Slovenia, Spain, Sweden, Switzerland, the United Kingdom, and the United States including Puerto Rico.

The listed marketplace currencies are AUD, CAD, CHF, CZK, DKK, EUR, GBP, HKD, JPY, MXN, NOK, NZD, PLN, RON, SEK, SGD, and USD. Confirm the live list before committing to a launch country because platform capabilities and regulation change.

Sharetribe uses one marketplace currency at a time. Its currency documentation notes that listing prices store their currency. Changing the marketplace currency does not silently convert existing listings; old listings may need to be updated or recreated before they can transact. Displaying or charging multiple currencies requires custom work, and payout conversion can create platform fees or reconciliation differences.

Country and currency preflight

• List provider legal countries, bank-account countries, and expected payout currencies, not only customer locations.
• Verify the built-in Sharetribe list and any country-specific restriction, including Mexico’s domestic-marketplace condition.
• Choose the marketplace settlement currency and model provider conversion exposure.
• Test the complete provider onboarding with a representative account in every launch country.
• Decide what the product does when a provider is ineligible: block onboarding, collect a lead, or route to a separately designed payment path.

KYC and connected-account onboarding

In the built-in flow, providers do not create a normal standalone Stripe business account for the marketplace. Sharetribe sends them through Stripe-hosted Connect onboarding for a Custom connected account. Stripe collects identity, business, ownership, and bank information required for know-your-customer and payout checks. Sharetribe’s provider payout-details guide explains this flow.

Plan onboarding as a lifecycle rather than one form:

• Explain why the information is required and that Stripe collects it.
• Distinguish “returned from onboarding” from “eligible to receive payments and payouts.”
• Handle missing, overdue, rejected, and newly required information.
• Give support staff a safe way to diagnose status without copying identity documents into tickets.
• Test business types and representative edge cases in each operating country.

Verification requirements change. Build a provider-status surface and support procedure instead of treating incomplete KYC as a mysterious checkout failure.

Payout timing follows the transaction process

Stripe payout settings for the built-in integration are manual, while Sharetribe triggers the provider payout when the transaction reaches its configured point. According to Sharetribe’s current payout documentation, the default calendar-booking process initiates payout two days after the booking ends. In the default purchase process, payout follows buyer receipt or automatic completion 14 days after the provider marks the order shipped. A custom transaction process can use different transitions.

The same documentation describes maximum holding windows of up to 90 days in most supported countries and up to two years for connected accounts in the United States. Treat those as platform constraints to verify, not a target payout policy. Marketplaces should promise providers only the timing they can support after transaction conditions, fraud review, Stripe processing, and bank transfer time.

Specify these cases before launch:

• provider never accepts or cannot fulfill;
• customer cancels before fulfillment;
• customer and provider disagree about completion;
• a bank payout fails after the marketplace transaction completes;
• KYC becomes restricted while funds are pending;
• a booking is rescheduled, partially fulfilled, or extended;
• the transaction nears the applicable holding limit.

Commission and fees need separate ledger lines

Sharetribe can configure a percentage or fixed commission on the provider, customer, or both. Its commission guide also allows zero commission, but zero platform commission does not remove Stripe fees.

Do not hard-code a blog’s Stripe percentages into the business model. Rates depend on platform country, card, currency, connected-account activity, payouts, conversion, and the current contract. Pull fees from Stripe financial records and keep gross merchandise value, platform revenue, processor fees, provider liability, and cash movement distinct.

Refunds, cancellations, and disputes

For the built-in flow, operators should issue a cancellation and refund from Sharetribe Console so the marketplace transaction and Stripe payment move together. Sharetribe’s refund guide says the default operator action is available before transaction completion. After completion, refund funds may need to come from the platform balance. The built-in feature does not provide partial refunds; that requires a custom implementation and transaction-process design.

Define a refund matrix by transaction state. For each state, state who may request, who approves, whether commission is returned, where funds come from, how the provider balance is handled, what appears in each product, and what evidence support retains. Avoid processing a manual refund only in the Stripe Dashboard unless an incident procedure also repairs the Sharetribe state.

Disputes and chargebacks need their own workflow because they can arrive after the marketplace considers a transaction complete. Assign an owner for Stripe notifications, evidence deadlines, customer and provider communication, balance exposure, and accounting entries. Your marketplace terms should match the actual charge and funds-flow design.

Reconciliation: connect the business state to the money state

Create a payment ledger that maps the Sharetribe transaction ID to every relevant Stripe identifier available in your implementation: PaymentIntent or charge, connected account, transfer, application fee, refund, dispute, and payout. Store currency, customer total, provider amount, commission, processor fees, current Sharetribe state, current Stripe state, and timestamps.

The Sharetribe Integration API exposes transaction totals, line items, transitions, and sequenced events that an integration can query. Sharetribe events are not a replacement name for Stripe webhooks. A custom Stripe integration should also operate a verified endpoint using Stripe Connect webhooks for account, payment, refund, dispute, transfer, and payout changes relevant to its charge model.

Make both ingestion paths idempotent. Persist the external event ID or Sharetribe sequence position, tolerate delayed and out-of-order delivery, and reconcile from source records on a schedule. Alert on mismatches such as:

• Sharetribe completed but payment not in the expected successful state;
• refund in Stripe without the corresponding cancellation or refund state in Sharetribe;
• provider payout failed after transaction completion;
• commission or currency differs between line items and the processor ledger;
• connected account restricted while it has pending transactions;
• an event consumer has stopped advancing.

Merchant of record and taxes cannot be inferred from the word “marketplace”

Document the exact Stripe charge type and whether the platform uses on_behalf_of. Stripe’s merchant-of-record guidance for Connect explains that the merchant of record can be the connected account or the platform depending on that configuration. The merchant of record is presented to the customer and carries responsibilities that include refunds and disputes. Do not publish terms that say every provider is the merchant, or that Horizon, Sharetribe, or Stripe has made the legal decision for you.

Tax responsibility is similarly fact-dependent. Stripe Tax documentation for Connect distinguishes tax collection configurations, while noting that a platform’s legal marketplace-liability status depends on applicable law rather than a Connect label. Determine seller-of-record presentation, marketplace-facilitator duties, indirect-tax registration, invoice content, information reporting, and treatment of platform fees with qualified counsel and tax advisors in each launch jurisdiction.

When to customize or use another payment provider

Customization is justified when a requirement survives a precise comparison with the built-in path: an unsupported provider country, required local payment rail, split or milestone release, partial refunds, deposits, multi-currency charging, a regulated funds flow, or a transaction model that cannot be represented safely with the default process. Sharetribe’s custom-development guide confirms that third-party gateways, additional payment methods, deposits, and transaction changes are custom-code territory.

A new gateway is not complete when checkout returns success. Budget for provider onboarding, failed verification, asynchronous payment states, duplicate callbacks, refunds, disputes, payout failures, reconciliation, accounting exports, admin tools, support procedures, security review, test fixtures, and migration. The decision should compare total operating burden, not only transaction pricing.

When a no-payment marketplace is cleaner

Some marketplaces sell access to demand rather than processing the underlying transaction. Sharetribe documents a service-marketplace flow without online payments using listings, inquiries, and messaging. That can suit lead generation, high-value deals closed by invoice, free exchange, or a subscription-funded community.

The tradeoff is concrete: the marketplace cannot automatically collect a commission from money it never processes. It also loses payment-linked signals for conversion, fulfillment, refunds, and disputes. Decide how access is monetized, what off-platform conduct is allowed, how completion is measured, and what protection the product does or does not provide.

Migration without losing the financial tail

Payment migrations fail when teams move the happy-path checkout but abandon open transactions, provider verification, refunds, disputes, and accounting history. Use a cutover plan:

1. Inventory: map every current transaction state, stored payment reference, provider account, pending balance, refund window, dispute window, currency, tax record, and operator report.
2. Decide portability: confirm with each payment provider which connected-account and payment credentials can legally and technically move. Do not assume provider verification or cards can be copied.
3. Choose a boundary: define whether open transactions finish on the old rail while new transactions start on the new one. Avoid changing the financial system underneath an in-flight booking.
4. Rehearse: test representative provider types, success and failure states, cancellation, full and partial-refund policy, dispute intake, payout failure, and ledger matching in a non-production environment.
5. Preserve the tail: keep secure read and operational access to the old system until its refunds, disputes, payouts, reporting, and retention duties are closed.
6. Reconcile: prove the closing old balances and opening new balances, then monitor both systems through the defined tail period.

If the marketplace currency changes, handle existing Sharetribe listings explicitly; a display change is not a price conversion. If the transaction process changes, map which old transitions remain valid and ensure operators can still support legacy transactions.

What experienced Sharetribe engineering adds

The hard work sits between product policy, Sharetribe transaction logic, Stripe financial objects, provider onboarding, and operator tooling. Horizon Labs supported Rarewaters from the first day of its marketplace operations through its acquisition. That establishes long-running Sharetribe operating experience; it is not a claim about payment performance or acquisition outcomes.

Recommended next step: request a marketplace payments architecture review. Horizon Labs will map the intended funds flow, countries and currencies, transaction states, commission, KYC, payout timing, refunds and disputes, reconciliation, tax and merchant-of-record questions, customization triggers, and migration risks before implementation begins.

Frequently asked questions