Розробка мультивендорного маркетплейсу: де ламається розрахунок
Розробка мультивендорного маркетплейсу починається не з вітрини, а з розрахункового ядра платформи.
Вітрина й кошик збираються передбачувано, а ось розрахункове ядро визначає, чи зійдеться платформа в цифрах, коли продавців сотні, у кожного свої правила комісії, свій графік виплат і своя валюта розрахунку. Економіка проєкту ламається саме тут.
Збій виглядає буденно.
Комісія розраховується в момент оформлення замовлення, але не перераховується при частковому поверненні; знижка за промокодом розподіляється на весь кошик, хоча товари належать трьом продавцям; доставка входить до бази розрахунку в одного і не входить в іншого.
Далі суми у звіті продавця та у внутрішньому реєстрі розходяться, і розбіжність закривають ручними правками.
Ручні правки в реєстрі виплат — найдорожча ділянка. Кожна правка втрачає зв'язок з вихідною операцією, і за місяць ніхто не може пояснити, чому в продавця утримано більше, ніж показано в його особистому кабінеті.
Спірні операції висять тижнями: покупцю повернення вже оформлено, а продавець виплату ще не отримав. Розсинхрон реєстрів накопичується спочатку у звітах, потім у довірі продавців, і на цьому етапі платформа втрачає асортимент.
Далі розбираємо, як це закривається: як описуються правила комісії, щоб вони жили в одному місці та версіонувалися, як будуються виплати продавцям, які сходяться без ручних правок, і як звірка реєстрів стає щоденною операцією, а не аварією.
Що дає керована модель комісій і відкладених виплат
Поки комісії рахують у таблицях і правлять руками, закриття розрахункового періоду перетворюється на звірку: у кожного продавця свої умови, частина замовлень повертається вже після відвантаження, а розбіжності шукають листуванням.
Помилка в одному коефіцієнті дає клас відмов «виплатили не тому й не стільки» — і розбирати його доводиться заднім числом.
Налаштовувані правила комісії описуються даними, а не кодом: відсоток за категорією, фіксована ставка за позицію, ступінь за оборотом, пріоритет правил при перетині та строк їх дії.
Зміна ставки — це нова версія правила, тому розрахунок за закритий період відтворюється точно з тими умовами, які діяли тоді.
Відкладені виплати розділяють нарахування і виведення: сума фіксується в момент замовлення, але стає доступною продавцю після закриття вікна повернень. Якщо товар повернувся, сторнується лише невиплачена частина, а не вся історія нарахувань за продавцем.
Єдиний реєстр продавців утримує один ідентифікатор, реквізити, статус перевірки надійності та історію підключених правил.
Звірка йде за ним, а не за вивантаженнями з кількох систем, тому частка ручних операцій у розрахунках падає: розрахунковий період закривається за регламентом, а не «коли зійдеться».
Схеми розрахунків між продавцем, покупцем і платформою
Рух грошей на платформі — не одна операція, а ланцюжок зобов'язань: авторизація, утримання, зарахування, виплата продавцю, повернення.
Схему вибирають не за зручністю інтеграції, а за тим, хто і на який строк несе ризик непоставки та скільки коштів заморожено в обороті між оплатою й отриманням товару.
| Варіант | Коли підходить | Обмеження |
|---|---|---|
| Ручне підтвердження | разові угоди та великі замовлення, де потрібна перевірка перед виплатою | трудовитрати зростають лінійно з кількістю замовлень, виплата затримується, звірка ведеться вручну |
| Автоматичне розділення платежу | масові товарні категорії з коротким циклом угоди | комісія платформи утримується одразу, при поверненні доводиться сторнувати частки, строк утримання обмежений правилами платіжного партнера |
| Умовне депонування | дорогі позиції та послуги, де важливе приймання результату | кошти заморожені до підтвердження, потрібен регламент випуску та розбору спорів |
| Відкладений розрахунок за фактом приймання | роботи, логістика, поставки між компаніями | продавець фактично кредитує покупця, потрібні ліміти за ризиком і правила блокування виплат |
Схеми не виключають одна одну: правило задається на рівні категорії та продавця, а доступ до депонування відкривається після перевірки контрагента.
Мультивалютні розрахунки додають фіксацію курсу на момент операції — комісія утримується до конвертації, і курсова різниця не переноситься на продавця заднім числом.
Етапи впровадження: від аудиту схеми до передачі регламентів
Порядок робіт побудований так, щоб розрахункове ядро не збиралося наосліп: спочатку фіксуємо фактичні схеми та реєстри, потім проєктуємо модель і тільки потім пишемо код. Кожен етап закінчується артефактом, який замовник може перевірити без доступу до нашої команди.
- Аудит схеми розрахунків. Розбираємо, як рахуються комісії за категоріями, як ділиться сума між продавцями, як проходять повернення та сторно, хто і з якої причини править суми вручну. На виході — карта розбіжностей і перелік місць, де реєстр перестає сходитися з виписками провайдера.
- Проєктування моделі розрахунків. Фіксуємо рахунки та подвійний запис, порядок резервування під замовлення, правила перерахунку при поверненні та в мультивалютних кошиках: курс береться на момент операції, а не виплати, тому підсумок не «пливе» заднім числом.
- Впровадження розрахункового ядра. Проводки позначаються ключем операції, тому повторний виклик від провайдера не створює дубль нарахування. Поруч ставимо автоматичну звірку: частина розбіжностей закривається сама, решта йде в чергу розбору з відповідальним.
- Налаштування перевірки продавців і виплат. Статус перевірки напряму визначає право отримувати виплати; ліміти, заморозка та черговість виплат задаються правилами, а не ручними рішеннями підтримки.
- Приймальні сценарії. Проганяємо спірні випадки до запуску: часткове повернення однієї позиції із замовлення, скасування після відвантаження, негативний баланс продавця, коригування заднім числом, розбіжність із провайдером. Кожен сценарій — з очікуваним станом реєстру.
- Передача регламентів і навчання команди замовника. Віддаємо схему рахунків, регламент ручних коригувань і розбору інцидентів, порядок ескалації; проводимо навчання на реальних операціях, щоб підтримка закривала типові розбіжності самостійно.
Після запуску перший закритий період проходимо разом — за метриками звірки видно, де правила потребують уточнення.
Комплект поставки: схеми, політики доступу, регламенти
Після запуску весь комплект документації залишається у замовника — не в листуванні й не в головах підрядника, а в репозиторії поряд із кодом. За цими матеріалами новий інженер, бухгалтер або оператор підтримки розбереться в будові розрахунків без дзвінків нам. Нижче — що саме фіксуємо та передаємо.
- Схеми інтеграцій — потік замовлення між вітриною, платіжним шлюзом і обліковою системою: у який момент замовлення переходить у стан «оплачено», де нараховується комісія продавця, які події надходять асинхронно і що відбувається при втраті відповіді.
- Матриця ролей і прав доступу — хто з продавців, операторів і бухгалтерії що бачить і змінює: зони видимості за своїми товарами та замовленнями, права на повернення, ручне коригування нарахувань і вивантаження звітів.
- Правила комісій — ставка за категоріями, момент утримання, обробка часткового повернення та скасування, порядок перерахунку при спорі між покупцем і продавцем.
- Регламент звірки — порядок зіставлення нарахувань, виплат і фактичних надходжень: які звіти сходяться, з якою періодичністю, хто закриває розбіжності та в якому вигляді фіксується результат.
- Інструкції для підтримки — типові звернення: продавець не бачить виплату, покупець оспорює списання, зависла заявка на перевірку компанії, — з готовими кроками діагностики та межею, після якої підключається інженер.
- Порядок дій при інцидентах — що робити при недоступності шлюзу, розбіжності балансу або масовому збої виплат, хто ухвалює рішення про зупинку нарахувань і як відкочується помилковий прогін.
Кожен документ прив'язаний до версії системи й оновлюється разом із нею — комплект не застаріває через півроку після передачі.
Кейс: зростання кількості продавців без зростання ручних операцій
Що було до
Платформа маркетплейс товарів для дому зростала швидко: кілька сотень продавців, десятки категорій, повернення й доплати за доставку.
Комісії та виплати зводилися вручну — бухгалтерія збирала вивантаження з панелі продавця, еквайрингу й служби доставки в таблиці, а закриття розрахункового періоду займало до дев'яти днів.
Підтримка відповідала на одне й те саме: «чому сума до виплати менша, ніж у моєму звіті», і на кожне таке питання йшло від півгодини на підняття історії замовлення.
Що змінили
Ввели правила розподілу грошей на рівні моделі даних: кожна операція отримує проводку з типом, ставкою та посиланням на замовлення — комісія, повернення, компенсація, утримання.
Регістр резервів утримує суму під можливі повернення, поки не минуло вікно спору, тому виплата рахується за підтвердженими операціями, а не за очікуваними.
Перевірку продавця перевели в потік із чек-листом документів і статусами, а спірні виплати стали завданням із дедлайном і прив'язкою до проводок замість листування в пошті.
Що стало
| Метрика | До | Після |
|---|---|---|
| Закриття періоду | до 9 днів | 1 робочий день |
| Ручні коригування виплат | близько третини операцій | одиниці відсотків |
| Звернення в підтримку щодо сум | базова лінія | менше приблизно в чотири рази |
| Спірні виплати без історії | більшість | розбираються за журналом проводок |
Кількість продавців за той самий період зросла втричі при тому самому складі операційної команди: звірка стала прогоном правил, а не роботою людей. Ми продовжуємо вести платформу — додаємо ставки комісій за категоріями та розбираємо розбіжності за журналом.
Що робити, якщо маркетплейс уже запущено на готовій платформі?
Готова платформа доводить майданчик до перших продажів: вітрина, каталог, кошик, замовлення, базові виплати.
Межа зазвичай настає на розрахунках — коли вендорів десятки, комісія залежить від категорії, а до неї додаються утримання, повернення, перевірка постачальників і друга валюта.
Перші ознаки, що маркетплейс на готовій платформі уперся в стелю: комісії правлять вручну в адмінці, виплати звіряють у таблицях, а будь-яке нове правило — знижка від вендора, розстрочка, партнерська схема — потребує правки ядра.
Кожна така правка сповільнює випуск змін і підвищує ризик, що розрахунок розійдеться з фактичними замовленнями.
Перенесення розрахунків робимо окремим контуром: він читає замовлення та події з робочої платформи, рахує комісії, утримання й виплати за своїми правилами, а платформа залишається вітриною та оформленням замовлення.
Продажі при цьому не зупиняються — новий контур спочатку працює паралельно й не впливає на гроші вендорів.
Далі з'являється агрегатор вітрин: каталог, залишки та замовлення зводяться з кількох джерел, включно з попередньою платформою, а розрахунок іде за єдиними правилами. Нову вітрину або канал підключаємо як ще одне джерело — решта продовжують працювати без змін.
Поступова міграція будується на звірці: новий розрахунок проганяє закриті періоди, і його підсумки порівнюються з фактичними виплатами за кожним вендором, поки розбіжності не зникнуть.
Тільки після цього перемикаємо групи вендорів і категорії, зберігаючи можливість повернути попередню схему, — перевірка перед перемиканням тут важливіша за швидкість.
Спірні операції, повернення та звірка: технічні сумніви
Повернення — це не одна операція, а ланцюжок пов'язаних проводок: блокування суми на балансі продавця, сторно нарахованої комісії, перерахунок виплати в розрахунковому періоді та коригування звіту, який продавець уже бачив.
Якщо провести одну ланку окремо від інших, наступний період звірки не зійдеться, і розбирати розбіжності доведеться вручну за вивантаженнями.
Окрема складність — часткові повернення та спори після відвантаження, коли товар уже в продавця, а рішення ухвалює арбітраж платформи. Нижче — те, що найчастіше уточнюють інженери та фінанси перед стартом розробки мультивендорного маркетплейсу.
Як утримується комісія при частковому поверненні?
Комісія рахується від фактично виконаної частини замовлення, а не від початкової суми. Сторно-проводка йде в той самий розрахунковий період, до якого належить первинне нарахування; якщо період уже закрито, коригування оформлюється окремим документом із посиланням на вихідний. Звірка періодів залишається сходимою, а виплата продавцю не перераховується заднім числом.
Як відкликається статус продавця після спірних операцій?
Не за фактом одного спору, а за порогом: частка програних спорів, прострочення відвантажень, час відповіді на претензії. Перед відкликанням призупиняється приймання нових замовлень, відкриті спори закриваються, залишок виводиться після розрахунків. Повернення статусу — автоматичне при виконанні умов, без ручних правок адміністратором.
Що з курсами валют, якщо спір закривають в іншому періоді?
Курс фіксується на момент операції, а не на момент звірки, тому закриті періоди не «пливуть» заднім числом. Усі рухи пишуться в незмінний журнал, а виправлення оформлюється зворотною проводкою — вихідний запис залишається в історії. Це дає відтворюваний слід для аудиту та дозволяє відкотити помилкове рішення без правок у базі.
Обговоримо схему розрахунків і повернемося з оцінкою та планом
Щоб оцінка була по суті, а не середньою по ринку, нам потрібно побачити вашу поточну модель розрахунків: як утримується комісія, хто тримає кошти до підтвердження замовлення, як обробляються часткові скасування та повернення, у яких валютах виставляються рахунки й за яким курсом закривається угода.
Від цього залежить архітектура розрахункового ядра та обсяг перевірок — а не кількість сторінок у каталозі.
Опишіть обсяг продавців: скільки працює зараз і скільки очікується, як вводите нових, хто перевіряє документи та бенефіціарів. Якщо платформа вже живе, додайте, що болить — розбіжності в балансах, ручні виплати, спірні утримання.
У відповідь надсилаємо не загальні слова, а робочий документ:
- оцінку та план робіт за етапами — розрахункове ядро, кабінет продавця, вітрина, адмін-панель;
- склад поставки: конфігурації платіжних сценаріїв, правила утримань, схеми повернень, вивантаження для бухгалтерії;
- порядок перевірок продавця — які документи, на якому кроці, хто підтверджує та як відхиляє;
- схему виплат: розклад, мінімальний залишок до виведення, обробку розбіжностей і спірних операцій;
- план міграції при робочій платформі: перенесення довідників, вивірка балансів, паралельний період;
- регламент підтримки платформи: строки реакції, чергування, порядок термінових звернень.
Опишіть схему розрахунків і обсяг продавців — повернемося з оцінкою та планом робіт.
