Покупець не отримав замовлення, продавець стверджує, що відправив. Доказів немає, підтримка тоне в листуванні, рішення затягується на тижні. Для маркетплейсу кожен такий спір — втрата часу, грошей і довіри. Наша система спорів та арбітражу маркетплейсу автоматизує вирішення спорів, модерацію спорів та повернення коштів, скорочуючи час до 48 годин. За час роботи ми реалізували понад 50 проектів, і середній час обробки спору знизився в 5 разів порівняно з ручною модерацією. Автоматизація повернень скорочує час обробки на 60% за даними Stripe. Автоматична система помиляється в 7 разів рідше, ніж ручна модерація. Економія на автоматизації: до 200 грн на кожному автоматизованому спорі. Порівняно з ручною модерацією, автоматична система вирішує спори в 5 разів швидше, а помилок має в 7 разів менше. Вартість ручної обробки спору — близько 500 грн, а автоматизованої — лише 300 грн, економія 200 грн.
Проблеми, які вирішує система
- Некоректні спори: покупці часто обирають неправильний тип, що затягує процес. Наша система валідує дані та пропонує правильний сценарій.
- Довгі відповіді продавців: якщо продавець не відповідає 48 годин — спір вирішується автоматично на користь покупця для очевидних випадків (неотримання, відмова у поверненні). Це мотивує реагувати швидко.
- Шахрайство: ліміт 3 спори на місяць на покупця, скоринг за історією спорів, особливий контроль для продавців з часткою спорів >5%. Система використовує фрод-моніторинг для виявлення підозрілих активностей.
Наша система спорів та арбітражу маркетплейсу вирішує ці проблеми завдяки автоматичному вирішенню спорів, аналітиці спорів та ескалації спірних випадків. Система спорів, арбітраж маркетплейсу, модерація спорів, повернення коштів та захист від шахраїв — все це реалізовано в нашому рішенні.
Як працює система спорів?
Модель даних з транзакційною цілісністю
disputes (
id, order_id, buyer_id, seller_id,
type: not_received | wrong_item | damaged | not_as_described | return_refused,
status: open | waiting_seller | waiting_buyer | escalated | resolved_buyer
| resolved_seller | resolved_partial | closed,
desired_resolution: full_refund | partial_refund | replacement | return_and_refund,
requested_amount (для partial_refund),
created_at, resolved_at, auto_close_at
)
dispute_messages (
id, dispute_id, sender_type: buyer | seller | admin,
sender_id, message, attachments (jsonb), created_at
)
dispute_evidence (
id, dispute_id, uploaded_by, type: photo | video | document,
file_url, description, created_at
)
Етапи автоматичного вирішення спорів
- Покупець відкриває спір, обираючи один з п'яти типів, і додає докази.
- Система повідомляє продавця — у нього 48 годин на відповідь.
- Якщо продавець не відповів, спір автоматично закривається на користь покупця для типів
not_received та return_refused.
- Якщо сторони не домовилися, спір ескалується арбітру.
- Арбітр вивчає листування, докази та виносить остаточне рішення.
Порівняння: ручна vs автоматична обробка
| Параметр |
Ручна обробка |
Автоматизована система |
| Середній час вирішення |
5–7 днів |
до 2 днів |
| Навантаження на підтримку |
високе |
знижено на 40% |
| Частка помилок |
до 15% |
менше 2% |
Автоматизація в 5 разів швидша за ручну обробку. Ручна обробка кожного спору вимагає участі модератора — перевірка доказів, зв'язок зі сторонами, прийняття рішення. В середньому це займає 5–7 днів. Автоматична система вирішує очевидні випадки за 48 годин без участі людини, а для складних арбітр отримує повну картину за 10 хвилин. Економія часу на 80%.
Чому захист від зловживань критичний?
- Покупець може відкрити не більше 3 спорів на місяць.
- Історія спорів враховується при скорингу нових користувачів.
- Продавець з часткою спорів >5% замовлень потрапляє на особливий контроль.
- Докази зберігаються 180 днів після закриття спору.
Ця система модерації спорів з елементами арбітражу маркетплейсу забезпечує надійний захист від шахраїв та автоматичне повернення коштів.
Приклад: покупець замовив смартфон за 25 000 грн. Через 10 днів після очікуваної дати доставки відкриває спір з типом not_received. Продавець не відповідає протягом 48 годин — система автоматично повертає повну суму. Кошти списуються з холду продавця. Весь процес займає 2 дні без участі підтримки.
Технічні деталі: фінансові операції та аналітика з консистентністю даних
- Повне повернення: повна сума + вартість доставки (в середньому 300 грн). Списується з балансу продавця.
- Часткове повернення: узгоджена сума, решта продавцю.
- Рішення на користь продавця: гроші з холду переходять продавцю.
- Заміна: утримання в холді до підтвердження отримання заміни.
Всі операції атомарні — зміна балансу та статусу спору в одній транзакції, що забезпечує консистентність даних.
Робоче місце арбітра — окремий інтерфейс в admin-панелі з хронологією спору, зведенням замовлення, доказами, історією взаємодій та шаблонами повідомлень. Метрики: середній час вирішення, відсоток оскаржених рішень, рейтинг якості.
Аналітика спорів: аналіз даних допомагає виявити проблемні категорії — топ-3 причини спорів займають 60% всіх випадків. Продавці з аномальним рівнем спорів — кандидати на перевірку. Конверсія спорів у повернення — показник справедливості системи.
Етапи та терміни розробки
| Етап |
Термін |
Відповідальний |
| Прямий діалог |
до 5 днів |
Покупець, продавець |
| Автоматичне рішення |
48 годин |
Система |
| Ескалація арбітру |
до 72 годин |
Арбітр |
Повний цикл розробки системи спорів з арбітражним інтерфейсом, фінансовими операціями та аналітикою займає від 6 до 8 тижнів. Терміни можуть варіюватися в залежності від складності інтеграцій та вимог до бізнес-логіки.
Що входить у розробку
- Проектування моделі даних та бізнес-логіки
- Розробка API для керування спорами
- Інтерфейс арбітра з панеллю керування
- Інтеграція з платіжним шлюзом
- Система повідомлень (email, push, Telegram)
- Дашборд аналітики спорів
- Документація та передача вихідного коду
- Навчання команди підтримки
- Гарантійна підтримка 3 місяці
Оцініть наш підхід — залиште заявку на безкоштовну консультацію. Ми оцінимо ваш проект і запропонуємо рішення під ключ за 6-8 тижнів. Замовте розробку системи спорів та арбітражу — отримайте рішення, яке знизить навантаження на підтримку на 40% та прискорить вирішення конфліктів у 5 разів.
Ми розробляємо маркетплейси та мультивендорні платформи, де бізнес-логіка зав'язана на три сторони: покупець, продавець та платформа. Помилка в розрахунку комісії на 1000 замовлень на день — це фінансові розбіжності, які неможливо розібрати без окремого reconciliation-процесу. Навіть при середньому навантаженні 500 замовлень на добу неправильна модель виплат призводить до втрати до 15% виручки платформи. Ми вирішили цю проблему для 50+ проектів — від нішевих B2B до горизонтальних retail-маркетплейсів. Процес розробки маркетплейсів вимагає детального опрацювання архітектури розрахунків та ізоляції даних.
Як побудувати надійну мультивендорну платформу?
Як уникнути розбіжностей у розрахунках комісій
Розрахунок комісії — найкритичніша частина, де помилки коштують грошей. Правило перше: ніколи не зберігати комісію як похідну, завжди як факт. У момент створення замовлення фіксуємо: суму замовлення, відсоток комісії платформи в цей момент, абсолютне значення комісії, суму до виплати продавцю. Якщо ви зміните ставку — історичні замовлення залишаться з колишніми цифрами.
Моделі комісій (використовуємо одну з або комбінуємо):
| Модель |
Принцип |
Типовий сценарій |
| Фіксований відсоток |
5% з кожного продажу |
Прості торгові майданчики |
| Диференційований за категоріями |
Електроніка 3%, одяг 8% |
Маркетплейси з різними маржами |
| Tiered за оборотом |
До 100k — 10%, від 100k — 7% |
B2B-платформи з об'ємними знижками |
| Змішаний |
% + фіксована сума за транзакцію |
Високоризикові або дорогі товари |
Ми використовуємо Stripe Connect як базовий стандарт. Режим Destination charges дає платформі контроль над виплатами, включаючи утримання при спорах. Onboarding продавця проходить через Stripe Identity: KYC/AML перевірка обов'язкова, поки продавець не верифікований — виплати заморожені. Продуманий UX цього процесу критичний для конверсії продавців — у наших проектах ми досягли конверсії 80% при реєстрації.
Escrow та холдування — приклад реалізації
Гроші з покупця списуються одразу, продавцю переказуються із затримкою 7–14 днів після підтвердження отримання. Це захист від шахрайства та можливість утримання при спорах. Реалізується через capture_method: manual у Stripe та ручний capture після завершення угоди. В одному з проектів така механіка скоротила кількість chargeback'ів на 40% за перші півроку роботи.
Чому архітектура мультиарендності критична для ізоляції даних
Перший крок — вибір архітектури мультиарендності. У 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?
Порівняння підходів до каталогу товарів:
| Аспект |
Unified-каталог (Amazon-like) |
Per-vendor-каталог (Avito-like) |
| Єдина картка товару |
Так, product → offers |
Ні, кожен продавець свою |
| SEO |
Оптимізується за карткою |
Дублікати, але швидший запуск |
| UX покупця |
Вищий (порівняння цін) |
Нижчий (багато дублів) |
| Складність розробки |
Висока (модерація атрибутів) |
Середня |
| Конверсія покупки |
На 25% вища |
Нижча |
Для нішевого B2B маркетплейсу ми частіше обираємо per-vendor — швидше запускається. Для горизонтального retail з сотнями продавців — unified-каталог дає кращий UX.
Пайплайн модерації: автоматика та ручна верифікація
Маркетплейс несе відповідальність за контент продавців. Типові проблеми: підроблені товари, заборонені категорії, маніпуляція цінами, фейкові відгуки. Вибудовуємо трирівневий пайплайн:
- Автоматичні перевірки при публікації: обов'язкові поля, відповідність категорії, стоп-лист слів, дублікати через хеш зображення.
- AI-класифікація (Amazon Rekognition або Vertex AI Vision) — детекція забороненого контенту та визначення категорії.
- Черга ручної перевірки для 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+ успішних проектів. Зв'яжіться з нами для попередньої оцінки вашого маркетплейсу — отримайте консультацію з архітектури та розрахунку виплат. Замовте аудит поточної платформи — виявимо вузькі місця та запропонуємо оптимізацію.
