TBBN Pricing

This page covers Merchant SaaS billing — one of TBBN's two payment flows (the other, TBBN Space, is a payout to hosts rather than a charge to anyone; see docs/business/conflict-resolution-log.md items 19-20 and services/space-service/README.md). Merchant SaaS billing is Business-rooted, not per-Merchant (Phase 25): a Business pays for one plan that covers usage across every Merchant account it has linked, billed collectively — see services/billing-service/README.md. TBBN does not currently charge an individual seller for anything (an earlier version of this document specified a seller listing-boost payment; that flow was removed entirely, see conflict-resolution-log.md item 14). Businesses are currently the only counterparty TBBN bills for a SaaS plan. ("Currently," not "only"/"never" — founder-directed language change, conflict-resolution-log.md item 17.) This revision (2026-07-04, founder-directed — see conflict-resolution-log.md item 16) lowers the flat plan prices, adds an annual-billing option, and formalizes the per-completed-checkout fee. It does not reopen a percentage-of-trade-value fee — see "Why a flat per-checkout fee, not a percentage" below.

Merchant SaaS plans

	Sandbox	Starter	Growth	Enterprise
Monthly billing	$0	$200/mo	$500/mo	Contact us — custom quote
Annual billing (paid yearly, upfront)	—	$150/mo ($1,800/yr) — save 25%	$400/mo ($4,800/yr) — save 20%	Contact us — custom quote
Listing visibility	none (sandbox env only)	Global only	Global + Private + Both	+ Enterprise (private trading with hand-picked enterprise merchants)
Widgets / white-label	sandbox only	—	✓ widgets, white-label option	✓ + dedicated infra option
Included listing syncs/mo	unlimited (rate-limited, sandbox)	2,500	10,000	negotiated
Included searches/mo	unlimited (rate-limited, sandbox)	10,000	50,000	negotiated
Included offers/mo	unlimited (rate-limited, sandbox)	500	2,500	negotiated
Included trade sessions/mo	unlimited (rate-limited, sandbox)	250	1,200	negotiated
Included webhook deliveries/mo	unlimited (rate-limited, sandbox)	5,000	25,000	negotiated
Overage — listing sync	—	$0.02	$0.02	negotiated
Overage — search	—	$0.002	$0.002	negotiated
Overage — offer	—	$0.15	$0.15	negotiated
Overage — trade session (negotiation)	—	$0.75	$0.75	negotiated
Checkout-orchestration fee (per completed checkout)	—	$1.50	$1.50	negotiated (floor: Growth rate × 3x, i.e. never under $4.50/completed cross-merchant checkout)
Cross-merchant (global) event multiplier	—	4x	4x	negotiated, floor of 3x
Support	community	email, best-effort	priority email, 2 business-day SLA	dedicated channel, named account manager

Toggle, not two products. Starter and Growth are the same plan at two billing cadences, not different tiers — a merchant picks monthly or annual at signup and can switch at renewal. Annual pricing is a straight discount for paying upfront (25% off Starter, 20% off Growth); it is not a different feature set. apps/Landing-page/components/PricingTiers.tsx renders this as a monthly/annual toggle with a "save X%" badge, matching common SaaS pricing-page convention.

Enterprise has no listed price by design. Real enterprise buyers (the eBay-scale end of the target market) expect a custom quote, not a self-serve number, and a low sticker price undersells the tier to exactly the audience it needs to convince — see docs/design/design-system.md's stated audience ("an engineering org that would trust TBBN with their checkout flow"). Contact-us does not mean unspecified — the table above still lists everything Enterprise includes (Enterprise-only private trading, dedicated infra option, custom workflows, negotiated volume quotas, a 3x-floor cross-merchant multiplier, named account manager), so a prospect can evaluate fit before a sales conversation, they just can't self-serve checkout into it.

The checkout-orchestration fee

$1.50 is charged per completed checkout — precisely, per CHECKOUT_A_COMPLETE/ CHECKOUT_B_COMPLETE event (see docs/architecture/trade-session-state-machine.md), i.e. per side of a trade, billed to whichever merchant owns the seller on that side. A standard two-sided trade where both parties complete checkout generates $3.00 total in checkout-orchestration fees across the two merchants involved (or $3.00 to one merchant, if both sides belong to the same merchant). Cross-merchant completions meter at the existing 4x multiplier ($6.00/completed checkout), 3x floor at Enterprise ($4.50 minimum). This event has no included free quota at any tier — unlike listing syncs/searches/offers/trade-session-negotiation, which have a plan allowance before overage kicks in, every completed checkout is billed from the first one. This is intentional: it's the moment TBBN's matching and orchestration actually created realized value for the merchant, so it's the one metered event priced from dollar one rather than bundled into a monthly allowance.

Merchants may pass this fee to the seller/trader. A merchant's own checkout is free to build the $1.50 (or $6.00 cross-merchant) fee into what it collects from the buyer/trader at checkout — the same way a business might build a payment-processing fee into its prices, or itemize it as a line-item surcharge. This is the merchant's commercial decision on the merchant's own checkout; it does not create a second TBBN-to-seller payment flow. TBBN's invoice relationship is still exclusively with the merchant — TBBN never bills, or has a relationship with, the individual seller either way. See business-model.md's "only payment flow" principle, which this preserves exactly.

Why a flat per-checkout fee, not a percentage

An earlier draft of this document (and, separately, a founder proposal on 2026-07-04 to charge 1% of a listing's original price per checkout) considered pricing the checkout-orchestration event as a percentage of trade value instead of a flat fee. Both were rejected, for the same reason (see conflict-resolution-log.md items 1 and 16): a fee that scales with the dollar value of a specific transaction is, in substance, a take-rate — the fingerprint of a payment processor or marketplace commission (Stripe, Square, eBay), which is exactly the regulatory and positioning profile business-model.md was written to avoid ("TBBN does not currently touch trade money" is the single most important business decision in this repo). A flat fee per event, regardless of that event's dollar value, is a usage/infrastructure fee instead — the same shape as Twilio billing per SMS or Plaid billing per API call, independent of what the SMS or API call was "worth." $1.50/completed checkout captures the same "we make money when trades actually happen, not just when merchants list inventory" story a percentage fee would, without the take-rate mechanics or the collection problem a percentage fee creates (a percentage requires the merchant to self-report the completed checkout's dollar amount, and the merchant's incentive is to under-report; a flat per-event fee is metered by TBBN's own systems and isn't self-reported).

Billing cycle, invoicing, and grace period

• Monthly-billing merchants: the plan's flat fee and the accrued usage/checkout-orchestration charges for the period are combined into one invoice, due every billing cycle (billing-service aggregates by calendar month — see packages/utils's currentBillingPeriodRef() — treated as the "30 days" cycle referenced in the founder's original instruction).
• Annual-billing merchants: the plan's flat annual fee is invoiced once, at signup and each annual renewal. Usage/checkout-orchestration charges are not deferred to the annual renewal — they still accrue and invoice monthly, on the same cycle as a monthly-billing merchant, for the months between annual renewals. (There is no world in which a merchant processing thousands of completed checkouts waits a year to be billed for them.)
• Due date: the end of each monthly billing cycle.
• Grace period: 7 days past the due date to pay an outstanding invoice.
• Suspension: if an invoice (plan fee and/or checkout-orchestration/usage charges) remains unpaid 7 days past its due date, the merchant's production API access is suspended until every outstanding bill is paid in full. Sandbox access is unaffected by suspension (evaluation only, no money involved).
• Dashboard visibility: a merchant's dashboard must show a running ledger of completed checkouts this cycle, the amount accrued, the amount due, the due date, and — if overdue — days remaining in the grace period before suspension. services/billing-service's UsageService.getSummary() already aggregates and totals checkout-orchestration charges per billing period (consumed by apps/merchant-dashboard's Billing page) — due dates, the 7-day grace-period countdown, and automatic suspension are specified here but not yet implemented; see services/billing-service/README.md for the concrete gap.

Why these price points

Benchmarked against usage-first API infrastructure pricing (Twilio, Plaid) rather than transaction-take-rate marketplace pricing, since TBBN's revenue model is structurally closer to the former. $200/mo (or $150/mo annual) is a low enough commitment for a small thrift/consignment business or classifieds platform to try trading as a retention feature without a large up-front bet; $500/mo (or $400/mo annual) targets platforms with real seller volume who need private/ internal trading, "Both" visibility, and white-label; Enterprise's custom quote matches how a mid-to-large marketplace already budgets for infrastructure vendors — a number arrived at through a sales conversation, not a self-serve checkout, same as Twilio/Plaid/Stripe all treat their largest accounts. The lower Starter/Growth flat fees (down from $299/$999) intentionally trade some per-merchant revenue for a meaningfully easier "yes" from a business on the fence, with the per-completed-checkout fee and cross-merchant multiplier making up ground as a merchant's real trade volume grows — revenue that scales with a merchant's success without billing a percentage of what any single trade was worth.

Which tier fits which kind of business

• Thrift & consignment businesses, classifieds platforms — thin engineering teams, lower seller volume, evaluating trade as a low-lift retention feature: Starter, via the embeddable widget path (see docs/business/business-model.md's target-customer table).
• Ecommerce platforms (Shopify/WooCommerce/Magento merchants), social commerce apps — moderate-to-real seller volume, want a "trade in" option or a community/engagement feature without building matching infrastructure themselves: Starter to start, Growth once private/internal trading, widgets, or white-labeling matter.
• Marketplaces and resale apps with real seller volume wanting trade as a retention feature alongside cash sales, with either full cross-merchant reach or fully private internal-only trading: Growth.
• Large marketplaces and platforms (eBay-scale) needing enterprise-only private trading with hand-picked merchants, dedicated infrastructure, custom workflows, and an SLA: Enterprise, sales-assisted.

What is explicitly not priced/sold

TBBN does not charge a percentage of trade value, does not take any cut of a merchant's own checkout/fulfillment revenue, and — as of this revision — does not charge individual sellers for anything at all (merchants may choose to pass the flat checkout-orchestration fee through to their own seller/trader at their own checkout, but that is the merchant's checkout and the merchant's commercial decision, not a TBBN-to-seller charge). An earlier version of this document specified a seller listing-boost payment (per-listing paid ranking promotion, $4.99/$14.99/$34.99 for 7/30/90 days, charged via services/boost-payment-service). That flow, and the service, have been removed entirely; see conflict-resolution-log.md item 14. This is deliberate and protects the "TBBN does not currently handle money" positioning that keeps TBBN a low-risk infrastructure company rather than a regulated marketplace/payments business — and it also removes the merchant-of- record/consumer-tax exposure that flow previously created (see docs/legal-flags/open-legal-questions.md).

Open item: Space API pricing (Phase 32, not decided)

The Space API (GET /v1/space/search, SpaceApiKey credentials, headless booking — see docs/business/conflict-resolution-log.md item 26) is currently free to use for any Business holding a key — this document does not yet specify a plan/usage fee for it, the way Merchant SaaS billing has one. The founder's framing of Space as "a business on its own" could eventually mean its own pricing model, separate from Merchant SaaS billing's merchantPlan/spaceEarnings split (item 20) — but per this document's own precedent (items 1 and 16), no new fee gets introduced without an explicit founder decision recorded here first. Flagged, not decided.

Free-space listing fee (Phase 34, shape decided, collection not built)

Per docs/business/conflict-resolution-log.md item 28: a Business that lists a Space for free (Space.isFree) owes TBBN a flat listing fee — the founder set $20 as the default but explicitly required it be dynamic, staff-set rather than hardcoded, via a future admin.tbbnetwork.com (Phase 35, planned not built). This phase implements the real, DB-backed mechanism (PlatformFeeSchedule for the amount, BusinessOneTimeCharge created PENDING per free Space at creation time, defaulting to $20 when no schedule row exists) but deliberately does not attempt real Stripe collection or admin editing of the fee amount yet — billing-service has no one-time-charge mechanism at all, and building one speculatively would repeat the mistake items 1 and 16 already warn against. A Space that charges for itself owes nothing beyond the existing Space commission (SpaceCommissionRate) — no change there.

Business webhook deliveries are not a billed usage dimension. BusinessWebhookDelivery (Phase 34, Business-rooted outbound webhooks) deliberately does not emit a UsageEvent the way Merchant's WebhookDelivery does — introducing a new billed dimension needs the same explicit founder decision this section's own precedent requires, not a silent default from mirroring the Merchant shape.