Dropship Partner Cabinet for OpenCart

The Dropship Partner Cabinet module adds a complete dropshipping partner management system to OpenCart. The extension combines partner registration, personalized prices, order creation, balance accounting, fund reservation, payouts, product XML (YML) feeds, and notifications in one dedicated cabinet.

Each partner receives a dedicated workspace where they can create orders for their customers, select a financial model, manage personal feeds, submit balance top-up and payout requests, review the financial journal, and configure notifications.

The administrator manages partners, available products, minimum markups, delivery and payment methods, order statuses, balances, payouts, the feed queue, and notification channels. Every financial change is recorded in a separate journal.

How the module works

1. A customer registers on the website and applies to join the partner program
2. The administrator reviews the application, configures personal terms, and approves the partner
3. The partner receives access to a dedicated dropshipping cabinet
4. Partner prices are calculated from the product cost price and the administrator's minimum markup
5. The partner can create orders for their customers without using the theme's standard cart
6. Each order is created as a complete OpenCart order and appears in the standard administration area
7. Financial operations follow the selected model: buyout / prepayment or commission sales
8. The partner can create static product XML (YML) feeds with personalized prices
9. Order, payout, top-up, and feed statuses can be sent by email or Telegram

Module features

• Accept applications to join the partner program
• Create partners manually in the administration area
• Move approved partners to a dedicated customer group
• Store the original customer group and restore it after a partner is blocked or deleted
• Set global and personal minimum markups
• Create markup rules for individual products, categories, and manufacturers
• Support percentage and fixed markups
• Create dropshipping orders through a dedicated form
• Work with the buyout / prepayment model
• Work with the commission model
• Track balance, reserved funds, pending earnings, and the amount available for payout
• Account for outbound and return delivery
• Create balance top-up requests
• Create payout requests
• Record every change in the financial journal
• Create multiple personal feed profiles for one partner
• Generate static XML (YML) feeds compatible with Prom.ua import
• Select feed language, currency, products, categories, manufacturers, and fields
• Map store categories to marketplace categories through portal_category_id
• Generate full feeds for initial import and compact feeds for fast price and stock updates
• Generate feeds manually or through a protected CRON task
• Send notifications through Telegram, email, or both channels
• Show administrators new applications, orders, payouts, top-ups, and feed errors
• Support Ukrainian, English, and Russian

Dropshipping partner registration

A partner is a regular registered store customer for whom a separate partner profile is created. When applying, the customer provides:

• Store name
• Store URL
• Contact email address
• Phone number in international format

The administrator can approve, reject, or block an application. Only a partner with the Approved status receives access to the working sections.

After approval, the module moves the customer to the configured dropshipping customer group. The original group is remembered and restored after the partner is blocked, rejected, or deleted.

The administrator can also create a partner manually for an existing customer account.

Partner details

In the cabinet, the partner can edit their contact and payment details:

• Store name
• Store URL
• Contact email address
• Phone number
• Payout recipient
• Tax ID / Company registration number
• IBAN

The partner can see their unique ID. It can be included in a payment reference so the administrator can reliably identify the payer when processing a balance top-up.

Cost price

All calculations are based on the product cost price stored in product.cost. The modification adds a cost price field to the standard product editing form.

If the cost column has already been created by another purchase price module, Dropship Partner Cabinet uses the existing field. The cost column is not removed when this module is uninstalled.

A product with a zero cost price cannot participate in partner sales and is not exported to personal feeds.

Minimum markup rules

The administrator defines the minimum price below which a partner cannot sell a product. The calculation starts with the cost price.

Example: the cost price is 1,000 and the administrator's minimum markup is 5%. The partner's settlement price is 1,050.

The module supports:

• A global minimum markup for all partners
• A personal minimum markup for an individual partner
• Rules for a specific product
• Rules for a category
• Rules for a manufacturer
• Percentage markup
• Fixed amount

Rule priority:

1. Individual product
2. Category
3. Manufacturer
4. Partner's personal markup
5. Module's global markup

If a product belongs to several categories with different rules, the rule that produces the highest final price is used.

Priority example: the manufacturer markup is 5%, the category markup is 8%, and a fixed amount of 150 is assigned to the product. For a product with a cost price of 1,000, the product rule takes priority and the settlement price is 1,150.

Creating orders

The partner creates orders through a dedicated cabinet form. The theme's standard cart and checkout are not used.

1. The partner selects a financial model
2. Finds a product by name, model, or SKU
3. Adds products to the order table
4. Specifies the required quantity
5. Sets their own selling price when needed
6. Enters the actual recipient's details
7. Selects a delivery and payment method
8. Creates the order

Autocomplete shows current product availability. Out-of-stock products are not hidden, but are clearly marked as unavailable. A quantity exceeding the available stock cannot be added.

The created order is compatible with the standard OpenCart order system. The partner remains the customer in the standard order, while the delivery details belong to the actual recipient.

Buyout / prepayment financial model

This model is suitable when the partner has already received payment from the buyer and must pay the store the settlement cost of the products.

Example:

• Cost price — 1,000
• Store's minimum markup — 5%
• Settlement amount — 1,050
• Partner's selling price — 1,260

When the order is created, 1,050 is reserved on the partner's balance. After successful completion, the reserved amount is permanently deducted.

If the available balance is insufficient, the order is still saved but receives the financial status Insufficient funds — awaiting top-up. The administrator sees a warning and should not process the order until the balance has been replenished.

After a top-up, setting a processing status again attempts to create the reserve. The order cannot be completed without successfully reserving the settlement amount.

Commission financial model

The commission model is used when the store receives payment directly from the recipient and the partner earns the difference between the selling price and the settlement amount.

Example:

• Store settlement amount — 1,050
• Recipient's selling price — 1,260
• Partner earnings — 210

After the order is handed over to the delivery service, 210 is recorded as pending earnings. Once the order is successfully completed, this amount becomes available for payout.

No advance balance top-up is required for a commission order. If the order is cancelled or returned, pending or already confirmed earnings are reversed.

Order statuses

The administrator maps OpenCart statuses to the processing stages of dropshipping orders:

• Initial status — a new order that has not yet entered processing
• Order accepted for processing — the administrator has started assembling the order
• Handed over to delivery service — the shipment has been given to the carrier
• Order completed — the recipient has received the order
• Order cancelled — the order was cancelled or the shipment was returned

Several OpenCart statuses can be assigned to one financial action. The same status cannot be used for different stages at the same time.

Reapplying the same status does not create duplicate reservations, deductions, or accruals. The module checks the order's current financial state before every operation.

The partner can see the order status history, dates, and administrator comments in the cabinet.

Recipient and delivery field builder

The administrator can create a custom set of order form fields and separate fields for every delivery method.

The following settings are available for every field:

• Technical code
• Name in all store languages
• Field type
• Order field where the value will be stored
• Required status
• Status
• Sort order

Regular text fields, multiline fields, a country list, and a dependent region / state list are supported.

Countries and regions are loaded from the store's local database. After a country is selected, the partner receives the corresponding list of regions.

Values from several fields can be directed to shipping_address_1 or shipping_address_2. The module combines them into a readable value with localized field names.

Example: “Street: Heroiv, Building: 22, Apartment: 3”.

Delivery and payment methods

The administrator creates the delivery methods and recipient payment methods available to partners.

Each delivery method has:

• A technical code, for example dropship.novapost
• A name in all store languages
• Status
• Sort order
• A custom set of fields

Courier delivery can request a city, street, building, and apartment. Branch delivery can request a city and branch number. Parcel locker delivery can request a city and locker number.

The technical delivery code is stored in shipping_code and the localized name in shipping_method. The payment code is stored in payment_code and its name in payment_method.

Outbound and return delivery

For every order, the administrator separately specifies:

• Who pays for delivery
• Actual outbound delivery cost
• Delivery comment
• Return delivery cost
• Return comment

If a successful delivery is paid by the recipient, its cost is not deducted from the partner's balance. If the partner pays for delivery, the actual amount is deducted from their balance.

If a shipment is returned, both outbound and return delivery costs are charged to the partner regardless of who was initially selected as the payer.

Before setting the shipped or completed status, the administrator must confirm the outbound delivery cost, even if it is zero. Cancellation requires separate confirmation of both outbound and return delivery.

Balance and reserved funds

The financial system separates several indicators:

• Balance — the partner's own funds
• Reserved funds — funds reserved for buyout orders
• Pending earnings — income from commission orders that have not yet been completed
• Available for payout — confirmed income from completed commission orders

The amount available for payout includes the free balance not currently reserved and confirmed commission earnings.

The administrator can manually credit or debit a partner's balance. The adjustment reason is saved in the financial journal and can be sent to the partner as a notification.

Balance top-ups

The administrator enters the store's payment details in the module settings:

• Payment recipient
• Tax ID / Company registration number
• IBAN
• Support phone numbers
• Support email address

The partner sees these details in the cabinet, makes a payment, and submits a top-up request. The request includes the amount and information the administrator can use to locate the payment.

The administrator verifies receipt and approves or rejects the request. The balance increases only after manual approval.

Partner payouts

A partner can submit a payout request for an amount that does not exceed their free balance and confirmed earnings.

To submit a request, the partner must provide:

• Recipient
• Tax ID / Company registration number
• IBAN

Funds are not transferred automatically. The administrator reviews the request, makes the payment manually, and assigns a status:

• Pending
• Paid
• Rejected

If a pending request is rejected or deleted, the amount reserved for payout is returned to the partner.

Financial journal

Every financial operation is recorded in a separate journal:

• Reserving funds for an order
• Deducting the settlement amount
• Releasing a reserve
• Refunding product cost
• Deducting outbound delivery
• Deducting return delivery
• Accruing pending earnings
• Confirming commission earnings
• Balance top-up
• Payout
• Manual administrator adjustment

For order-related operations, the order number and a link to the order are displayed. The journal shows changes to the balance, reserved funds, pending earnings, amount available for payout, and the comment.

Personal XML (YML) feeds

Every approved partner can create personal static product feeds. The maximum number of profiles is set globally by the administrator or individually for a particular partner.

A feed profile contains:

• Custom name
• Language
• Currency
• Product availability mode
• Categories
• Manufacturers
• Additional markup
• Personal markup rules
• XML (YML) field set

The partner can export:

• All products
• Only in-stock products
• Only out-of-stock products

The administrator can restrict the categories and manufacturers that partners are allowed to use in their feeds.

XML (YML) feed fields

The partner independently selects the data to export:

• Product name
• Category
• Description
• Price
• Stock quantity
• Product URL
• Main and additional images
• Manufacturer
• Model
• SKU
• Attributes
• Weight
• Dimensions
• GTIN
• MPN

The offer identifier and availability flag are always generated. The field used as the offer ID is selected by the administrator in the module settings.

The full field set is suitable for the initial product import. A compact feed containing, for example, only price and stock can be used to update an already imported catalog quickly.

Feed language and currency

For each profile, the partner selects one of the active store languages. Product names, descriptions, categories, and attributes entered in that language are included in the feed.

The module does not translate content automatically. If catalog data has not been entered in the required language, it cannot be generated automatically in the feed.

Prices are converted to one of the store's active currencies. The selected currency code is passed in currencyId.

Prom.ua categories

A numeric Prom.ua marketplace category ID can be specified for every store category. When filled in, the module exports it in the portal_category_id tag.

This maps the store's own catalog structure to marketplace categories without changing the categories in the store.

Feed markups

The feed's additional markup is applied after the administrator's minimum price.

Example:

1. Cost price — 1,000
2. Administrator's minimum markup — 5%
3. Settlement price — 1,050
4. Feed's own markup — 20%
5. Feed price — 1,260

The profile markup can be overridden for a specific product, category, or manufacturer. Personal feed rule priority is: product, category, manufacturer, then the profile's global markup.

Static files and CRON

Feeds are generated as static XML files. Requests from an external system to a feed URL do not run heavy SQL queries or rebuild the catalog in real time.

• A partner can manually add their feed to the update queue
• The feed URL remains unchanged after regeneration
• A product, price, or stock change queues related feeds without deleting the previous file
• While a new version is generated, the previous successful file and its URL remain available
• Feeds are processed in batches
• Each CRON call uses the available PHP execution time and keeps a safety margin before the server limit
• When the time limit is reached, the next call resumes from the last processed product

Notifications

The partner can select a notification channel:

• Telegram
• Email
• All channels

Available event types:

• Order status change
• Feed generated successfully
• Feed generation error
• Payout status change
• Balance adjustment
• Top-up request status change

Payout and top-up messages include the operation amount, new status, and administrator comment.

For Telegram, the administrator enters the bot token and each partner enters their own Chat ID. A separate Mail or SMTP transport can be configured independently of the store's main email settings.

Administration area

After installation, a dedicated dropshipping cabinet section appears in the administration area's left menu.

Administrators have access to:

• General settings
• Partner list
• Adding and editing partners
• Dropshipping orders
• Payout requests
• Top-up requests
• Financial journals
• Feed list and queue
• Delivery and payment settings
• Order status settings
• Telegram and email settings
• Complete built-in documentation

The administration header notification widget shows:

• New partner applications
• New dropshipping orders
• Top-up requests
• Payout requests
• Feeds with errors

The standard OpenCart order page displays a dedicated label linking to the dropshipping order and showing its financial status.

Dropshipping cabinet pages

The demo cabinet contains the following pages:

• Dropshipping Cabinet — dashboard with financial indicators and quick links
• Partner Details — partner store, contacts, and banking details
• Dropshipping Orders — list of orders created by the partner
• New Order — dedicated form for creating an order for a recipient
• Personal Feeds — profile list, generation statuses, and static URLs
• New Feed Profile — create a personal XML (YML) feed
• Finances and Payouts — balance, top-ups, payouts, and financial journal
• Notifications — Telegram, email, and event type settings

You must sign in with an approved partner account to view the working pages.

Security and data separation

• All orders, finances, feeds, and notifications are linked to the internal partner_id
• A partner cannot view another partner's data
• Deleting a partner does not assign their previous orders to a new account
• Financial operations use a separate transaction journal
• Reprocessing a status does not duplicate deductions or accruals
• CRON is protected by a secret key
• Access to administration pages is controlled by the standard access and modify permissions

Performance

• Static XML files instead of generation on every request
• Batch processing of queued products
• Resume generation from the last processed product
• Use of the PHP time limit with a safety margin before process termination
• Selection of only the fields required for a particular feed
• Dedicated table indexes for partners, orders, finances, and the feed queue
• Preservation of the previous working file until the new generation completes successfully
• Support for catalogs containing tens of thousands of products

Open source code and independence

The module code is not encoded or obfuscated. PHP, Twig, JavaScript, and XML files are available for viewing and editing.

The module does not use a license server, hidden telemetry, or remote libraries. Core calculations, orders, financial accounting, and feed generation are performed directly on the website.

External connections are made only for channels explicitly configured by the administrator: the Telegram bot, SMTP, and retrieval of static files by an external import system.

Theme compatibility

The module's customer-facing pages are adapted for the standard OpenCart theme. Third-party themes can use a different HTML structure, CSS classes, grid, and form styling, so the partner cabinet pages require a separate theme adaptation to display correctly.

Theme adaptation is not included in the base module package and is performed separately for the specific theme used by the store.

System requirements

• OpenCart 3.0.3.x
• PHP 7.4–8.5
• MySQL or MariaDB
• Configured store base currency
• Completed product.cost values
• Write access for static XML files
• Ability to configure a recurring CRON task
• Telegram bot token for Telegram notifications
• Configured Mail or SMTP for email notifications

Installation

1. Perform a clean installation of the main package through Extensions / Installer
2. Go to Extensions / Modifications and refresh the modification cache
3. Go to Extensions / Extensions
4. Select the Modules extension type
5. Find Dropship Partner Cabinet and click Install
6. Open the settings and enable the module
7. Select the partner customer group
8. Configure minimum markups
9. Configure order statuses
10. Create delivery and payment methods
11. Enter the store's payment details
12. Configure Telegram and the email transport
13. Add the CRON URL to the scheduler
14. If needed, install the Dropshipping Cabinet Navigation module in the required layout position

Uninstalling the module

Disabling the module does not delete partners, orders, financial history, or feed files.

A complete uninstall removes the module's own tables, events, and generated static feed files. Partners are returned to their original customer groups before removal.

The product.cost column is not removed because it may be used by other cost price modules.

We recommend creating a database backup before uninstalling the module from a live store.

Important notes

The module does not perform automatic bank transfers and does not connect to a payment system. Top-ups and payouts are reviewed and approved manually by the administrator.

For correct financial accounting, do not edit the module's own database tables manually. Balance, reserved funds, delivery costs, and commission earnings must be changed through the provided pages and statuses.

Products without a cost price cannot participate in partner calculations. Before launching the partner program, product.cost must be completed for the available catalog.

A recurring CRON task is required to update feeds automatically and process deferred notifications. The execution frequency depends on catalog activity and the number of partner feeds.

Theme compatibility

The module's customer-facing pages are adapted for the standard OpenCart theme. Third-party themes can use a different HTML structure, CSS classes, grid, and form styling, so the partner cabinet pages require a separate theme adaptation to display correctly.

Theme adaptation is not included in the base module package and is performed separately for the specific theme used by the store.

License

The license covers one domain and its subdomains.