OMS Handling of Partial Payments and Split Billing

Not every order is paid in one transaction by one party. Deposits, layaway plans, buy-now-pay-later installments, and orders split across a corporate card plus an employee's personal card all require an OMS payment model richer than a single "paid" or "unpaid" flag per order.

The core requirement is separating the order's financial state from its fulfillment state. An order can be fully allocated and ready to ship while only partially paid (a deposit plus a balance due on delivery), or fully paid across several transactions that arrived at different times. The OMS needs a payment ledger per order — not just a single amount-paid field — recording each transaction, its method, timestamp, and remaining balance.

• Deposit-and-balance orders need a defined trigger for when the balance is due (on shipment, on delivery, on a fixed date)
• Multiple payment methods on one order (split tender) must each be tracked separately for refund and reconciliation accuracy
• Partial refunds must reduce the correct payment record, not just an aggregate order total

Whether an order can ship before it's fully paid is a policy decision, not a technical default — some businesses ship on a deposit, others hold until 100% collected. The OMS needs this as a configurable gate per order type or customer segment, since a hardcoded "ship only when fully paid" rule breaks legitimate deposit-based business models, while a hardcoded "ship regardless" rule creates bad debt risk for others.

BNPL providers typically pay the merchant in full upfront and then collect installments from the customer directly, meaning the OMS sees the order as fully paid from day one, while the BNPL provider carries the collection risk. The OMS still needs to record which orders went through a BNPL provider for return-and-refund purposes, since refunding a BNPL order requires notifying the provider, not just crediting the customer directly.

For layaway or in-house installment plans (as opposed to third-party BNPL), a missed installment payment needs a defined consequence: a grace period, a hold on further fulfillment, or in some models a partial cancellation with a restocking fee. The OMS should automate the dunning sequence — reminder before due date, notice on missed payment, defined escalation — rather than relying on manual follow-up that scales poorly.

An order that's 40% paid and mid-fulfillment creates a reporting question: is this revenue recognized, deferred, or split? This ties directly into the accounting integration layer, and the OMS needs to expose payment-completeness state clearly enough that finance doesn't have to guess at collection status from raw transaction logs.