Підключити платіжну систему Wayforpay до одностороннього

О компании и текущей работе Компания продает товары через: несколько магазинов 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. Тільки тим, хто мав подібний досвід. Ціна — за домовленістю