Commerce Partner Agreement Update: What's Changing and Why

Date of Last Revision: September 1, 2025

  1. Why We’re Updating the Partner Agreement We’ve combined the legacy Agency Partner Agreement and Technology Partner Program Agreement into a single, modern Commerce Partner Agreement to make life simpler for partners. The new agreement: • Unifies multiple programs (referrals, agencies, developers—apps & themes, unified billing) so you don’t need to juggle separate contracts to participate in different partner activities. • Aligns referral commissions in one easy-to-read schedule so it’s clear what you’ll earn across tiers and services. • Clarifies app developer terms, including a clear distinction between Public and Custom Apps (where revenue share only applies to Public Apps), plus a defined process for app wind-downs to protect partners and customers. • Introduces optional Unified Billing so Commerce can invoice, collect, and remit to you fees from customers and provide consistent monthly reporting. • Reflects our updated parent brand (Commerce) and covers BigCommerce, Feedonomics, and Makeswift under one agreement.
  2. About the Rebranding to Commerce The rebranding to Commerce reflects our evolution from siloed platforms to an integrated, AI-driven ecosystem. Commerce now serves as the open, intelligent engine powering: • BigCommerce – a scalable e‑commerce platform • Feedonomics – data optimization for AI-powered discovery. • Makeswift – visual, collaborative storefront design tools. Each brand continues to operate under its own name but now works in concert within a unified ecosystem, enabling partners and customers to benefit from deeper integrations, shared infrastructure, and aligned innovation. The new partner agreement enables partners to work with all three platforms.
  3. Partners with Existing Negotiated Terms If you’re on negotiated or custom terms, the new partner agreement does not apply to your engagement with Commerce. Those negotiated/custom terms continue to govern. At renewal, the parties will evaluate whether to move to the new partner agreement.
  4. Side-by-side Comparison of Key Changes:

Key Change

Legacy Agreements

New Partner Agreement

Unified Agreement Structure

Separate contracts by role (Agency for agencies/referrals; Technology for app/tech partners). Multiple contracts to join multiple programs.

One consolidated agreement with Parts A–D covering referrals, agencies, developers (apps & themes), technology partners, payments, and unified billing; API Terms and commercial terms are incorporated.

Public vs. Custom Apps

No explicit public/private distinction; tech program applied a general 20% revenue share to app activity.

Clear definitions of Public App vs. Custom App. Revenue share applies to Public Apps. Custom (single-customer) apps aren’t revenue-shared.

Parent Brand Coverage

Issued under BigCommerce; focused on the BigCommerce platform.

Issued by Commerce (parent of BigCommerce, Feedonomics, Makeswift) and definition covers all 3 offerings.

Payments App Developer Revenue Minimum

No specific minimum for payments apps.

$5k/year revenue share minimum for Developers of Payments Apps; shortfall is paid as a program fee.

Referral Commissions Aligned & Simplified

Different schemes split across program guides—harder to compare.

Aligned, tiered referral commissions in a single schedule with clear percentages by partner tier, service, and term.

Unified Billing

Optional direct billing required a separate addendum; otherwise partner billed merchants directly.

Unified Billing terms included by default which allows partners to optionally enroll in Unified Billing without executing new terms.

Wind-Down Protections

No explicit wind-down protections.

90-day wind-down for Public App removal so customers aren’t stranded and partners have a protected runway to offboard customers and apps.

  1. What This Means for You • Fewer contracts, clearer rules. One agreement covers all partner actions and brands, with aligned referral commissions and a single destination for developer and billing terms. • Developer clarity. If you ship Public Apps, revenue share rules are explicit; Custom (single-merchant) work isn’t revenue-shared and shouldn’t be replicated as multiple “custom” deployments. • Optional Unified Billing. Use Commerce to handle invoicing/collections and receive predictable monthly remittances and reporting.