Ключевые темы
Связанные публичные страницы
Если нужен не только разбор, а страница продукта, API или операционного сценария, начните с этих разделов VPOS.am.
Маркетплейс должен разделять order, payment и vendor ledger
Один заказ может включать несколько продавцов, комиссии, доставку и разные refund rules.
В обычном интернет-магазине один заказ часто принадлежит одному продавцу. В marketplace и multivendor-сценарии один платеж может относиться к нескольким продавцам, товарам, комиссиям, доставке, скидкам и частичным возвратам. Если хранить только paid/failed, финансовая картина быстро ломается.
Надежная модель разделяет customer order, payment intent, provider reference, vendor ledger and business settlement. Payment backend фиксирует оплату и события, а отдельный ledger показывает, какая часть суммы относится к продавцу, комиссии платформы, доставке и возвратам.
- связывать payment id с order id и vendor ids;
- хранить commission rule version на момент оплаты;
- разделять gross amount, platform fee и vendor share;
- не использовать один paid status как отчет по продавцам.
Split, payouts и settlement нельзя обещать без правил
Автоматические перечисления зависят от провайдера, договора и юридической модели, поэтому сначала нужен settlement workflow.
Некоторые команды сразу называют это split payment, но технически и юридически это может быть другой процесс: один merchant payment, внутренний ledger, ручной или пакетный seller settlement, бухгалтерский экспорт или отдельная payout-интеграция. Нельзя обещать автоматические выплаты, если провайдер и договор это не поддерживают.
Практичный старт - controlled settlement workflow: vendor balance, payout period, refund hold, commission rule, manual review and accounting export. Когда банк или провайдер подтверждает доступный payout-механизм, workflow можно автоматизировать без потери audit trail.
- не смешивать customer payment и seller payout;
- хранить payout period и settlement status;
- учитывать refund hold до выплаты продавцу;
- логировать manual approval и exported accounting file.
Refunds и disputes должны пересчитывать ledger
Частичный возврат по одному продавцу не должен ломать отчет по другим продавцам и комиссии платформы.
В marketplace возврат редко бывает простым. Клиент может вернуть один товар из заказа, продавец может принять частичный refund, доставка может остаться платной, а комиссия платформы может пересчитываться по отдельному правилу. Все это должно быть видно до закрытия периода.
Ledger должен хранить original payment, refund amount, affected vendor, commission adjustment, dispute status and provider reference. Тогда поддержка видит не только сумму возврата, но и влияние на продавца, платформу, delivery и отчетность.
- partial refund должен указывать affected vendor line;
- dispute не равен обычному refund;
- commission adjustment хранится отдельным событием;
- сверять provider report, vendor ledger и ERP export.
FAQ
Можно ли сразу делать split payment между продавцами?
Это зависит от провайдера, договора и юридической модели. Без подтвержденного механизма безопаснее начать с customer payment, vendor ledger и controlled settlement workflow.
Как учитывать комиссию платформы?
Хранить commission rule version на момент оплаты и рассчитывать отдельные ledger lines: gross amount, platform fee, vendor share, delivery and adjustments.
Что происходит при частичном возврате?
Refund должен ссылаться на конкретную vendor/order line, пересчитать commission adjustment и остаться в истории платежа, ledger и ERP export.
