Chapter 30: Commission and Revenue Models

Why This Exists

A marketplace does not make money by selling products; it makes money by facilitating the transaction. If the architecture cannot accurately calculate, extract, and route the platform's cut of the money, the business will quickly go bankrupt. The Commission and Revenue architecture exists to execute complex financial math—splitting payments between the platform, the vendor, and the payment gateway—while ensuring the accounting ledgers balance perfectly to the penny.

Real World Problem

A new marketplace launches with a simple business model: "We take 10% of every sale." A user buys a $10 mug. Shipping is $5. The total charged to the credit card is $15. The developer writes code that takes 10% of the total ($1.50). The vendor is furious. They explain, "The $5 was purely to pay the post office; I didn't make profit on that! You overcharged me commission." The developer fixes it to only take 10% of the item ($1.00). Then, the Stripe credit card processing fee hits: $0.30 + 2.9% of the $15 total = $0.74. The marketplace only keeps $0.26. The real-world problem is that simple percentage rules completely break down in the face of shipping, taxes, and third-party gateway fees.

Everyday Analogy

Think of a real estate agent selling a house. They sell the house for $500,000. They do not get $500,000. They take a 6% commission ($30,000). The rest goes to the seller ($470,000). But wait, the agent has to pay $1,000 for staging and $500 for legal fees out of their cut. Marketplace software has to automatically perform this "split and deduct" math for every single transaction in milliseconds.

Beginner Explanation

When a customer pays $100 on a marketplace, the money goes into a virtual bucket. The computer then divides the bucket:

The Gateway Fee: The credit card company takes $3 right off the top.
The Commission: The marketplace takes $10 for providing the website.
The Vendor Payout: The remaining $87 is set aside to be transferred to the seller's bank account.

Intermediate Explanation

Revenue models are rarely just "10% flat." Architectures must support Dynamic Commission Engines:

Category-Based: Electronics might have a 5% commission, while Jewelry has a 20% commission due to different profit margins.
Tiered Volume: A vendor pays 10% on their first $10,000 of sales, and 7% on everything after that.
Subscription Fees: The platform takes 0% commission, but charges the vendor $50/month to use the software (SaaS model).

Because of this complexity, the Commission Engine acts like a Rules Engine. During the checkout process, it evaluates the cart items against the commission rules to calculate the exact platform fee before finalizing the ledger entry.

Advanced Explanation

The hardest part of commission architecture is dealing with Floating Point Math and Refunds.

Computers struggle with fractions. 15% of $19.99 is $2.9985. You cannot charge someone fractions of a penny. The system must use Bankers Rounding (Round Half to Even) and store all financial values as Integers (cents). $19.99 is stored as 1999.

If a customer returns half of their order, the architecture must calculate a Pro-Rata Reversal. If the platform took $10 commission on a $100 order, and the customer refunds $50, the platform must claw back $5 of the commission from the platform's revenue account and return it to the vendor's escrow account to balance the refund.

Real World Example

Apple App Store vs. Epic Games: Apple's revenue model was famously strict: a flat 30% commission on all digital goods sold inside an iOS app. When Epic Games (Fortnite) tried to bypass this by offering a direct payment option to avoid the 30% fee, Apple banned them. This highlights that commission architecture isn't just code; it enforces the fundamental business strategy and legal agreements of the platform.

Architecture Design

Here is the flow of funds using a modern payment router (like Stripe Connect):

graph TD
    Customer[Customer Pays $100] --> Gateway[Payment Gateway]
    
    Gateway -->|Takes Gateway Fee: $3| GatewayBank[(Stripe Revenue)]
    
    Gateway -->|Evaluates Routing Rules| Router{Fund Router}
    
    Router -->|Extracts Platform Commission: $15| PlatformBank[(Marketplace Bank Acct)]
    
    Router -->|Holds Vendor Funds: $82| Escrow[(Vendor Escrow Balance)]
    
    Escrow -- Triggers Weekly --> Payout[Vendor Bank Account]

Database Design

Financial ledgers must track exactly where every penny went.

Commission Rules Table:

CREATE TABLE commission_rules (
    id UUID PRIMARY KEY,
    category_id UUID NULL, -- Null implies default rule
    percentage DECIMAL(5,4), -- 0.1500 for 15%
    fixed_fee INT -- stored in cents, e.g., 30 for $0.30
);

Transactions Ledger:

CREATE TABLE transactions (
    id UUID PRIMARY KEY,
    order_id UUID,
    vendor_id UUID,
    gross_amount INT, -- 10000 ($100.00)
    gateway_fee INT,  -- 300 ($3.00)
    platform_commission INT, -- 1500 ($15.00)
    net_vendor_payout INT, -- 8200 ($82.00)
    status VARCHAR(50), -- 'HELD_IN_ESCROW', 'PAID_OUT'
    CONSTRAINT math_check CHECK (gross_amount = gateway_fee + platform_commission + net_vendor_payout)
);

API Design

The API must expose the ledger to the vendor so they can do their accounting.

GET /api/vendor/transactions Response:

{
  "order_id": "ord_123",
  "gross_sale": 100.00,
  "deductions": {
    "marketplace_fee": -15.00,
    "payment_processing": -3.00
  },
  "net_earnings": 82.00
}

Production Considerations

Tax on Commissions: In many countries, the platform's commission is considered a B2B service. If you charge a vendor a $10 commission, you might legally owe $2 in VAT on that service fee. The system must generate VAT invoices for the vendors detailing the commission taken.
Negative Balances: If a vendor has $0 in their account, and a customer issues a $100 chargeback, the vendor's balance becomes -$100. The platform must have a mechanism to automatically debit the vendor's actual bank account or credit card to recover the negative balance, otherwise, the marketplace absorbs the loss.

Security Considerations

Double Entry Accounting: A single database row (like the transactions table above) is acceptable for MVP, but enterprise platforms use Double Entry Accounting. Every movement of money writes two rows: a debit to one account and a credit to another. This prevents "money out of thin air" bugs, as the sum of all accounts must always perfectly equal zero.

Common Mistakes

Taking Commission on Taxes: A customer buys a $100 item with $10 state tax. The total is $110. If the marketplace takes 10% of $110 ($11), they are illegally taking a cut of government tax money. Commission must always be calculated against the product subtotal, exclusively.
Using Floats: Writing let fee = 100.00 * 0.15; in JavaScript. Due to binary floating-point precision issues, this can occasionally result in numbers like 14.9999999999. Always use integers (cents) or specialized decimal libraries.

Tradeoffs and Alternatives

MoR (Merchant of Record) vs. Direct Charges:
- Destination Charges (Direct): The customer's money goes directly to the vendor's Stripe account. Stripe automatically routes the commission to the platform. The platform holds very little liability.
- Separate Charges & Transfers (MoR): The platform takes 100% of the money into its own bank account, holds it, and manually transfers $82 to the vendor later. This allows the platform to hold funds to handle refunds easily but requires immense regulatory compliance (Money Transmitter Licenses).

Interview Questions

Why must you never calculate a marketplace commission on the Grand Total (which includes tax)?
Explain why storing currency as an Integer (in cents) is architecturally superior to storing it as a Float or Decimal.
How do you design a system to handle a vendor's balance going negative due to a customer chargeback?

Hands-On Exercise

Assume a cart has Item A ($50) and Item B ($50).
The platform takes a 20% commission on Category A, and a 10% commission on Category B.
The payment gateway charges a flat 3% on the gross total.
Calculate the exact dollar amounts assigned to the Gateway, the Platform, and the Vendor. (Answers: Gateway: $3. Platform: $10 + $5 = $15. Vendor: $82).

Key Takeaways

Revenue models are complex rules engines that must evaluate categories, tiers, and exclusions.
Never calculate commission on taxes; carefully consider if commission applies to shipping.
Store all currency values as integers (cents) to prevent floating-point rounding errors.
Ensure the database schema enforces strict mathematical constraints (Gross = Fees + Net).