Вибір платіжного рішення для майданчика — не те саме, що вибір для магазину. Магазин питає про ставку і швидкість надходження грошей. Майданчику треба запитати, хто заводить продавців, хто тримає їхні баланси, хто відповідає, коли замовлення не відбулося, і що станеться в день, коли продавець виявиться проблемою.
Більшість провайдерів добре відповідає на перше питання і розпливчасто — на решту. Список нижче саме й відділяє рішення, побудоване для майданчиків, від магазинного продукту з підписом «для маркетплейсів» на сторінці тарифів.
Онбординг продавців — те, що визначає ваше навантаження
Кожного продавця треба ідентифікувати до того, як він отримає гроші. Питання в тому, хто робить цю роботу і скільки її впаде на вашу підтримку.
Запитайте, чи йде онбординг через API, який ви вбудуєте у власну реєстрацію продавця, чи продавця перекинуть на форму, якої він не впізнає. Запитайте, скільки триває схвалення і яка частка отримує відмову. Запитайте, що відбувається з продавцем, що застряг на перевірці: він може виставляти товари, але не отримувати виплати, чи заморожено все? Майданчик, який не вміє заводити продавця за день, втрачає його на користь того, який уміє.
Наша частина цієї роботи пов’язана з налаштуванням мерчант-рахунку, а сам рахунок відкривається від 5 днів, коли документи зібрані.
Рух грошей, яким ви керуєте
Рішення має вміти три речі без ручної роботи: поділити вхідний платіж, притримати частку до вашої команди і виплатити продавцям за графіком, який задаєте ви. Якщо хоча б одне потребує таблиці, ви вестимете цю таблицю щотижня стільки, скільки живе майданчик.
Конкретно: перевірте, чи може комісія бути відсотком, фіксованою сумою або і тим і іншим одразу — більшості майданчиків зрештою потрібно і те, і те. Перевірте, чи можна утримувати кошти за замовленням, а не за продавцем: спори прив’язані до замовлень. І перевірте, чи можна скасувати виплату, доки вона не пішла, — це знадобиться першого ж разу, коли шахрайське замовлення проскочить. Як це влаштовано технічно, описано в розділі обробки платежів.
Звітність, яка переживе перевірку
Майданчики переростають власну бухгалтерію швидше за магазини, бо кожне євро, що проходить через вас, частину шляху належить комусь іншому. До підписання попросіть показати справжній звіт про розрахунки, а не скриншот.
За ним ви маєте без розробника відповісти на три питання: скільки заробив такий-то продавець минулого місяця, з яких замовлень складається така-то виплата і де лежать гроші, які ще не виплачені. Якщо звіт так не вміє, фінансисти зберуть його в таблиці, і до третього кварталу таблиця брехатиме.
Де чекають баланси продавців між збором і виплатою, теж важить. Окремий бізнес-IBAN тримає ці гроші відокремлюваними від вашої виручки, і розмова з аудитором стає короткою.
Що відбувається, коли продавець виявляється поганим
Цей сценарій ніхто не показує на демо, і він же коштує найдорожче. Продавець набрав замовлень, не відвантажив, зник. Покупці відкривають спори. Гроші вже виплачені.
Запитайте прямо: чи можна миттєво зупинити виплати конкретному продавцю, чи для цього потрібна заявка в підтримку? Чи можна автоматично утримати збиток за чарджбеком із його майбутніх заробітків? Чи приходить сигнал, коли в одного продавця зростає частка спорів, чи ви дізнаєтеся про це від еквайра? Рішення, яке добре відповідає на ці три питання, варте переплати, бо альтернатива — платити за збитки самому.
Питання щодо комерційної частини
У майданчиків більше рухомих частин у тарифі, ніж у магазинів. Крім ставки за обробку, яка для middle-risk майданчиків починається від 1,8%, зазвичай є плата за виплату, іноді плата за заведеного продавця і подекуди місячна плата за платформу. Модель із дешевою обробкою і дорогими виплатами пасує майданчику з великими замовленнями й невеликою кількістю продавців і руйнує майданчик зі зворотним профілем.
Візьміть свої реальні числа — замовлень на місяць, середній чек, кількість продавців, періодичність виплат — і порахуйте все цілком, а не одну ставку. Структура — на сторінці тарифів.
Що перевірити на пілоті
Демо будують так, щоб воно пройшло успішно, тому корисне порівняння відбувається на ваших власних даних. Попросіть пісочницю і проженіть чотири сценарії до підписання: звичайне замовлення зі сплітом, повернення після того, як продавцю вже виплатили, спір за доставленим замовленням і продавця, який не пройшов перевірку на середині.
Ці чотири закривають шляхи, якими реально ходитиме ваша підтримка. Повернення після виплати дивує найсильніше, бо гроші мають звідкись узятися, і хто їх несе — майданчик чи продавець — це налаштування, а не закон природи.
Заразом подивіться, як виплати виглядають з боку продавця: за цим екраном продавці й судять про майданчик.
Часті питання зібрані в розділі запитань.
Короткий чек-лист
- Онбординг продавців через ваш інтерфейс, а не через перекидання.
- Поділ, утримання і виплата без ручних кроків.
- Комісія відсотком, фіксованою сумою або обома одразу.
- Зупинка виплат і утримання збитку за конкретним продавцем.
- Звіти, які розгортають виплату в список замовлень.
- Частка спорів видна за продавцем, а не лише за майданчиком.
Якщо провайдер закриває всі шість пунктів, інтеграція — проста частина. Якщо чотири, решту два ви побудуєте самі, і про цю вартість краще знати до договору, а не після. Механіку самого руху грошей ми розбирали окремо, у матеріалі про мерчант-рахунки.
Підключення від 5 днів. Комісія від 1,8% — прозорі умови, без прихованих платежів. Залиште заявку або замовте консультацію — ми підберемо оптимальне рішення під вашу нішу та ризиковий профіль.