Розробка автоматизованої системи виплат для маркетплейсу

Після запуску модулю виплат без холду баланс продавця на маркетплейсі пішов у мінус на 500 000 рублів через масові повернення. Щоб таке не повторювалося, ми проектуємо системи з ескроу та автоматичними розрахунками. Наша команда з 10+ роками досвіду в фінтехі реалізувала виплатні модулі для 20+ маркетплейсів — від стартапів до платформ з 10 000 продавців. За 10+ років на ринку ми навчилися будувати надійне фінансове ядро, яке витримує тисячі транзакцій на день. Автоматизація виплат продавцям знижує операційні витрати на 40% та виключає помилки ручного введення. Фінансовий контроль маркетплейсу — запорука прозорості та дотримання 115-ФЗ.

У цій статті розберемо ключові компоненти: фінансову модель, життєвий цикл грошей, інтеграцію з платіжними шлюзами, обробку повернень та документообіг. Ви дізнаєтеся, як уникнути типових помилок і побудувати інфраструктуру, що масштабується разом з маркетплейсом.

Автоматизована система виплат: архітектура та ключові модулі

Як влаштований життєвий цикл виплат?

Покупець платить — гроші надходять на рахунок платформи. Платформа утримує комісію (зазвичай 5–15%) і перераховує нетто-суму продавцю. Основні сутності — баланси та транзакції, які зберігаються в базі:

seller_balances (
  seller_id, available_balance, hold_balance, total_earned,
  currency, updated_at
)

balance_transactions (
  id, seller_id, type, amount, balance_before, balance_after,
  reference_type, reference_id,
  status, created_at, description
)
-- type: order_credit | commission_debit | payout_debit | refund_debit | adjustment

Етапи руху коштів

1. Оплата замовлення — сума за вирахуванням комісії зараховується в hold_balance продавця.
2. Закінчення холд-періоду (7–14 днів після доставки) — переведення з hold в available.
3. Запит виплати — продавець ініціює виведення коштів.
4. Схвалення та переказ — платформа відправляє кошти через платіжний шлюз.
5. Підтвердження — статус completed, списання з available_balance.

Холд захищає від чарджбеків — без нього продавець міг би вивести гроші, а покупець одразу запросити повернення. Докладніше про механізм ескроу.

Чому важлива модель виплат?

Автоматичний розклад — золота середина: знижує навантаження на підтримку в 2 рази порівняно з ручними виплатами і не потребує постійного моніторингу. Гібридна модель (планові + позапланові виплати) додає гнучкість, але складніша в реалізації. Для маркетплейсу з 1000 продавців економія на операційних витратах є значною. Для платформи з 10 000 продавців економія може бути значною.

Автоматичні виплати за розкладом знижують навантаження на підтримку в 2 рази порівняно з ручними. Гібридна модель виплат в 1.5 рази ефективніша за чисто планову за показником задоволеності продавців.

Як інтегрувати платіжні системи?

Обираємо шлюз під завдання маркетплейсу. Кожен провайдер має формат webhook-нотифікацій. Ми налаштовуємо обробку успіху/помилки та автоматичне звіряння балансів.

Обробка повернень

При поверненні сума списується з available_balance продавця; якщо коштів недостатньо — з hold_balance. Якщо і там пусто — утворюється від'ємний баланс, що блокує майбутні виплати. В системі це запис з type='refund_debit'.

1. Повернення покупцю — з ескроу/балансу платформи.
2. Списання з продавця: refund_amount + повернення комісії (опціонально).
3. Запис у balance_transactions.

Документообіг та звітність

Для російських продавців генеруємо:

• Акт виконаних робіт / звіт агента
• Рахунок-фактуру (при ПДВ)
• Реєстр продажів

PDF-файли (через Puppeteer) зберігаються в хмарному сховищі. Для ФОП та самозайнятих — окремі шаблони. Всі документи доступні в кабінеті продавця в архіві.

Інтерфейс продавця

• Поточний баланс (доступно / на утриманні)
• Історія транзакцій з експортом в Excel
• Форма запиту виплати з реквізитами
• Статуси виплат (processing / completed / failed)

Перед першою виплатою — верифікація реквізитів: перевірка БІК та тестовий переказ на 1 рубль.

Безпека та контроль

• Ліміти на виведення (денний, разовий)
• Подвійне підтвердження сум понад поріг
• Моніторинг аномалій
• Щоденне звіряння з платіжною системою

Ми гарантуємо відповідність 115-ФЗ та повний аудит всіх транзакцій.

Що входить у розробку під ключ

• Детальна специфікація API та моделі даних
• Інтеграція з обраним платіжним шлюзом
• Модуль автоматичних виплат за розкладом
• Генерація бухгалтерських документів
• Особистий кабінет продавця з балансом та історією
• Розгортання на інфраструктурі замовника
• Навчання команди та документація
• 30 днів технічної підтримки після запуску

Терміни: від 6 до 8 тижнів на типову систему. Зв'яжіться з нами, щоб отримати попередню архітектуру вашої системи. Замовте розробку — почніть з аудиту поточної схеми виплат.

Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.

Як побудувати надійну мультивендорну платформу?

Як уникнути розбіжностей у розрахунках комісій

Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.

Моделі комісій (використовуємо одну з або комбінуємо):

Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.

Чому архітектура мультиарендності критична для ізоляції даних

Перший крок — вибір архітектури мультиарендності. У shared-schema режимі всі продавці в одних таблицях з vendor_id. Ми обов'язково впроваджуємо Row Level Security на рівні PostgreSQL та глобальні scopes в ORM (Laravel, Rails, Django). Це гарантує, що продавець не побачить чужих замовлень навіть при помилці розробника. Для enterprise-проектів з жорсткими вимогами GDPR використовуємо окремі схеми PostgreSQL — ізоляція строгіша, але cross-vendor аналітика складніша.

Як реалізувати складські залишки без race condition

Два покупці одночасно додають останній товар у кошик. Хто його купить? Застосовуємо optimistic locking при створенні замовлення:

UPDATE inventory 
SET reserved = reserved + 1 
WHERE product_id = ? AND (quantity - reserved) >= 1

Атомарна операція — другий запит поверне 0 зачеплених рядків та отримає помилку «товар закінчився». Типова схема для високонавантажених маркетплейсів.

Який підхід до каталогу товарів обрати: unified чи per-vendor?

Порівняння підходів до каталогу товарів:

Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.

Пайплайн модерації: автоматика та ручна верифікація

Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:

1. Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
2. AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
3. Черга ручної перевірки для flagged товарів.

Статусна машина: draft → pending_review → active / rejected → suspended. Кожен перехід — подія з причиною та модератором. Продавець отримує сповіщення з конкретною причиною відмови, а не «порушення правил». Верифікація відгуків обов'язкова — тільки після підтвердженого замовлення. Автоматичний детектор флагує різке зростання відгуків від акаунтів з нульовою історією.

Пошук та рекомендації

Пошук по маркетплейсу з різними продавцями та сотнями тисяч товарів — це Elasticsearch або OpenSearch, не SQL LIKE. Векторний пошук для семантики, фасетна фільтрація через агрегації. Персоналізована стрічка на основі колаборативної фільтрації. A/B тестування алгоритмів ранжування обов'язкове — інтуїція тут поганий порадник.

Процес роботи

Маркетплейс — ітеративна розробка. MVP: реєстрація продавців, каталог товарів, кошик та checkout через Stripe Connect, базова модерація. Після запуску — дані про реальне використання визначають пріоритети наступних ітерацій.

Типовий порядок:

• MVP (3–4 місяці)
• Аналітика та зворотний зв'язок
• Перший розширений реліз (2–3 місяці)
• Масштабування та оптимізація

Терміни та вартість

• MVP маркетплейсу (каталог, checkout, базові профілі продавців): 3–5 місяців.
• Повнофункціональний маркетплейс з модерацією, розширеною аналітикою, мобільним додатком: 8–18 місяців.
• Додавання маркетплейс-функціональності до існуючого e-commerce: 2–5 місяців.

Вартість розробки розраховується індивідуально після аудиту вимог. Точну оцінку надамо на безкоштовному передпроектному обстеженні.

Що входить в роботу

• Проектна документація: архітектура, схеми даних, API-специфікації (OpenAPI).
• Доступи до репозиторію, CI/CD, документації з розгортання.
• Навчання команди замовника роботі з платформою.
• Технічна підтримка протягом першого місяця після запуску.

Ми гарантуємо коректність фінансових розрахунків та конфіденційність даних. Архітектурні принципи, на яких ми ґрунтуємося, підтверджені досвідом 10+ років та 50+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.