Simple Automation Solutions

Marketplace Architecture Guide

Building a Two-Sided Marketplace on Bubble.io

The complete technical blueprint: buyer & seller flows, listing management, search & discovery, escrow payments with Stripe Connect, reviews & trust, dispute resolution, onboarding funnels, and production-grade security — built correctly in Bubble from day one.

9Core Chapters
70+Code Patterns
~40minRead Time
⏱ 40 min read  ·  Bubble.io Marketplace Architecture
marketplace.yourdomain.com/listing/brand-identity-design
Search
logo design…
Category ▾
Price ▾
🎨
Brand Identity Pack
by @designpro
$299
★ 4.9 (142)
💻
Full-Stack App Build
by @bubblewizard
$1,200
★ 4.8 (87)
Order #4821  ·  Escrow held
IN ESCROW
🛒 Browse
💰 Sell
📝 Orders

What Makes a Marketplace Different — & Why It’s Harder Than a SaaS

A marketplace is a platform that connects two distinct user types — typically buyers and sellers (or hosts and guests, freelancers and clients, providers and consumers) — and facilitates transactions between them. Think Etsy, Fiverr, Airbnb, Upwork, and eBay. The platform takes a commission (or fee) on every transaction rather than charging a flat subscription.

Marketplaces are architecturally more complex than SaaS for a fundamental reason: you have two completely different user experiences to build (buyer and seller), two different onboarding funnels, payment flows that involve three parties (buyer, platform, seller), trust mechanisms (reviews, verification badges), and a cold-start problem where neither side has value without the other. Getting this architecture right in Bubble from day one determines whether your marketplace can scale — or whether you’ll be rebuilding everything after your first 500 users.

The core marketplace equation: Money flows from Buyer → Platform (held in escrow) → Seller (after delivery confirmation), minus platform commission. Every technical decision in your Bubble marketplace — data model, payment setup, privacy rules, notifications — must correctly implement this three-party financial relationship. Use the wrong Stripe product and you’ll either hold money illegally or lose your commission entirely.

The Seven Pillars of a Marketplace on Bubble

👥

Dual User Roles

Buyers and sellers are the same User data type but with different profiles, onboarding paths, and dashboards. A user can be both a buyer and a seller simultaneously.

🛒

Listing Management

Sellers create, edit, and manage listings. Listings have status (draft, active, paused, sold). Categories, tags, pricing models, availability, and media galleries all live on the Listing type.

🔍

Search & Discovery

Buyers discover listings via keyword search, category filters, price ranges, ratings, and location. Search performance is the single biggest driver of buyer conversion and must be architected carefully in Bubble.

💰

Stripe Connect (Escrow)

Payments use Stripe Connect with the platform as the intermediary. Funds are captured from the buyer, held by the platform, then released to the seller’s connected Stripe account after delivery, minus the platform’s commission.

💬

Messaging System

Secure in-platform messaging between buyers and sellers on a per-order basis. Messages must be scoped to an Order (not a listing) to prevent off-platform transactions and maintain dispute history.

Reviews & Trust

Bidirectional reviews: buyers review sellers, sellers review buyers. Reviews are only unlocked after order completion. Aggregate ratings on seller profiles drive discovery ranking and buyer confidence.

Dispute Resolution

When delivery is disputed, the platform mediates. Funds remain in escrow until resolved. The dispute system must trigger Stripe refunds or releases programmatically based on outcome decisions.

📋

Order Lifecycle

Orders move through a defined status workflow: Pending → Accepted → In Progress → Delivered → Completed (or Disputed/Cancelled). Each status transition triggers notifications and payment actions.

📊

Seller Analytics

Sellers need revenue dashboards, order history, payout tracking, and listing performance data. Buyers need order history, saved listings, and spend tracking. Two separate dashboard experiences from shared data.

Marketplace Architecture: The Full Stack

Buyer ↔ Platform ↔ Seller — Stripe Connect as the financial backbone
🛒
Buyer A
🛒
Buyer B
👪
Buyer+Seller
👴
Seller C
↓ all users served from a single Bubble application
⚙  Single Bubble Application
Listings  ·  Orders  ·  Messaging  ·  Reviews  ·  Disputes  ·  Payouts
💰 Stripe Connect
📧 SendGrid / Postmark
💬 Pusher (realtime)
🔍 Algolia (search)
📄  Bubble Native Database — privacy-scoped, order-scoped, listing-scoped on every query

Marketplace Types You Can Build on Bubble

🛒
Product Marketplace

Physical or digital goods. Sellers list products with inventory, buyers purchase and receive. Examples: handmade goods, templates, stock photos, ebooks, plugins.

  • Inventory tracking per listing
  • Digital delivery (file download)
  • Shipping address collection
💼
Service Marketplace

Freelancers and professionals offer scoped services. Examples: Fiverr clone, design marketplace, development services, consulting bookings.

  • Service packages with tiered pricing
  • Delivery milestones + revision rounds
  • Order brief / requirements intake
🏠
Rental Marketplace

Spaces, equipment, or assets available for time-limited rental. Examples: Airbnb clone, equipment rental, parking spot rental, event venue booking.

  • Availability calendar per listing
  • Date-range booking with conflict detection
  • Security deposits & damage claims
📅
Booking Marketplace

Appointment-based or event-based transactions. Examples: tutoring sessions, fitness classes, beauty appointments, coaching calls.

  • Time-slot availability management
  • Calendar sync (Google Calendar API)
  • Reminder notifications

The Core Marketplace Data Model

The marketplace data model is the foundation every other decision sits on. Get these relationships wrong and you’ll be refactoring while live orders are in flight. These eight data types cover the complete foundation of any two-sided marketplace built on Bubble. Every additional feature you build will extend these types — not replace them.

👤User (extended)
display_nametext
avatarimage
biotext
is_selleryes/no
seller_profileSeller Profile
stripe_customer_idtext
avg_buyer_ratingnumber
onboarding_doneyes/no
notification_prefstext (JSON)
👴Seller Profile
userUser
headlinetext
skillslist of text
portfolio_itemslist of file
stripe_account_idtext
stripe_payouts_enabledyes/no
avg_ratingnumber
total_reviewsnumber
total_salesnumber
verifiedyes/no
response_time_hrsnumber
🛒Listing
sellerUser
titletext
descriptiontext
categoryCategory
tagslist of text
pricenumber
pricing_typeoption set
imageslist of image
statusoption set
delivery_daysnumber
revision_countnumber
avg_ratingnumber
total_ordersnumber
📋Order
buyerUser
sellerUser
listingListing
statusoption set
amount_centsnumber
platform_fee_centsnumber
seller_payout_centsnumber
stripe_pi_idtext
stripe_transfer_idtext
requirementstext
due_datedate
delivered_atdate
completed_atdate
💬Message
orderOrder
senderUser
bodytext
attachmentslist of file
read_by_buyeryes/no
read_by_selleryes/no
is_system_messageyes/no
Review
orderOrder
reviewerUser
revieweeUser
reviewer_typeoption set
ratingnumber (1–5)
commenttext
is_publicyes/no
Dispute
orderOrder
opened_byUser
reasonoption set
detailstext
evidencelist of file
statusoption set
resolutionoption set
resolved_byUser
📝Category
nametext
slugtext (unique)
parent_categoryCategory
iconimage
sort_ordernumber
is_activeyes/no

The Order Status State Machine

Every order in your marketplace travels through a defined sequence of states. Each state transition is a one-way door — you can’t move backward (except via dispute/cancellation paths). Enforce this by checking the current status in every status-changing workflow before allowing the transition.

1
💳
Pending
Payment captured, awaiting seller acceptance
2
Accepted
Seller confirmed, work begins
3
🛠
In Progress
Active work, messaging open
4
📦
Delivered
Seller submitted, buyer reviews
5
🎉
Completed
Payout released to seller
// Option Set: Order_Status PENDING — buyer paid, seller hasn’t accepted yet ACCEPTED — seller accepted, requirements being collected IN_PROGRESS — requirements submitted, seller working DELIVERED — seller marked as delivered, buyer review window open REVISION — buyer requested revision, back to seller COMPLETED — buyer approved or auto-approved after 3 days; payout triggered DISPUTED — dispute opened; funds frozen in escrow CANCELLED — order cancelled; buyer refunded REFUNDED — dispute resolved in buyer’s favour; full refund issued // Status transition enforcement in any workflow Step 1: Only when Order’s status = IN_PROGRESS // Prevents a seller from marking as delivered twice // or from skipping the In Progress state Step 2: Make changes to Order: status = DELIVERED, delivered_at = now Step 3: Create Message (system): “Seller has marked this order as delivered…” Step 4: Send email to buyer: “Your order has been delivered — review now”

Stripe Connect: The Only Correct Way to Handle Marketplace Payments

This is the most critical technical decision in your entire marketplace build. Standard Stripe (Checkout, Payment Links) is for one-party payments: customer pays you. Marketplaces require three-party payments: customer pays you, you pay the seller minus your commission. This requires Stripe Connect — a completely different product with a different API, different onboarding flow, and different compliance requirements.

Using standard Stripe for marketplace payments is not just technically wrong — it may be legally non-compliant in your jurisdiction (as you would be holding funds on behalf of third parties without a money transmitter licence). Stripe Connect is specifically licensed for marketplace fund flows.

Stripe Connect vs. Standard Stripe: Standard Stripe Checkout sends money from buyer to your Stripe account. That’s it. Stripe Connect charges the buyer, holds the platform fee, and routes the remaining amount to the seller’s connected Stripe account — either immediately (direct charges) or on a delay (destination charges with hold). For marketplaces, use destination charges with a transfer delay to implement escrow. The platform retains funds, then triggers a Transfer to the seller’s stripe_account_id upon order completion.

The Two-Phase Payment Model (Escrow)

// PHASE 1: Buyer pays (at order creation) // Use PaymentIntent with capture_method=manual to hold funds POST /v1/payment_intents amount: order_total_cents (e.g. 29900 for $299.00) currency: “usd” customer: buyer’s stripe_customer_id capture_method: “manual” ← holds funds, does not settle application_fee_amount: platform_fee_cents (e.g. 2990 for 10%) transfer_data.destination: seller’s stripe_account_id metadata: { order_id: “bubble_order_unique_id” } // Store PaymentIntent ID on Order record // Order status → PENDING // Funds are reserved on buyer’s card but not yet captured // PHASE 2a: Order completed — release funds to seller POST /v1/payment_intents/{pi_id}/capture (no body required) // This captures the charge AND automatically transfers // (order_total – platform_fee) to seller’s connected account // Store transfer ID on Order record for reconciliation // PHASE 2b: Order cancelled — release hold, refund buyer POST /v1/payment_intents/{pi_id}/cancel // Releases the hold; buyer’s card is never charged // If already captured: use /v1/refunds instead

Seller Onboarding: Stripe Connect Express

Before a seller can receive payouts, they must complete Stripe’s identity verification flow. Use Stripe Connect Express — it provides a hosted, Stripe-managed onboarding UI that handles KYC (Know Your Customer), bank account collection, and compliance. You create the account, Stripe handles verification.

1
Create Connected Account
// Called when user clicks “Become a Seller” POST /v1/accounts type: “express” email: Current User’s email capabilities: { transfers: { requested: true } } metadata: { bubble_user_id: Current User’s unique id } // Store response.id on Seller Profile: stripe_account_id
2
Generate Onboarding Link & Redirect
POST /v1/account_links account: Seller Profile’s stripe_account_id refresh_url: “https://app.com/seller/connect-stripe?refresh=true” return_url: “https://app.com/seller/connect-stripe?success=true” type: “account_onboarding” // Open response.url — Stripe-hosted, branded KYC flow // On return, check account status via webhook below
3
Handle account.updated Webhook
// Webhook: account.updated // Fired when Stripe verifies the seller’s account Find Seller Profile by stripe_account_id = event.account If event.data.object.payouts_enabled = true: Step 1: Update Seller Profile: stripe_payouts_enabled = yes Step 2: Update User: is_seller = yes Step 3: Send email: “You’re now set up to receive payments!” Step 4: Create Audit Log entry

Commission Models: How Marketplaces Make Money

📈

Percentage Commission (Most Common)

Platform takes a percentage of every transaction. Example: 10–20%. Calculated as order_amount × commission_rate and passed as application_fee_amount in the PaymentIntent. Stripe automatically retains this amount when routing funds to the seller.

💵

Flat Fee per Transaction

Fixed dollar amount per order regardless of order size. Better for high-value orders where percentage would be too punitive. Set a fixed platform_fee_cents value. Can be combined with a small percentage.

📅

Subscription + Commission

Sellers pay a monthly subscription (managed via standard Stripe Subscriptions) plus a reduced commission rate. Two separate Stripe products working in parallel. Higher seller LTV, lower per-transaction friction.

Listing Fees (Optional)

Charge sellers to post listings above a free tier. A one-time PaymentIntent per listing publish action. Store a paid_listing flag and only set status to Active after payment confirmation via webhook.

Stripe Webhook Handlers for Marketplaces

payment_intent.succeeded
Buyer payment captured
Find Order by metadata.order_id. Update Order status from PENDING to ACCEPTED (if auto-accept) or keep as PENDING (if seller must manually accept). Send notification to seller: “New order received.”
payment_intent.payment_failed
Card declined at checkout
Find Order. Update status to CANCELLED. Send buyer an email notifying them the payment failed and prompting them to retry with a different payment method. Do not notify the seller.
transfer.created
Payout sent to seller after order completion
Find Order by metadata.order_id. Store stripe_transfer_id on Order. Send seller notification: “Your payout of $X has been initiated — arrives in 2–7 business days.”
charge.dispute.created
Buyer files card chargeback
Find Order. Create Dispute record. Update Order status to DISPUTED. Notify both buyer and seller. Alert your admin team. Stripe will automatically freeze the funds. Submit evidence via Stripe dashboard.
account.updated
Seller Stripe account status change
Find Seller Profile by stripe_account_id. Update stripe_payouts_enabled accordingly. If payouts become disabled (e.g., Stripe verification issue), notify the seller and pause their active listings from accepting new orders.

Privacy Rules: Access Control for a Marketplace

Marketplace privacy rules differ from SaaS in one key way: some data is public (listings are visible to everyone including non-logged-in users) and some data is strictly private (order messages can only be seen by the two parties involved in that order). You need both public and private access patterns, correctly separated.

Data Type Privacy Condition View Edit Delete Search
Listing Rule 1: status=Active → Everyone. Rule 2: seller = Current User → all statuses Seller only (Rule 2) Seller + Admin
Order Current User = Order’s buyer OR Current User = Order’s seller Via workflows only
Message Current User = Message’s order’s buyer OR Message’s order’s seller
Review Rule 1: is_public=yes → Everyone (view only). Rule 2: reviewer = Current User Reviewer within 24h
Seller Profile Rule 1: Everyone (public). Rule 2: User = Current User (edit own) Own profile only
Dispute Current User = Order’s buyer OR Order’s seller; Admin always Admin only (resolution)
User Rule 1: display_name, avatar, avg_rating → Everyone. Rule 2: all fields → Current User self Limited (public fields) Self only
Category is_active = yes → Everyone
// Listing privacy — multi-rule pattern // Rule 1: Public view for active listings (allows non-logged-in browse) Condition: This Listing’s status = Active Permissions: View details ✓, Find in searches ✓ // Rule 2: Full access for the seller who owns the listing Condition: This Listing’s seller = Current User Permissions: View details ✓, Edit ✓, Find in searches ✓ // Note: Delete should go through a soft-delete workflow, not direct deletion // Order privacy — bilateral access Condition: This Order’s buyer = Current User OR This Order’s seller = Current User Permissions: View details ✓, Find in searches ✓ // Edit only via structured workflows, never direct field access // User privacy — expose only public fields to the world // Protect: email, stripe_customer_id, notification_prefs Rule 1 (Everyone): View details ✓ Fields visible: display_name, avatar, bio, avg_buyer_rating, is_seller Fields hidden: email, stripe_customer_id, all billing fields Rule 2 (Self): Condition: Current User = This User All fields visible, Edit ✓
💡

Hide Financial Fields from Privacy Rule “View”

Even when a user has view access to an Order (as buyer or seller), some fields must be hidden from the non-owning party. The seller should never see the buyer’s stripe_customer_id, and the buyer should never see the seller’s stripe_account_id or seller_payout_cents. Use field-level privacy within the same rule by toggling individual field visibility rather than granting blanket “all fields” access.

Order-Scoped Messaging & Notifications

Every message in a marketplace must be scoped to an Order, not to a user pair or a listing. This is non-negotiable. Order-scoped messaging preserves the complete communication history for each transaction, enabling dispute resolution to see exactly what was said between buyer and seller for that specific order. It also prevents buyers and sellers from creating “shadow” message threads outside of order context that would allow off-platform transactions.

Messaging Architecture

// Messages Repeating Group (inside Order detail page) Data source: Do a search for Messages order = Current Page’s Order Sort by: Created Date ascending Max items: 50 (paginate for long threads) // Send message workflow Step 1: Only when Message Input is not empty AND Current Page’s Order’s status is in [ACCEPTED, IN_PROGRESS, DELIVERED] // Prevent messaging on cancelled/completed orders Step 2: Create Message order = Current Page’s Order sender = Current User body = Message Input’s value attachments = File Uploader’s value (if any) read_by_buyer = Current User is buyer read_by_seller = Current User is seller Step 3: Reset Message Input Step 4: Send email notification to recipient If sender = buyer: notify seller If sender = seller: notify buyer Subject: “New message on your order: [Listing Title]” // Mark messages as read (on page load) Page load workflow: Search for Messages [order=Current Order, read=no (for current user)] Make changes to list: update read field = yes

System Messages: Automating Order Status Communication

Every order status change should automatically insert a system message into the order thread. This keeps the complete order history in one place and makes the timeline auditable. System messages use the is_system_message = yes flag and are displayed differently in the UI (no avatar, centred, timestamp-only).

Order Created
Buyer places order
“Order placed by [Buyer Name]. Please submit your requirements to get started.” — prompts buyer to fill in the brief/requirements.
Order Accepted
Seller accepts
“[Seller Name] has accepted your order. Expected delivery: [due_date].”
Delivery Submitted
Seller marks delivered
“[Seller Name] has submitted a delivery. Review and accept or request a revision within 3 days.” — includes auto-completion countdown.
Revision Requested
Buyer requests changes
“[Buyer Name] has requested a revision ([N] of [Max] allowed). See their feedback above.”
Order Completed
Accepted or auto-approved
“Order completed. Payment has been released to the seller. Please leave a review!”

Reviews, Ratings & Trust Signals

Trust is the currency of any marketplace. Buyers take risk when they pay before receiving a service. Reviews, ratings, seller verification, and response time metrics are the mechanisms that reduce perceived risk and drive conversion. Getting the review system correct — bidirectional, order-gated, tamper-proof — is essential for marketplace health.

Bidirectional Review System

// Review eligibility: only after order is COMPLETED // Buyer reviews Seller, Seller reviews Buyer — independently // Workflow: “Submit Review” (buyer reviewing seller) Step 1: Only when: Current Page’s Order’s status = COMPLETED AND Search for Reviews [order=Current Order, reviewer=Current User]:count = 0 // ↑ Prevents duplicate reviews on same order Step 2: Create Review order = Current Page’s Order reviewer = Current User reviewee = Current Page’s Order’s seller reviewer_type = Buyer rating = Star Rating element’s value comment = Comment Input’s value is_public = yes Step 3: Recalculate seller’s avg_rating (denormalised) // Search for all Reviews [reviewee=seller, reviewer_type=Buyer, is_public=yes] // Calculate average rating // Update Seller Profile: avg_rating = result, total_reviews += 1 // Also update Listing: avg_rating (for search ranking) Step 4: Update Listing: total_orders += 1 Step 5: Send notification to seller: “You received a review: ★★★★★”

Trust Signals That Drive Conversion

Verified Seller Badge

Awarded after Stripe Connect KYC is completed (payouts_enabled = true). Display a checkmark badge on all listing cards and the seller profile. This is the single most effective trust signal for buyers.

🕐

Response Time Display

Track message response time per seller. Recalculate avg_response_time_hrs on every first response to a new order. Display as “Typically responds within 4 hours” on listing and profile pages.

🏆

Top Seller Program

Award “Top Seller” status when a seller hits thresholds: e.g., 50+ completed orders, 4.8+ avg rating, 95%+ on-time delivery, 0 disputes in 6 months. Display prominently in search results.

👥

Member Since Date

Display how long a user has been on the platform. Older accounts signal stability and reduce perceived risk. Shows on seller profile and listing cards. Simple but meaningful to buyers.

📈

Repeat Buyer Rate

Show sellers what percentage of their buyers return. Track on Seller Profile as repeat_buyer_rate. A high repeat rate is the strongest possible signal of buyer satisfaction and product quality.

🔒

Buyer Protection Badge

Display “Protected by [Platform] Guarantee” on every listing and checkout page. Link to your dispute resolution policy. This reduces buyer anxiety significantly and has been shown to increase checkout completion rates.

Dual Onboarding: Buyers & Sellers

A marketplace has two distinct user activation paths that require different onboarding flows. A buyer is activated when they place their first order. A seller is activated when they publish their first listing and have their Stripe Connect account verified. Both paths need careful design — especially the seller path, which involves a third-party (Stripe) KYC step that many users will abandon if not guided correctly.

Buyer Onboarding Flow

1
Sign Up
Email + Password
Create User record. Set is_seller = no. Redirect to /onboarding/buyer. Collect display name and avatar. Optionally ask “What are you looking for?” to seed category preferences.
2
Browse Intent
Discovery
Show curated search results based on stated preferences. Key: get the buyer to a listing page within 60 seconds of signup. Reduce friction to browsing. No forced profile completion before browsing.
3
First Order
Activation event
On first checkout, prompt to add billing info. Create Stripe Customer on first purchase. Collect delivery requirements after order creation. Aha moment: buyer submits requirements and sees seller accept.
4
Order Complete
Retention trigger
Order marked complete. Prompt review immediately (strike while the satisfaction is fresh). Send a “Saved Listings” prompt — buyers who save listings re-purchase at 3× the rate of those who don’t.

Seller Onboarding Flow

1
Become a Seller
Intent declaration
Triggered from a “Start Selling” CTA. Show what’s required: Stripe verification, profile setup, first listing. Set expectations upfront. Most abandonment happens when users are surprised by Stripe KYC requirements.
2
Build Profile
Seller Profile record
Create Seller Profile record linked to User. Collect: headline, skills, bio, portfolio images. Show a profile completeness meter. High-quality profiles rank better in search. Make this feel like building a shop, not filling a form.
3
Connect Stripe
Stripe Express KYC
Create Stripe Connect Express account. Generate onboarding link. Open in same tab (not popup — popups block Stripe’s flow). On return, check webhook for payouts_enabled. If incomplete, show resume link via /v1/account_links.
4
Create First Listing
Activation event
Walk seller through the listing creation form. Use a multi-step UI (not one long form). Show a live preview of how the listing will appear to buyers. Publish requires Stripe verification. Aha moment: First order notification in their inbox.

Creating a Listing: The Multi-Step Form

1
Overview: Title, Category, Description

The listing title is the most important SEO element in your marketplace. Guide sellers: “I will [service/product description] for [audience/use case].” Category selection should use a two-level hierarchy (parent → sub-category). Description field should support rich text or at minimum line breaks. Save as draft on every step with an auto-save pattern.

// Create Listing as draft on Step 1 completion Step 1: Create Listing seller = Current User title = Title Input’s value category = Category Dropdown’s value description = Description Input’s value status = Draft Step 2: Navigate to: /seller/listing/[Result of Step 1’s unique id]/pricing
2
Pricing: Base Price, Packages, Delivery Time

For service marketplaces, offer three package tiers (Basic / Standard / Premium) with different deliverables, prices, and delivery times. For product marketplaces, a single price with optional quantity pricing. Delivery time and revision count are key differentiators that buyers filter on.

3
Gallery: Images, Videos, Portfolio

The gallery is the highest-impact conversion element on a listing page. Require at least one image before publishing. Guide sellers: first image is the thumbnail in search results — it must be a professional, high-contrast visual. Support up to 10 images and one video. Store as a list of images on the Listing record.

4
Publish: Review & Go Live

Show a complete preview of the listing before publishing. Run validation: all required fields completed, at least one image, Stripe payouts enabled. On publish, change status from Draft to Active (or Pending Review if you run manual moderation). Trigger a “Listing Published!” celebration moment.

// Publish workflow with validation Step 1: Only when: Listing’s title is not empty AND Listing’s images:count > 0 AND Listing’s price > 0 AND Current User’s seller_profile’s stripe_payouts_enabled = yes Step 2: Make changes to Listing: status = Active Step 3: Update Seller Profile: total_listings += 1 Step 4: Show success animation, navigate to listing public page

Production Launch Checklist & Security Hardening

A marketplace has more attack surface than a SaaS product because it handles real money flowing between real people. Every item in this checklist represents a failure mode we’ve seen in production marketplace builds. Do not launch until every item is checked.

💰 Payment & Financial Integrity

  • Using Stripe Connect (not standard Stripe) for all buyer-to-seller payment flows
  • Stripe webhook signatures validated on every event before processing
  • Order completion does NOT release funds via client-side workflow — only via server-side API Workflow triggered by business logic
  • Commission calculated server-side, not passed from client (can be manipulated)
  • All monetary values stored in cents (integers), never floats
  • Duplicate order prevention: check for existing pending order on same listing from same buyer before creating a new one
  • Tested the full refund path: cancelled order → PaymentIntent cancelled → buyer card never charged
  • Seller cannot trigger their own payout — release only via buyer accept OR auto-completion workflow, never via seller action

🔒 Data Privacy & Access Control

  • Order messages only visible to buyer and seller of that specific order — tested with three-user scenario
  • Buyer’s Stripe customer ID is not visible to sellers via privacy rules
  • Seller’s Stripe account ID is not visible to buyers via privacy rules
  • User email addresses never exposed via any search result or profile page
  • Dispute records only visible to the order’s buyer, seller, and admin users
  • Draft listings not visible to anyone except the owning seller
  • Admin panel accessible only to users with is_admin = yes — protected by privacy rules AND page redirect on load

✉ Messaging & Communication

  • All communication between buyers and sellers happens inside the platform — no ability to share external contact info in the first order message
  • File attachments in messages are only accessible to order participants
  • Email notifications sent for every message received when recipient is offline
  • Auto-completion workflow (3-day window after delivery) tested and running correctly via Bubble’s scheduled API workflows

⭐ Trust & Quality

  • Reviews only creatable after Order status = COMPLETED — checked in workflow AND privacy rule
  • Duplicate review prevention: one review per user per order (checked before creation)
  • Seller avg_rating is recalculated (denormalised) on every new review — not computed live on page load
  • Listing moderation workflow exists: admin can deactivate any listing without deleting it
  • User suspension workflow: admin can disable login, hide all listings, and freeze pending payouts

⚡ Performance & Scale

  • Search page uses database-level constraints only — zero use of :filtered by on search results
  • Listing search tested with 1,000+ active listings — results appear in under 1.5s
  • Seller dashboard tested with 200+ orders — no timeout or slow load
  • All monetary denormalised counters (total_sales, total_orders) updated on event, not recalculated on load
  • Order messaging tested with 100+ messages per thread — pagination implemented
  • Bubble app on at least Growth plan — marketplace workloads require dedicated server capacity
The marketplace cold-start failure mode: Most marketplace startups fail not from bad technology but from never solving the chicken-and-egg problem. You can’t attract buyers without listings. You can’t attract sellers without buyers. Solution: manually curate your first 20–30 high-quality sellers before launching to buyers. Personally recruit them. Subsidise their first orders. Create the appearance of a thriving marketplace before it actually is one. Your Bubble build needs to be ready for this — a clean listing creation flow, a polished buyer experience, and a working payment system. Architecture without supply-side hustle is not a business.

Recommended Bubble Plugins & Integrations for Marketplaces

Plugin / ToolUse CaseNotes
Stripe.js by ZeroqodeStripe Connect Express onboarding, payment element UI, Customer PortalHandles the Stripe.js SDK calls that the raw API Connector cannot
API Connector (built-in)All Stripe Connect API calls, webhook payload parsing, Algolia queriesEssential for PaymentIntent create/capture/cancel, Transfer, Refund calls
Algolia Search pluginFull-text listing search with relevance ranking, faceted filtersRequired for marketplaces with 5,000+ listings. Dramatically better UX than Bubble native search.
Pusher / Ably pluginReal-time messaging updates without page refreshBuyers and sellers expect instant message delivery — polling is insufficient for a good inbox UX
SendGrid / PostmarkTransactional emails: order notifications, message alerts, payout confirmationsPostmark preferred for deliverability on order and payment emails
Google Maps pluginLocation-based listings (rental marketplaces, local service marketplaces)Required for any marketplace where geography affects matching — adds address field to Listing
Filestack or UploadcareGallery image uploads with resize, crop, and CDN deliveryBubble’s native file upload stores raw files. Use a CDN service for listing images to improve load time.
Intercom pluginIn-app support chat, user identity, NPS surveysIdentify users with user_id, is_seller, total_orders for segmented support
Mixpanel / SegmentGMV tracking, conversion funnels, search-to-purchase analyticsTrack: search performed, listing viewed, checkout started, order placed, order completed as core funnel events

Build Your Marketplace the Right Way

Data model design, Stripe Connect integration, search architecture, and full marketplace builds —
the same disciplined approach applied to every Bubble product we ship.

Book a Free Discovery Call → View Our Work