Консультація щодо реалізації платіжного механізму для онлайн-платформ

Про компанію та поточну роботу Компанія продає товари через: кілька магазинів Rozetka; 5–8 магазинів Prom.ua; кілька магазинів Epicentr. Обсяг: орієнтовно 50–100 замовлень на день. Планується підключення хорошоп найближчим часомВикористовувані системи та способи оплати Rozetka; Prom.ua; Epicentr; Нова пошта; NovaPay; PrivatBank; monobank; RozetkaPay; Checkbox. Способи оплати: накладений платіж через Нову пошту / NovaPay; RozetkaPay; прямий переказ на IBAN; планується оплата за посиланням через еквайринг monobank. NovaPay та RozetkaPay перераховують гроші загальною сумою за реєстрами: в реєстрі NovaPay вказані ТТН; в реєстрі RozetkaPay вказані замовлення. Основні цілі Налаштувати KeyCRM так, щоб власник міг в одному місці: -Бачити всі замовлення з усіх магазинів. -Не втрачати замовлення та ТТН. -Бачити поточний стан кожної відправки. -Бачити фактичний рух грошей за замовленнями. -Автоматично пов'язувати отримані платежі з відповідними замовленнями. -Бачити неприв'язані платежі, недоплати, переплати та інші розбіжності. -Контролювати дії співробітників. -Мінімізувати ручну роботу.-Автоматичну фіскалізацію - Вибудувати автоматизацію правильну по руху замовлення Провести аудит діючого KeyCRM Перевірити: -поточні статуси, поля та автоматизації; -банківські та платіжні підключення; -ролі та права співробітників; -історію дій; -поточну настройку Checkbox; -можливість реалізації вимог штатними засобами KeyCRM. За результатами аудиту надати: -список знайдених проблем; -перелік необхідних налаштувань; -перелік завдань, для яких потрібна API-інтеграція або зовнішній сервіс; -рекомендації для кращої роботи сервісу -оцінку термінів та вартості. Налаштувати надходження та обробку замовлень Необхідно: налаштувати єдину послідовність обробки замовлень; налаштувати обов'язкові поля, без яких замовлення не можна передати на наступний етап; створити контроль замовлень, які не завантажились, завантажились з помилкою або залишились без відповідального. Налаштувати рух та звірку оплат Підключити до KeyCRM всі використовувані рахунки та платіжні сервіси: PrivatBank; monobank; NovaPay; RozetkaPay; еквайринг monobank після його підключення. Необхідно реалізувати: -Автоматичне отримання доступних виписок та транзакцій. -Відображення фактичних надходжень по кожному ФОП та рахунку. -Автоматичну прив'язку прямого платежу на IBAN до замовлення за номером замовлення в коментарі. -Звірку загальної виплати NovaPay з реєстром і подальшу прив'язку рядків реєстру до замовлень за ТТН. -Звірку загальної виплати RozetkaPay з реєстром і подальшу прив'язку рядків реєстру до замовлень за номером замовлення. -Автоматичну обробку оплат за посиланням після підключення еквайрингу. -Окремий список оплат, які неможливо зв'язати автоматично. Виявлення: -недоплати; -переплати; -часткової оплати; -дубльованої оплати; -оплати без знайденого замовлення; -замовлення, відміченого оплаченим без підтвердженого надходження. -Щоденну звірку сум по ФОП, рахункам та способам оплати. -Статус «Оплачено» повинен встановлюватись автоматично після підтвердженого зарахування грошей на відповідний IBAN. Співробітники не повинні мати права встановлювати його вручну. Якщо штатних можливостей KeyCRM недостатньо, інтегратор повинен: пропонувати API-інтеграцію або зовнішній модуль; описати його логіку; окремо оцінити розробку; забезпечити журнал помилок та повторну обробку; не прив'язувати оплату автоматично при неоднозначному збігу. Налаштувати контроль втрачених замовлень Потрібен окремий робочий список або звіт: замовлення надійшло, але не взято в роботу; замовлення підтверджено, але не передано на склад або дроп; замовлення готове, але ТТН не створена; ТТН створена, але посилка не передана перевізнику; посилка довго не рухається; клієнт не забирає посилку; була переадресація; почався повернення; повернена посилка не отримана компанією; замовлення доставлено, але оплата не зарахована; оплата отримана, але не пов'язана з замовленням; замовлення залишилось в проміжному статусі довше допустимого терміну. По кожному виключенню повинні бути: відповідальний; термін реакції; завдання або сповіщення; зрозуміла причина; посилання на замовлення. 4.7. Налаштувати права та контроль співробітників Обов'язкові обмеження: -співробітники не можуть видаляти замовлення; -співробітники не можуть вручну ставити статус «Оплачено»; -співробітники не мають доступу до банківських підключень, API-ключів та адміністративних налаштувань.Налаштувати Checkbox Зараз чеки з KeyCRM не створюються. Інтегратору необхідно: -перевірити існуючі кабінети, каси та касирів Checkbox; -підключити каси відповідних ФОП; -налаштувати способи оплати; -налаштувати автоматичну фіскалізацію для погоджених сценаріїв; -налаштувати обробку помилок; -налаштувати чеки повернення; -провести тестування.Налаштувати звіти для власника Власник повинен бачити: -кількість нових і необроблених замовлень; -проблемні відправлення; -посилки в відділенні; -повернення; -доставлені замовлення без отриманої оплати; -отримані, але неприв'язані платежі; -недоплати та переплати; -ручні зміни співробітників.Формат може бути реалізований штатними списками, фільтрами, аналітикою, завданнями або зовнішнім звітом — спосіб пропонує інтегратор. Навчити співробітників Після налаштування провести навчання: власника — контроль, звіти, помилки та права; менеджерів — обробка замовлень; співробітника дропа — передача замовлення та контроль ТТН; співробітника складу — створення ТТН та відправка; відповідального за фінанси — обробка неприв'язаних платежів та розбіжностей. Надати короткі інструкції або відеозаписи основних операцій. Очікуваний результат Після виконання робіт: -всі замовлення обробляються в KeyCRM; -пропущені та завислі замовлення автоматично виявляються; -кожна ТТН пов'язана з замовленням і відстежується; -проблемні посилки потрапляють відповідальним співробітникам; -банківські та платіжні надходження видимі в CRM; -однозначні платежі автоматично пов'язуються з замовленнями; -реєстри NovaPay та RozetkaPay звіряються з надходженнями та замовленнями; -неоднозначні платежі потрапляють на ручну перевірку; -співробітники не можуть видалити замовлення або вручну відзначити його оплаченим; -власник бачить рух грошей і список відхилень; -Checkbox працює за погодженими сценаріями; -команда навчена роботі. Формат пропозиції від інтегратора До початку впровадження виконавець повинен надати: -Результат аудиту. -Пропоновану схему налаштування. -Що буде реалізовано штатними засобами KeyCRM. -Що вимагатиме API або зовнішнього сервісу. -Вартість штатної настройки. -Окрему вартість розробки. -Терміни по етапах. -Перелік необхідних доступів. -План тестування та запуску.

Розробка міжнародного мобільного додатку під ключ (Дизайн + Код) Для здешевлення, можливо не робити в купити готовий дизайн 1. Загальні вимоги до проекту Платформа: Кросплатформова розробка на фреймворку Flutter (один код під iOS та Android). Тип платформи: Соціальний беттінг / Ігрові суперечки на дисципліну (Peer-to-Peer 도전戰). Завдання Виконавця: Повний цикл розробки (UI/UX Дизайн у Figma, фронтенд, бекенд-сервер, база даних, інтеграція IoT-датчика контролю та платіжного шлюзу). Мультимовність: Повна підтримка локалізації (i18n) та робота з кількома валютами. 2. Вимоги до UI/UX Дизайну Потрібна розробка сучасного, неоново-технологічного інтерфейсу в темних тонах (Dark Mode). Акцентні кольори: Глибокий графітовий (фон), яскравий зелений (фінанси, баланс), яскравий червоний (режим охорони включень, штрафні події). Функціонал: Відображення 4 головних екранів нижньої навігації (Дашборд, Ігрові кімнати, Гаманець, Налаштування пристрою). Потрібні динамічні анімації зміни балансу та спливаючих алертів. 3. Фінансова архітектура (Escrow/Holding/Split) Додаток пов'язань на утримання депозитів за дотримання правил дисципліни. Критично важливою є інтеграція платіжного шлюзу, що підтримує Split Payments (Розщеплення платежів) та Холдування коштів (Stripe Connect для глобального ринку/аналоги для локального). Логіка транзакцій (API-команди бекенда): Поповнення: Кошти користувачів прив'язуються до їх облікового запису та заморожуються на транзитному (ескроу) рахунку платіжної системи. Вони не надходять безпосередньо на рахунок компанії. Режим SOLO: При настанні тригерної події від IoT-датчика у заборонених годин бекенд дає команду платіжній системі перевести фіксовану суму (штраф) з транзитного рахунку користувача на розрахунковий рахунок компанії. Режим GROUP (Кімнаті): Користувачі формують загальний пул (наприклад, 10 осіб $10). Гроші заморожуються у межах конкретної Ігрової Кімнати. При настанні тригерного події в одного з учасників сума його штрафу автоматично розщеплюється: 15% (комісія платформи) йдуть на розрахунковий рахунок компанії, а 85% залишаються усередині призового фонду кімнати. Після закінчення терміну челенджа бекенд автоматично розподіляє нагромаджений призовий фонд між переможцями, а платіжна система робить автоматичний переказ (Payout) ним на картки. 4. Структура кабінетів Кабінет 1: "Персональний Трекер" (Режим SOLO) Індикатор статусу моніторингу (Активний/Доступний/Заблокований). Конфігуратор часових інтервалів охорони (Time Picker) та налаштування вартості штрафного тригера. Панель стану зовнішнього пристрою IoT (заряд батареї датчика у %, рівень сигналу, статус синхронізації). Кабінет 2: «Ігрові Кімнати» (Режим GROUP) Інструментарій створення приватних кімнат (генерація інвайт-посилань/кодів для друзів) та список публічних глобальних ліг. Турнірна таблиця (Лідерборд) учасників з відображенням їхнього поточного статусу в реальному часі, таймер до кінця челленджа та вбудований груповий чат. Загальний розділ: Мультивалютний гаманець Відображення балансу з автоматичним конвертуванням локальних валют у реальному часі. Історія транзакцій із прозрачним логом списань, комісій та виграшів. 5. Вимоги до Бекенду та Інтеграції IoT Стек: Node.js/Python/Go (на вибір виконавця, аргументовано). Зв'язок із IoT: Прийом пакетів даних від зовнішнього Wi-Fi модуля. Швидкість надсилання Push-повідомлення (через FCM) на смартфон при настанні події від датчика – менше 1 секунди. Антифрод-логіка: Сервер повинен аналізувати передані датчиком телеметричні дані вбудованого акселерометра (accel_x/y/z). Якщо подія відбувається при нульовій зміні осей прискорення, транзакція позначається системою як підозрілий (захист від статичного утримання датчика), користувачеві надсилається попередження.

Нам потрібно підключити платіжну систему до high risk сайту. Основні вимоги — прийом фіатних коштів та виведення коштів у криптовалюту. Бажано no kyc. Тільки тим, хто мав подібний досвід. Ціна — за домовленістю