Order & Commission Management Systems Explained

Order and commission management systems for marketplaces are the operational backbone of every transaction. Every order generates a cascade of state changes, and a commission calculation that must be correct every single time.

Platforms that underdesign this layer spend their first year doing manual reconciliation, fielding vendor disputes about incorrect payouts, and retrofitting logic that should have been built from day one. The architecture is not complex, but it must be deliberate.

Key Takeaways

• Order state machine is the foundation: Every state transition triggers downstream actions including notifications, payment releases, and commission calculations that must be defined before development begins.
• Commission calculation and payment routing are separate: The commission engine resolves the rate and calculates the split; the payment gateway executes it. Conflating these produces systems that are hard to audit.
• Variable rates require a rule engine: Flat rates can be hardcoded; tier-based, category-specific, and vendor-specific rates require a configurable engine that does not need a developer to update.
• Payout timing is a vendor trust lever: Predictable, on-schedule payouts are among the highest-impact vendor retention factors on any marketplace platform.
• Cancellation logic is as complex as fulfilment logic: The reverse path must be specified in as much detail as the forward path; most systems fail at cancellation edge cases.
• Every commission event must be auditable: Vendors who dispute payout calculations need a clear record of how each commission was calculated, not just the result.

Marketplace App Development

Marketplaces Built to Grow

We build scalable marketplace apps with modern no-code technology—designed for buyers, sellers, and rapid business growth.

Let's talk

What Order Management Functionality Is Non-Negotiable?

Order management is part of essential marketplace platform features. Without it, the platform has no reliable record of what happened and no basis for resolving disputes or processing payouts.

The minimum viable order management system includes a state machine, a defined data model, and explicit cancellation handling.

• Order lifecycle definition: Every order must move through a defined sequence of states, from placement through fulfilment to payout, with each state transition logged.
• State machine requirement: Tracking orders as flat database records without state machine logic produces orders that get stuck in ambiguous states requiring manual intervention.
• Order data model baseline: Each order record must include order_id, buyer_id, vendor_id, transaction_value, order_status, commission_rule_id, vendor_net_amount, platform_fee_amount, and payout_status.
• Cancellation as first-class concern: Cancellation before acceptance, after acceptance, and after partial fulfilment are three different scenarios with different commission and refund implications.

The order data model must be designed before any payment integration begins, because the commission and payout fields are part of the record, not additions to it.

How Should the Order State Machine Be Designed?

A well-designed order state machine defines every state, every valid transition, and every action triggered by each transition. Gaps in the diagram become places where orders get stuck.

Here is the full seven-state model that covers the complete order lifecycle for a marketplace platform.

State 1: Pending

The order is placed and payment is authorized but not yet captured. The order is awaiting vendor acceptance.

A timeout rule is required at this state: if the vendor does not accept within a defined window, the order auto-cancels and the authorization is released.

• Payment authorization hold: Funds are reserved but not captured; the buyer's card is not charged until the vendor accepts the order.
• Vendor timeout rule: Auto-cancellation after a defined period of inactivity prevents orders from sitting in pending state indefinitely.
• Notification triggers: Vendor receives a new order alert; buyer receives an order confirmation with an expected acceptance window.
• Auto-cancel on timeout: If the vendor does not act within the defined window, the system cancels automatically and releases the payment hold.

The timeout duration should reflect your platform's expected vendor response time. A 15-minute window works for on-demand; 24 hours is more appropriate for custom services.

State 2: Accepted

The vendor has confirmed the order. Payment is captured and held. Commission calculation is performed and recorded at this transition.

This is the most important state transition in the order lifecycle. The commission_rule_id and resulting split amounts are committed to the order record at this point and should not change.

• Payment capture trigger: Payment moves from authorized to captured when the vendor accepts; the buyer is now formally charged.
• Commission calculation at acceptance: The applicable commission rate is resolved, the split amounts are calculated, and both values are written to the order record.
• Commission record immutability: Once committed at acceptance, the commission record should not be modified; any adjustments should be separate correction records.
• Buyer notification: Buyer receives acceptance confirmation with the expected fulfilment timeline communicated clearly.

Calculating commission at acceptance rather than at completion creates a clean, auditable record that is not affected by fulfilment changes.

State 3: In Fulfilment

The vendor is actively fulfilling the order. For physical goods, tracking information may be added. For services, work is in progress.

This state may have sub-states for complex fulfilment workflows, such as milestone-based delivery or multi-stage projects.

• Tracking number addition: Physical goods marketplaces should allow vendors to add carrier tracking numbers at this state for automatic buyer notification.
• Sub-state support for complex orders: Service marketplaces with milestone-based delivery need sub-states (milestone 1 complete, awaiting client review) within In Fulfilment.
• Buyer communication channel: In-app messaging should be available throughout the fulfilment state so buyers and vendors can coordinate without leaving the platform.
• Estimated completion visibility: Where possible, buyers should see an expected completion date or time based on vendor input at acceptance.

The In Fulfilment state is where most of the work happens and where the least order management activity is required from the platform, unless disputes arise.

State 4: Delivered or Completed

Delivery is confirmed by the buyer, or auto-confirmed after a defined timeout from the delivery notification. The escrow release trigger fires and vendor payout moves to scheduled.

The review window opens at this state for both buyer and vendor.

• Auto-confirmation timeout: If the buyer does not confirm receipt within 48 to 72 hours, the order auto-confirms and payout is scheduled; this prevents buyers from delaying payout indefinitely.
• Escrow release trigger: Payment moves from held to scheduled-for-payout at this transition; the payout date is set according to the platform's payout schedule.
• Review window activation: Both buyer and vendor can leave a review during the review window period; reviews are locked after the window closes.
• Payout schedule commitment: The vendor sees their expected payout date immediately when the order completes; this is the transparency that builds trust.

Auto-confirmation timeout is one of the most frequently underspecified rules in marketplace order management. Define it explicitly before launch.

State 5: Disputed

Either party has raised a dispute. Payout is paused and the dispute resolution workflow is initiated.

A dispute can be entered from In Fulfilment or from Delivered, meaning a buyer can dispute after auto-confirmation in cases of significant quality failure.

• Payout pause on dispute: Vendor payout is held the moment a dispute is opened; funds are not released until the dispute is resolved.
• Evidence submission requirement: Both parties must be able to submit evidence (text and images) through the dispute interface before the admin reviews.
• State re-entry from Delivered: A buyer must be able to open a dispute after auto-confirmation within a defined window, typically five to seven days post-completion.
• Resolution transitions: A resolved dispute transitions the order to Completed (with original or adjusted payout) or Cancelled (with full or partial refund).

The dispute state is where poorly designed systems fail most visibly. The evidence submission flow and the payout hold mechanism must be built before the platform handles real money.

State 6: Cancelled

Cancellation has three distinct scenarios with different financial implications. Each must have a defined resolution path.

Pre-acceptance cancellation means full refund and no commission. Post-acceptance cancellation and post-fulfilment cancellation follow platform-defined rules that must be configured, not hardcoded.

• Pre-acceptance cancellation: Full refund and no commission deduction; this is a clean reversal with no financial complexity.
• Post-acceptance cancellation rules: Platform cancellation policy determines the commission and refund split; these rules must be configurable by admin without developer involvement.
• Partial commission on work commenced: Some platforms retain a partial commission if the vendor has demonstrably begun work; the rule engine must support this.
• Notification on cancellation: Both parties must be notified immediately with the financial outcome of the cancellation and any next steps.

Cancellation policy is a commercial decision that must be encoded in the commission rule configuration before the platform goes live.

State 7: Refunded

A refund is issued post-completion within the refund eligibility window. Commission is recalculated on the net transaction value and vendor payout is adjusted.

This state requires the payment system to support payout clawback or reduction, which is not a default capability in all payment processors.

• Post-completion refund window: Define the period during which buyers can request a refund after order completion; most platforms use seven to fourteen days.
• Commission recalculation on net value: If a partial refund is issued, commission is recalculated on the net amount, not the original transaction value.
• Payout clawback capability: If the vendor has already been paid, the system must either deduct from future payouts or request the difference back; verify your payment processor supports this.
• Audit trail for refund adjustments: Every refund and its effect on commission must be logged in the audit trail, separate from the original commission record.

The Refunded state is rare but high-stakes. The financial logic must be specified before it is needed, not designed under pressure when the first post-payout refund request arrives.

How Should Commission Rates Be Structured?

Commission rate structure is a product and commercial decision before it is a technical one. Commission-based marketplace economics determines what the engine must calculate, not the other way around.

The engine must support five rate types, with a defined rule resolution order that determines which rate applies when multiple rules are valid simultaneously.

• Flat rate commission: A single percentage applied to all transactions; simplest to implement and audit, appropriate for early-stage platforms with a uniform catalogue.
• Category-specific rates: Different commission percentages per product or service category, requiring a rate lookup table keyed to listing category at calculation time.
• Tiered volume rates: Commission rate decreases as vendor monthly GMV increases; requires monthly GMV calculation per vendor and automatic rate recalculation at tier boundaries.
• Promotional rates: Temporary commission reductions with defined start and end dates; requires a rule priority system with automatic expiry to prevent indefinite application.
• Vendor-specific overrides: Bespoke rates for strategic vendors, stored as an override record linked to vendor_id that takes precedence over all other rate rules.

The rule resolution order must be implemented explicitly: vendor override takes highest priority, then active promotional rate, then category rate, then the flat platform default. Any ambiguity in this order produces incorrect payouts.

How Does Commission Management Connect to the Admin Panel?

Commission configuration belongs in the admin panel commission controls. Rate changes, vendor overrides, and payout holds must be operator-accessible without requiring a developer.

The admin commission interface is the operational control surface for the platform's revenue model.

• Commission rule configuration UI: Admins must be able to create, edit, and deactivate commission rules through a UI, not through a database edit or developer ticket.
• Rule scheduling and expiry: Promotional rates must have start and end dates set at creation; automatic expiry eliminates the risk of discounted rates remaining active indefinitely.
• Vendor override management: The admin interface for vendor-specific rates must show the rate, the start and end date, and the authorising admin user in a single view.
• Audit log for rate changes: Every commission rule change must be logged with actor, timestamp, old value, and new value; this is the evidence record for vendor payout disputes.
• Payout hold controls: Admins must be able to place a manual hold on a specific vendor's payout and must trigger a notification explaining the reason, not a silent delay.

An admin who cannot manage commission rates without a developer cannot operate the platform commercially. This is not a feature to defer.

How Does the Commission Engine Connect to the Payment Gateway?

The commission engine produces the split instruction that is passed to the payment gateway integration layer. These two systems must share a consistent state model or payouts become unreliable.

The event sequence at the integration boundary must be strictly ordered and fully specified before any payment code is written.

• Calculation precedes gateway instruction: If the gateway receives a split instruction before the commission engine has resolved the correct rate, the payout record will not match the commission record.
• Idempotency requirement: Every split instruction must carry a unique transaction reference; if the same instruction is sent twice due to a network retry, the gateway must not execute the split twice.
• Failed split handling: If the gateway rejects a split instruction (suspended payout account, invalid banking details), the order record must be updated to a hold state and both admin and vendor notified.
• Reconciliation event logging: Every commission calculation event must be written to an audit log separate from the order record so the audit trail survives any order record edits.
• State consistency requirement: The order record state and the gateway state must be updated atomically; a mismatch between the two produces reconciliation failures that require manual correction.

Idempotency is the most commonly missed requirement at the gateway integration boundary. Build it in from the start; adding it later requires auditing every historical transaction.

How Does Order Management Surface in the Vendor Dashboard?

The vendor's view of order management is defined by vendor dashboard order features. What they can see, update, and act on determines how quickly orders move through the fulfilment pipeline.

The vendor dashboard is an operational tool. Design it for the vendor's working flow, not for the admin's oversight needs.

• Order list view design: Filter by status (new, in progress, awaiting confirmation, completed, disputed) with unread buyer messages indicated so vendors can prioritise without opening individual records.
• Payout transparency per order: Each completed order must show the commission rate applied, the platform fee deducted, the net vendor amount, and the expected payout date.
• Fulfilment action availability: Accept, mark as dispatched, mark as delivered, and initiate cancellation request must all be available from the individual order view.
• Dispute visibility for vendors: A vendor in a dispute must see the dispute reason, the buyer's claim, the current timeline, and the available actions from their dashboard without contacting support.
• Masked buyer contact details: Buyer name and contact information should be visible for fulfilment purposes but masked to prevent off-platform transactions that circumvent commission.

Opacity in payout calculations is the primary cause of vendor commission disputes. If the vendor cannot see how the commission was calculated, they will assume it is wrong.

Conclusion

Order and commission management systems for marketplaces are the operational backbone of the platform. When they fail, they fail publicly, in the form of incorrect payouts, unresolvable disputes, and vendor churn.

The state machine design, the commission rule engine, and the payout architecture must be built with the same care as the buyer experience.

Before writing a specification, draw the complete order state machine for your platform. Every state, every transition, and every triggered action. Every gap in that diagram is a place where an order will eventually get stuck and require manual intervention.

Marketplace App Development

Marketplaces Built to Grow

We build scalable marketplace apps with modern no-code technology—designed for buyers, sellers, and rapid business growth.

Let's talk

Building Order and Commission Systems That Run Without Manual Intervention

Most marketplace operators spend their first year doing manual payout reconciliation and resolving commission disputes that a well-designed system would handle automatically. That is a fixable problem, but only if the architecture is right from the start.

At LowCode Agency, we are a strategic product team, not a dev shop. We design and build order management and commission engine architecture for marketplace platforms, from state machine design and rule engine configuration through to payout scheduling and reconciliation tooling. The goal is a system that runs correctly from the first transaction without requiring manual intervention to fix edge cases.

• State machine design: We design the complete order state machine before development begins, including every transition, every triggered action, and every edge case in cancellation and refund flows.
• Commission rule engine: We build configurable commission engines that support flat, category, tiered, promotional, and vendor-specific rates without hardcoded logic.
• Admin commission controls: We build the admin UI for commission rule management so platform operators can update rates, set promotions, and manage vendor overrides without developer dependency.
• Gateway integration specification: We specify the event sequence and idempotency requirements at the commission-to-gateway boundary before any payment code is written.
• Vendor dashboard order tooling: We design vendor order management interfaces with payout transparency built in so vendors always understand how their commission was calculated.
• Audit trail architecture: We build commission event logging separate from the order record so every payout calculation is auditable and dispute-provable from day one.
• Full product team: Strategy, UX, development, and QA from a single team that understands the operational requirements of marketplace platforms, not just the technical ones.

We have built 350+ products for clients including Coca-Cola, American Express, and Sotheby's. We know exactly where order and commission systems fail and how to build them so they do not.

If you are serious about building an order and commission system that works without manual intervention, let's scope it together.