White-label vs reseller vs OEM — which one are you signing?
The three models all put one company's software into another company's sales channel, and they get drafted interchangeably — which is how providers end up supporting customers they never contracted with, and partners end up liable for products they do not control. The sorting question is simple: whose brand does the end customer see, and who do they call when it breaks? If the answer is the channel partner on both counts, you are in white-label territory; if the customer knows the provider's product by name, you want a reseller or distribution agreement instead.
| White-label | Reseller | OEM / embedded | |
|---|---|---|---|
| Whose brand the end customer sees | The partner's brand only. The provider is invisible — its name appears nowhere in the product, the contract or the support experience. | The provider's brand. The reseller sells the provider's named product and the customer knows exactly whose software it is. | The OEM's brand on the combined product; the embedded component may or may not be disclosed ("powered by" is a negotiated point). |
| Who contracts with the end customer | The partner papers the customer on its own terms, subject to flow-down minimums imposed by the provider. | Usually the provider's EULA or subscription terms bind the end customer; the reseller intermediates commercially (orders, invoicing). | The OEM contracts for its whole product; the component licence sits upstream between provider and OEM. |
| Who supports the end customer | The partner is the only face the customer sees (L1); the provider works behind the curtain at L2/L3 on a back-to-back SLA. | Typically the provider supports directly, or the reseller handles first-line with open escalation to the provider. | The OEM supports its product; component-level support flows back-to-back to the provider, invisible to the customer. |
| Who owns the customer relationship | The partner — that is the commercial point of the deal. The fight is over what the provider may do with those customers after termination. | Contested. The provider usually knows the end customers (licence registration) and often deals with them directly on renewal. | The OEM, unambiguously. The provider sells a component, not a customer-facing product. |
| Typical SA example | A payments or lending platform rebranded by a bank; practice-management software sold under an industry body's brand. | An IT firm reselling Microsoft 365 or Sage licences to its client base. | A mapping or OCR engine embedded inside a fleet-tracking or document product. |
Misclassification is expensive in both directions. Paper a white-label deal on a reseller template and the partner has no brand licence, no L1 support obligation and no flow-down architecture — the provider's terms bind customers who have never heard of the provider. Paper a reseller deal on a white-label template and the provider has handed over support tiering and customer ownership it never intended to give away.
The nine clauses that matter
Brand licence — each way
The unusual one: the partner licenses its trade marks to the provider so the provider can apply them to the product, UI and documentation. Brand guidelines, approval rights over how marks are rendered, quality control (without which a bare trade-mark licence risks dilution arguments), and immediate strip-out obligations on termination.
Product IP ownership + improvements and feedback
The provider retains all IP in the product, including improvements, bug fixes and features built in response to partner feedback. A broad feedback-assignment or feedback-licence clause prevents the partner later claiming rights in features it "suggested". Partner-commissioned bespoke features are the exception that needs express treatment.
End-customer contract architecture
The partner papers the end customer in its own name — but the provider imposes flow-down minimums: licence scope limits, warranty disclaimers, liability caps, acceptable-use rules and data terms the partner's customer contract must contain. If the partner under-papers, the indemnity clause decides who absorbs the gap.
Support tiering + back-to-back SLA
The partner is L1 — the only support face the customer ever sees. The provider sits at L2/L3, invisible. The provider-to-partner SLA must be at least as strong as the partner-to-customer SLA (response times, severity definitions, escalation paths), or the partner is contractually promising service levels it cannot deliver.
Data roles under POPIA
For end-customer personal information the partner is usually the responsible party (its customer, its purposes) and the provider an operator — which makes written section 21 operator terms mandatory: security safeguards, breach notification to the partner, sub-operators, cross-border hosting under section 72. Carve out analytics and derived/aggregated data expressly: providers want usage telemetry to improve the product, and silence breeds disputes.
Exclusivity + territory and segment
Whether the partner gets the product exclusively in a territory, industry vertical or customer segment — and what it pays for that in minimum commitments. Define the boundary precisely (named competitors? segment definitions?) and what happens to exclusivity if minimums are missed: conversion to non-exclusive beats termination.
Pricing, minimums + true-ups
Per-seat, per-transaction or revenue-share pricing; minimum volume or revenue commitments that underwrite the exclusivity; audit rights and periodic true-ups where the provider cannot see end-customer billing directly. Index pricing or build review gates for multi-year terms.
Liability + indemnities in both directions
Two distinct risk streams. The provider indemnifies for what it controls: product defects, security failures, third-party IP infringement in the product. The partner indemnifies for what it controls: its sales conduct, marketing claims, mis-selling and any customer terms beyond the agreed flow-downs. Caps and carve-outs must track that split — a single mutual cap usually misallocates the risk.
Termination + customer continuity
The existential clause. Live end customers are mid-contract with the partner when the white-label deal dies — do they follow the brand (partner migrates them to a replacement product) or the product (provider takes them over, now visibly)? Draft the wind-down period, migration assistance and data-export obligations, non-solicitation of each other's customers, and code/data escrow options for provider-failure scenarios — in advance, while the parties still like each other.
The invisibility problem
The provider's invisibility is the partner's biggest asset and its biggest exposure. When the product goes down, the outage happens under the partner's brand: the partner's customers flood the partner's support desk, the partner's reputation absorbs the damage, and the partner's churn statistics carry the scars — while the party actually able to fix the problem sits behind a curtain. Standard SLA service credits, calibrated as a percentage of the monthly fee, do not begin to compensate for brand damage. Partners with leverage negotiate beyond credits: termination rights for chronic failure (defined objectively — say, three SLA breaches in any six-month window), liability carve-outs for security failures, and in serious deals, direct compensation mechanics keyed to demonstrated customer churn following a major incident.
Just as important is the incident communication protocol. In an outage or data breach, the partner must speak to customers immediately — but only the provider knows what actually happened. The agreement should hard-code the information flow: provider notification to the partner within a defined number of hours, a named incident channel, pre-agreed holding statements the partner can issue under its own brand, and a strict prohibition on the provider communicating with end customers directly (which would shatter the white-label fiction at the worst possible moment). For personal-information breaches, this protocol must dovetail with the section 22 POPIA notification duties that sit with the partner as responsible party.
Termination war-gaming — three scenarios to draft in advance
Every white-label termination strands a third group who never signed the agreement: the end customers. They are mid-contract with the partner, running their businesses on a product the partner no longer has rights to. The continuity clauses cannot be negotiated at termination — by then the parties' interests have fully diverged — so the agreement should war-game the three endings up front:
Scenario 1 — the partner walks
The partner terminates to move to a competitor or an in-house build. The agreement must already answer: how long is the migration window, in what format does end-customer data export, what run-off support does the provider owe (and at what price), and is the provider barred from approaching the partner's customers directly during and after the wind-down?
Scenario 2 — the provider pulls the product
The provider terminates, sunsets the product or is acquired by the partner's competitor. The partner has live customers on contracts it can no longer perform. Pre-agree a minimum wind-down period (12–24 months for enterprise customers), continued support and security patching for the duration, and a licence tail that survives long enough for an orderly migration.
Scenario 3 — the provider fails
Insolvency or business rescue. A business-rescue moratorium can freeze the partner's contractual remedies precisely when it needs them most, so the protections must be structural, not contractual promises: source-code and data escrow with insolvency-trigger release, deposit-refresh obligations, and hosting arrangements the partner can step into or replicate.
Frequently asked
What is the difference between a white-label agreement and a reseller agreement?
Visibility. A reseller sells the provider's product under the provider's brand — the end customer knows whose software it is, and the provider typically papers and often supports the end customer directly. In a white-label deal the provider is invisible: the product carries the partner's brand, the partner contracts with and supports the end customer, and the provider operates behind the curtain. That inversion changes the whole design — support must be tiered (partner L1, provider L2/L3 back-to-back), liability must be split between product defects and sales conduct, and termination must deal with customers who do not even know the provider exists.
Who owns the end customers in a white-label arrangement?
Commercially, the partner — the customers contract with the partner, know only the partner's brand, and the customer relationship is the main asset the partner is building. But "ownership" is only as good as the termination clause: if the provider can market to those customers the day after termination, or the partner has no data-export and migration rights, the ownership is illusory. Well-drafted agreements pair customer-relationship ownership with mutual non-solicitation, defined data-export formats, and a migration window long enough to move customers without breaching their contracts.
Who is liable when the product fails under the partner's brand?
To the end customer: the partner, because the partner is the contracting party — the customer usually has no claim against a provider it has never heard of. Between the parties: whoever caused the failure. The agreement should route product defects, downtime and security failures to the provider through an indemnity and a back-to-back SLA, and route mis-selling, over-promising and unauthorised customer terms to the partner. If the partner's customer contract failed to include the agreed flow-down disclaimers and caps, the partner typically absorbs the uncapped exposure it created.
Can the provider sell to the partner's customers after termination?
Only if the agreement allows it — and this is one of the most heavily negotiated exit points. Providers argue the customers are users of their product who deserve continuity; partners argue the customer list is their confidential information and goodwill. Common landing zones: a non-solicitation period (12–24 months) barring the provider from targeting the partner's customers, an exception where a customer approaches the provider unprompted, and sometimes a paid customer-transfer mechanism where the provider takes over willing customers for a per-customer or revenue-share fee.
How do POPIA roles work in a white-label deal?
For end-customer personal information, the partner is usually the responsible party — they are its customers and it determines the purposes — and the provider processes that data as an operator, making written section 21 operator terms mandatory (security safeguards under section 19, breach notification, sub-operator controls, and section 72 mechanics if hosting is offshore). The provider is, however, a responsible party in its own right for data it uses for its own purposes — typically usage analytics and product telemetry. The agreement should carve those flows out expressly, ideally limited to aggregated or de-identified data, rather than leaving the provider's analytics use squatting inside the operator relationship.
Does exclusivity change the pricing?
It should. Exclusivity is the provider giving up every other route to a territory or segment, so it is almost always tied to minimum volume or revenue commitments that underwrite the bet. The partner pays for exclusivity either in higher unit pricing or in minimums with true-up payments when actuals fall short. The drafting points that prevent disputes: define the exclusive field precisely (territory, vertical, named-competitor list), state what happens when minimums are missed — conversion to non-exclusive is usually better for both sides than termination — and give the partner audit-able data on any provider sales that allegedly breach the exclusivity.
Who owns improvements to the product — and what about features we paid for?
General improvements, including those prompted by partner feedback, stay with the provider — that is standard and commercially necessary, since the provider maintains one codebase for all partners. Partner-commissioned custom features are different: under the Copyright Act's section 1(1) definition, the author of a computer program is the person who exercised control over its making — the principle applied in Haupt v Brewers Marketing Intelligence — so a partner that genuinely directs and controls a bespoke build may own it without any assignment. In practice the provider's standard terms reverse this, so the partner must negotiate expressly; and any assignment of copyright is only valid under section 22(3) if it is in writing and signed. The cleanest pattern: provider owns the platform and generic improvements, partner owns (or gets an exclusive licence to) the bespoke modules it paid for.
What does a bespoke white-label agreement cost in SA?
From R14,000 for a bilateral provider–partner agreement covering brand licensing both ways, support tiering, flow-down minimums, POPIA operator terms and termination continuity. Multi-territory or multi-partner frameworks, escrow arrangements and heavily negotiated exclusivity structures are quoted on scope.