Updated: 2026-06-23
The Reseller system is Dujiao-Next's built-in white-label, multi-tenant distribution model. A reseller runs their own standalone storefront (a dedicated domain with custom branding) and sells your products at a self-set markup on top of the base price — the difference between the reseller price and the base price is the reseller's profit. Buyers place and pay for orders on the reseller's storefront, while the main site fulfills them centrally. Reseller profit is settled to the reseller's account after a confirmation period, and the reseller can request withdrawals.
Difference from the Affiliate Program
This system and the Affiliate Program are two independent features — do not confuse them:
| Dimension | Affiliate | Reseller (this doc) |
|---|---|---|
| Model | Referral links + commission rebate | White-label storefront + self-set pricing margin |
| Storefront | Shares the main site | Dedicated domain, independent branding |
| Buyer perception | Still shopping on the main site | Shopping on the reseller's branded site |
| Revenue source | Order amount × commission rate | Reseller price − base price (margin profit) |
| Best suited for | Individual promotion / traffic | Channel agents / second-tier merchants |
| Module | Description |
|---|---|
| Application & Review | Users apply to become resellers; admins review and set markup limits |
| Domain Binding | System subdomain (assigned by admin) or custom domain (reviewed by admin) |
| White-Label Site | Custom site name, logo, favicon, announcement, SEO, navigation, footer, theme |
| Products & Pricing | List/unlist products, 4 pricing modes for self-set markup |
| Order Fulfillment | Buyers order on the reseller site; the main site fulfills centrally |
| Profit Settlement | Profit posting → confirmation period → withdrawable, ledgered per currency |
| Withdrawal | Resellers request withdrawals; admins review and pay out offline |
| Risk Control | Self-dealing / related-account profit blocking; pricing floor prevents platform loss |
Reseller mode is disabled by default. Enable it in the reseller section of the backend config.yml:
reseller:
enabled: false
# List of main-site hosts. After enabling reseller mode, put the production main-site domains here.
# Requests matching main_hosts are handled as the main-site context; otherwise reseller domains are resolved.
main_hosts:
- localhost
- 127.0.0.1
- "::1"
# Enable only when the reverse proxy is trusted and forwards Host correctly.
# false uses the raw Host; true prefers X-Forwarded-Host.
trusted_forwarded_host: false
# Base domain used when an admin assigns a system subdomain, e.g. hello.{subdomain_base}.
# Before enabling in production, set it to a domain with wildcard DNS/TLS ready, e.g. shop.example.com.
subdomain_base: ""
# Whether ordinary users may self-submit a reseller application from the personal center.
self_apply_enabled: true
# Confirmation days before posted reseller profit becomes "withdrawable" (0 = instant, max 3650).
settlement_confirm_days: 7| Option | Description |
|---|---|
enabled | Master toggle for reseller mode |
main_hosts | List of main-site hosts; matches are handled as the main-site context |
trusted_forwarded_host | When the reverse proxy is trusted, prefer X-Forwarded-Host for domain detection |
subdomain_base | Base domain for system subdomains (requires wildcard DNS/TLS set up in advance) |
self_apply_enabled | Whether users may self-apply from the personal center |
settlement_confirm_days | Profit confirmation days; 0 for instant, max 3650 |
Production prerequisites
main_hosts, otherwise main-site requests may be misidentified as a reseller site.subdomain_base must point to a domain with wildcard DNS (*.shop.example.com) and a wildcard TLS certificate configured.Host/X-Forwarded-Host to the backend — reseller domain resolution relies on that header.User applies → Admin reviews (sets markup limit) → Assign/bind domain
→ Reseller configures site + product pricing → Go live
→ Buyer orders & pays on reseller site → Profit posted (confirmation period)
→ Becomes withdrawable on maturity → Reseller requests withdrawal → Admin reviews & paysUsers can self-apply only after the admin enables
enabledandself_apply_enabled: trueinconfig.yml.
| Status | Identifier | Description |
|---|---|---|
| Pending Review | pending_review | Submitted, awaiting admin review |
| Active | active | Approved; reseller identity is in effect |
| Rejected | rejected | Rejected; the user may edit the reason and reapply |
| Disabled | disabled | Disabled by admin; the reseller site goes offline immediately and cannot reapply |
A rejected (
rejected) user can submit again; a disabled (disabled) user cannot self-reapply and must contact the admin for restoration.
Manage the reseller lifecycle under "Reseller Management → Reseller Review" in the admin panel.
| Action | Description |
|---|---|
| Approve | Set the "default markup percent" and "max markup limit"; reseller identity takes effect |
| Reject | Provide a rejection reason; the user may reapply |
| Disable | Immediately take all of the reseller's domains offline (reseller site returns unavailable) |
| Restore | Restore a disabled reseller back to the active state |
When approving or editing later, the following reseller-level parameters can be adjusted:
| Parameter | Description |
|---|---|
| Default markup percent | The uniform markup percentage applied when a product/SKU has no individual pricing |
| Max markup limit | Hard cap on a single item's implied markup; exceeding it fails order/display validation (0 = no limit) |
| Settlement status | normal / frozen; once frozen, the reseller is barred from withdrawing |
┌──────────────┐
Application ─▶ │ pending_review│
└──────┬───────┘
approve │ │ reject
▼ ▼
┌────────┐ ┌──────────┐ reapply
│ active │ │ rejected │ ─────────▶ pending_review
└───┬────┘ └────┬─────┘
disable │ │ disable
▼ ▼
┌──────────────────┐
│ disabled │ ──restore──▶ active
└──────────────────┘The reseller site identifies the tenant context by domain, and supports two domain types.
Assigned by the admin in the panel, based on subdomain_base in config.yml:
subdomain_base: shop.example.com, assigning the subdomain hello yields hello.shop.example.comThe reseller submits their own domain (e.g. shop.mybrand.com) under "Domain Management" in the storefront:
In the current version, custom domains go through manual admin review; automatic DNS verification is not yet enabled. The submitted domain cannot be a main-site domain or
subdomain_baseand its subdomains.
| Dimension | Values |
|---|---|
| Binding status | pending_review / active / disabled |
| Verification status | pending / verified / failed |
| Primary domain | is_primary; each reseller has exactly one primary domain |
Resellers customize their storefront appearance under "Site Configuration" in the storefront. All text fields support multiple languages (matching the main site):
| Option | Description |
|---|---|
| Site name | Reseller site title |
| Logo / Favicon | Site logo and browser icon |
| Announcement | Homepage announcement content |
| Support info | Customer support contact / entry |
| SEO | Title, description, keywords, etc. |
| Navigation | Top navigation menu |
| Footer links | Bottom link area |
| Theme | Site theme / color scheme |
The reseller identity must be "active" to edit the site configuration. Images are submitted via the reseller console's upload endpoint.
is_listed) under "Product Management"Each product / SKU can independently choose a pricing mode:
| Mode | Identifier | Calculation |
|---|---|---|
| Inherit | inherit | Use the base price, no markup (or fall back to the upper-level rule) |
| Percentage markup | markup_percent | base price × (100 + markup%) / 100 |
| Fixed markup | fixed_markup | base price + fixed markup amount |
| Fixed price | fixed_price | Directly specify the reseller price |
Pricing is resolved top-down in the following priority, adopting the first non-"inherit" rule encountered:
SKU-level setting ▶ Product-level setting ▶ Reseller default markup ▶ Base price (inherit)inherit, the SKU rule is used firstinherit, the product rule is usedTo prevent platform loss, the reseller price must satisfy all of the following, otherwise order and display validation fails:
The display page tolerates stale/dirty configs: if a SKU fails pricing validation due to changes in base price / cost price / limit, it only hides that SKU and logs a warning instead of breaking the whole product page. Operators should fix the config based on the warning.
reseller_order_snapshot) recording the base price, reseller price, profit, risk-control verdict, etc., which serves as the basis for later profit settlementAfter an order is paid successfully, the system generates an "order profit" ledger entry from the order snapshot:
profit = Σ (reseller price − base price) // accumulated across items in the orderorder_profit, initial status pending_confirmsettlement_confirm_daysA scheduled backend worker batch-converts matured pending_confirm entries to available (withdrawable) and refreshes the balance cache. With settlement_confirm_days: 0, profit is withdrawable instantly.
On order refunds, the system proportionally claws back posted profit and creates a refund_deduct (negative) ledger entry:
pending_confirm), the refund deduction entry also stays pending and uses the same available time, maturing together with the profit — preventing un-matured profit from being deducted into an "available negative balance" that wrongly freezes the accountEach reseller is ledgered independently per currency (reseller_balance_account):
| Field | Description |
|---|---|
| Available balance | Confirmed net amount eligible for withdrawal (including negative entries such as refunds) |
| Locked balance | Amount already in a withdrawal request, awaiting review |
| Negative balance | The owed amount when the available net is negative |
Account status: normal / negative_balance / frozen_review / disabled. Withdrawals are forbidden when in a negative-balance, frozen, or disabled state.
Ledger types:
| Type | Description |
|---|---|
order_profit | Order profit posting (positive) |
refund_deduct | Refund deduction (negative) |
manual_adjust | Manual admin adjustment |
Ledger statuses:
| Status | Description |
|---|---|
pending_confirm | Pending confirmation (within the confirmation period) |
available | Withdrawable |
locked | Locked (in a withdrawal request) |
withdrawn | Withdrawn |
canceled | Voided |
The reseller identity must be "active" with settlement status
normalto withdraw; withdrawals are not allowed when the account is in a negative-balance / frozen / disabled state.
Handled under "Reseller Management → Withdrawal Management" in the admin panel (protected by finance permissions):
During the checkout pricing phase, the system performs self-dealing risk checks. When triggered, that order's profit is not credited to the reseller's account (the buyer is still charged as usual; it simply isn't settled to the reseller):
| Block type | Identifier | Description |
|---|---|---|
| Self-purchase | self_dealing_owner | The buyer is the reseller themselves |
| Related account | self_dealing_related_account | The buyer is flagged as a related account of the reseller |
In addition, the "Pricing Floor" above guarantees at the source that the reseller price is never below the base/cost price, so the platform never loses money on any reseller order.
enabled is turned on in config.yml.subdomain_base; custom domains currently go through manual review.