Цифровые сервисы: практика

Интеграция CRM с мобильным приложением: чек-лист проверки безопасности, поддержки и оплаты

Автор и проверка: Алексей Воронов, редакционный координатор ormobil.com · Факты, документы, риски и применимость · Обновлено: 06 сентября 2025 г.

Перед интеграцией CRM с мобильным приложением нужно проверить не только API, но и безопасность данных, сценарии оплаты, поддержку после релиза, права пользователей, логи и порядок исправлений. Практичный минимум:

Критерии выбора

Интеграция CRM с мобильным приложением обычно нужна, когда клиентские действия в приложении должны сразу попадать в CRM: заявка, заказ, оплата, обращение в поддержку, статус доставки, запись на услугу, бонусы или история покупок. Ошибка на этом участке влияет не только на удобство, но и на деньги, персональные данные и работу менеджеров.

Что изменилось и что важно проверять сейчас

В 2025–2026 годах требования к таким интеграциям стали строже по нескольким причинам:

• компании чаще используют несколько каналов продаж: приложение, сайт, мессенджеры, офлайн-точки;

• платежи в приложении должны корректно связываться с заказом, кассой, чеком и CRM-сделкой;

• растет внимание к персональным данным, журналам доступа и хранению токенов;

• пользователи ожидают быстрый статус заказа: задержка синхронизации даже на 10–15 минут может создавать обращения в поддержку;

• бизнесу нужны отчеты по источникам, повторным покупкам, LTV, отказам и возвратам.

Поэтому выбирать подрядчика или технический вариант нужно не по фразе «интегрируем CRM», а по конкретным проверкам.

Основные критерии выбора интеграции

1. Совместимость CRM и мобильного приложения

Проверьте, есть ли у CRM открытый API, webhooks, лимиты запросов, документация, sandbox-среда и возможность работы с нужными сущностями: клиенты, сделки, заказы, оплаты, статусы, обращения, бонусы.

2. Безопасность доступа

Нужны OAuth 2.0, OpenID Connect, JWT с коротким сроком жизни, refresh-токены, разграничение прав, шифрование HTTPS/TLS, хранение секретов не в коде приложения, а на backend-стороне.

3. Персональные данные и документы

Для проекта заранее готовят:

• техническое задание;

• схему обработки персональных данных;

• политику конфиденциальности;

• пользовательское соглашение;

• договор с подрядчиком;

• акт приема-передачи работ;

• SLA или регламент поддержки;

• описание API и сценариев обмена.

4. Оплаты и возвраты

Если приложение принимает деньги, проверяйте связку: мобильное приложение → платежный шлюз → касса/чек → CRM → статус заказа. Комиссия эквайринга обычно составляет примерно 1,5–3,5%, а исправление ошибок в платежной логике после релиза может стоить дороже, чем тестирование до запуска.

5. Поддержка после релиза

Интеграция не заканчивается публикацией приложения. CRM обновляется, платежные провайдеры меняют API, мобильные ОС выпускают новые версии. Минимально нужен период гарантии 1–3 месяца и понятный тариф на поддержку: например, фиксированный пакет часов или SLA с реакцией 4–24 часа.

6. Сроки и бюджет

Простая интеграция формы заявки с CRM может занять 5–10 рабочих дней. Интеграция заказов, оплат, бонусов, push-уведомлений и личного кабинета — 3–8 недель. Стоимость зависит от CRM, количества сущностей и качества API: условно от 80–150 тыс. рублей за базовую связку до 500 тыс. рублей и выше за сложную интеграцию с оплатами, ролями и аналитикой.

Для тиража или проекта запросите 3 сметы: базовую, оптимальную и срочную; отдельно отметьте сроки 3–7 дней, гарантию и стоимость переделки.

Критерии проверки

| Блок | Что проверить | Какой результат считать нормальным |

|---|---|---|

| API CRM | Документация, лимиты, webhooks, sandbox | Есть описание методов, тестовый доступ, понятные ограничения |

| Данные клиентов | ФИО, телефон, email, согласия, история заказов | Нет дублей, поля сопоставлены, есть правила обновления |

| Авторизация | OAuth/JWT, срок действия токенов, refresh-механика | Пользователь не получает доступ к чужим данным |

| Роли | Клиент, менеджер, администратор, оператор поддержки | Каждая роль видит только разрешенные данные |

| Оплаты | Успешный платеж, отказ, возврат, частичная оплата | Статусы в CRM совпадают с платежным шлюзом |

| Чеки и документы | Онлайн-касса, чек, статус фискализации | Чек формируется и привязан к заказу |

| Логи | Ошибки API, платежи, авторизация, изменения статусов | Есть журнал событий без раскрытия лишних данных |

| Поддержка | SLA, каналы связи, время реакции | Зафиксированы сроки реакции и исправления |

| Тестирование | Тест-кейсы, тестовые карты, нагрузочные проверки | Критические сценарии пройдены до релиза |

| Передача проекта | Репозиторий, инструкции, доступы, акты | Клиент получает управляемую систему, а не «черный ящик» |

Проверьте портфолио, техническое задание, смету, сроки, гарантию, порядок правок, поддержку и документы на материалы или услугу.

Сравнение вариантов

Выбор способа интеграции зависит от CRM, нагрузки, сценариев приложения и бюджета. Ниже — практическое сравнение.

Вариант 1. Готовый коннектор CRM

Подходит, если CRM популярная, а сценарии типовые: передача заявки, создание сделки, обновление статуса, отправка уведомления менеджеру.

Плюсы:

• быстрее запуск: иногда 2–7 дней;

• ниже стартовая стоимость;

• меньше разработки;

• часто есть готовая документация.

Минусы:

• ограниченная логика;

• сложнее настроить нестандартные поля;

• возможны лимиты по количеству запросов;

• не всегда подходит для оплат и сложных личных кабинетов.

Когда выбирать:

если нужно быстро проверить гипотезу, запустить MVP или связать приложение с CRM без сложных сценариев.

Что проверить:

кто отвечает за сбой коннектора, где хранятся токены, есть ли журнал ошибок, можно ли выгрузить историю операций.

Вариант 2. Кастомная интеграция через API

Это наиболее гибкий способ: backend приложения обменивается данными с CRM через API, webhooks и очереди сообщений.

Плюсы:

• можно настроить сложные сценарии;

• лучше контроль безопасности;

• удобно подключать платежи, бонусы, статусы, аналитику;

• легче масштабировать.

Минусы:

• дольше разработка: обычно 3–8 недель;

• выше стоимость;

• нужно сопровождение;

• требуется полноценное ТЗ и тестирование.

Когда выбирать:

если приложение — важный канал продаж или сервиса, есть оплаты, личный кабинет, статусы заказов, программы лояльности, несколько ролей пользователей.

Что проверить:

архитектуру, обработку ошибок, повторные попытки отправки данных, защиту от дублей, idempotency для платежей, логи и мониторинг.

Вариант 3. Интеграция через промежуточную платформу

Иногда используют iPaaS, шину данных или middleware: приложение передает данные в промежуточный слой, а он уже связывает CRM, платежи, склад, рассылки и аналитику.

Плюсы:

• удобно, если систем много;

• проще менять одну CRM на другую;

• можно централизовать логи и правила обмена;

• полезно для масштабных проектов.

Минусы:

• появляется дополнительная точка отказа;

• растет стоимость сопровождения;

• нужна архитектурная дисциплина;

• не всегда оправдано для небольшого приложения.

Когда выбирать:

если кроме CRM есть ERP, склад, call-центр, BI, программа лояльности, несколько мобильных приложений или филиальная сеть.

Что может пойти не так

Типовые риски: нет ТЗ, размытые сроки, устные правки, скрытая стоимость материалов, неподходящий формат файлов или отсутствие поддержки.

Для интеграции CRM с мобильным приложением это обычно проявляется так:

• заявки создаются в CRM без источника или с неверным менеджером;

• один клиент появляется в базе 2–5 раз из-за разных телефонов или email;

• успешная оплата не меняет статус заказа;

• возврат прошел в платежном шлюзе, но не отразился в CRM;

• push-уведомление ушло раньше, чем CRM подтвердила статус;

• менеджер видит персональные данные, которые не должен видеть;

• приложение работает на тестовом API, но ломается на боевом из-за лимитов;

• подрядчик не передал документацию, и следующий разработчик не может поддерживать интеграцию.

Когда интеграция не подходит или ее лучше отложить

Интеграцию не стоит запускать сразу, если:

• в CRM нет чистых справочников, статусов и ответственных;

• бизнес-процесс меняется каждую неделю;

• нет владельца процесса со стороны заказчика;

• не определены правила обработки дублей;

• неизвестно, какие данные должны попадать в приложение;

• платежная схема не согласована с бухгалтерией и юридическим блоком;

• нет бюджета на поддержку после релиза.

В таких случаях лучше сначала описать процессы, очистить CRM, согласовать статусы и только потом подключать мобильное приложение.

1. Данные и бизнес-логика

• [ ] Определены сущности: клиент, заказ, сделка, обращение, платеж, возврат, бонусы.

• [ ] Есть таблица соответствия полей приложения и CRM.

• [ ] Описаны обязательные поля и формат данных.

• [ ] Указаны правила обновления: что главнее — данные из CRM или из приложения.

• [ ] Настроена защита от дублей клиентов.

• [ ] Есть правила для статусов: «создан», «оплачен», «в работе», «доставлен», «отменен», «возврат».

2. Безопасность

• [ ] Используется HTTPS/TLS.

• [ ] Секретные ключи не хранятся в мобильном приложении.

• [ ] Есть серверный слой между приложением и CRM.

• [ ] Токены имеют ограниченный срок действия.

• [ ] Настроены роли и права доступа.

• [ ] Логи не содержат полные банковские данные, пароли и лишние персональные данные.

• [ ] Есть механизм блокировки пользователя или сессии.

• [ ] Проверены сценарии потери телефона, смены номера, восстановления доступа.

3. Оплаты

• [ ] Выбран платежный провайдер.

• [ ] Проверены комиссии: например, 1,5–3,5% за эквайринг в зависимости от условий.

• [ ] Описаны успешный платеж, отказ, отмена, возврат, частичный возврат.

• [ ] Настроена idempotency, чтобы один заказ не оплатился дважды.

• [ ] Проверена привязка платежа к заказу в CRM.

• [ ] Проверена передача статуса чека.

• [ ] Подготовлены тестовые платежи и тестовые карты.

• [ ] Определено, кто разбирает спорные платежи: поддержка, бухгалтерия, подрядчик.

4. Поддержка и эксплуатация

• [ ] В договоре указан гарантийный срок.

• [ ] Есть SLA: время реакции и время исправления.

• [ ] Определены каналы поддержки: почта, трекер, чат, телефон.

• [ ] Указана стоимость часа доработок.

• [ ] Есть регламент обновлений CRM и мобильного приложения.

• [ ] Настроен мониторинг ошибок API.

• [ ] Есть резервный план, если CRM временно недоступна.

• [ ] Подрядчик передает документацию и инструкции.

5. Приемка работ

• [ ] Согласованы тест-кейсы.

• [ ] Проведен тест на 20–50 типовых операций: регистрация, заказ, оплата, отмена, возврат, обращение в поддержку.

• [ ] Проверены разные роли пользователей.

• [ ] Проверена работа на iOS и Android.

• [ ] Проверена нагрузка: например, 100–500 одновременных операций, если это соответствует масштабу проекта.

• [ ] Ошибки зафиксированы в трекере, а не в устной переписке.

• [ ] Подписан акт только после устранения критических дефектов.

Какие вопросы задать подрядчику

1. Какие CRM вы уже интегрировали с мобильными приложениями?

2. Можете показать похожий кейс без раскрытия коммерческой тайны?

3. Кто пишет техническое задание?

4. Как вы защищаете API-ключи и токены?

5. Как обрабатываются повторные платежные уведомления?

6. Что происходит, если CRM недоступна 10 минут или 2 часа?

7. Где будут храниться логи и сколько времени?

8. Что входит в гарантию, а что считается доработкой?

9. Сколько стоит срочное исправление после релиза?

10. Какие документы и доступы вы передаете после завершения работ?

Внутренние материалы, которые стоит подготовить заранее

Перед стартом полезно отдельно собрать:

• карту бизнес-процессов;

• список ролей и прав;

• описание статусов заказов;

• перечень персональных данных;

• схему оплат и возвратов;

• требования к отчетам;

• список интеграций кроме CRM: касса, склад, рассылки, аналитика, поддержка.

Дополнительно можно изучить связанные темы:

• [как составить техническое задание на мобильное приложение](/tehnicheskoe-zadanie-na-mobilnoe-prilozhenie);

• [выбор подрядчика для разработки мобильного приложения](/vybor-podryadchika-dlya-mobilnogo-prilozheniya);

• [приемка цифрового проекта перед запуском](/priemka-cifrovogo-proekta).

Сколько времени занимает интеграция CRM с мобильным приложением?

Базовая интеграция заявки или формы может занять 5–10 рабочих дней. Интеграция с личным кабинетом, заказами, оплатами, возвратами, push-уведомлениями и аналитикой обычно занимает 3–8 недель. Если CRM плохо документирована или процессы не описаны, срок может увеличиться.

Сколько стоит такая интеграция?

Ориентир для простой связки — от 80–150 тыс. рублей. Средний проект с заказами, статусами и платежами может стоить 250–700 тыс. рублей. Сложные интеграции с несколькими системами, ролями, очередями, мониторингом и поддержкой могут стоить выше 1 млн рублей.

Нужно ли подключать CRM напрямую к мобильному приложению?

Чаще всего нет. Безопаснее использовать backend-прослойку: мобильное приложение обращается к вашему серверу, а сервер уже работает с CRM. Так проще защитить ключи, контролировать роли, фильтровать данные и логировать ошибки.

Что важнее проверить в оплатах?

Проверьте четыре сценария: успешная оплата, отказ, возврат и повторное уведомление от платежного провайдера. Особенно важно, чтобы статус заказа в CRM совпадал с фактическим статусом платежа, а один заказ не мог быть оплачен дважды.

Кто должен писать техническое задание?

Лучше, если ТЗ готовится совместно: бизнес описывает процессы и правила, подрядчик переводит их в технические требования. В финальном документе должны быть поля данных, сценарии, роли, статусы, ошибки, API, тест-кейсы и критерии приемки.

Можно ли запустить интеграцию без поддержки?

Технически можно, но это рискованно. После релиза могут измениться API CRM, версии iOS и Android, платежные требования, логика статусов или бизнес-процессы. Минимально стоит заложить 1–3 месяца гарантии и отдельный договор поддержки.

Какие ошибки чаще всего находят после запуска?

Частые ошибки: дубли клиентов, неверные статусы заказов, потерянные платежные уведомления, отсутствие логов, слишком широкие права менеджеров, неочевидные ошибки авторизации и несогласованные возвраты.

Что запросить у подрядчика до оплаты работ?

Запросите портфолио, техническое задание, смету, сроки, гарантию, порядок правок, SLA поддержки, список передаваемых документов, описание прав на код и инструкцию по эксплуатации. Для сравнения запросите три сметы: базовую, оптимальную и срочную.