Интеграция Битрикс24 с оплатой и доставкой: как принимать платежи и оформлять отправки из CRM

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

Что даёт интеграция оплат и доставки с Битрикс24

Интеграция нужна, если в компании есть хотя бы один из процессов: клиенту отправляют платёжную ссылку из сделки; менеджер вручную проверяет оплату в кабинете банка; доставка оформляется отдельно в кабинете СДЭК, Яндекс Доставки или Почты России; трек-номер копируют в CRM вручную; клиент спрашивает «где заказ», а менеджер ищет ответ в разных системах; статус оплаты и доставки не связаны со стадиями сделки.

Сквозной процесс: от сделки до вручения

Правильная интеграция строится не вокруг отдельной кнопки «оплатить», а вокруг полного пути клиента.

Бизнесу важно не название метода API, а результат: менеджер должен видеть, что клиент оплатил и где сейчас заказ.

Какие данные нужно хранить в CRM

Чтобы интеграция работала стабильно, в Битрикс24 нужно хранить не только сумму и имя клиента. Для оплат и доставки нужны отдельные поля.

Битрикс24 + ЮKassa: оплата из сделки и контроль статуса платежа

Ключевые запросы: юкасса битрикс24, оплата из сделки битрикс24, платёжная ссылка битрикс24, подключить ЮKassa к Битрикс24.

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

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

Нюансы, о которых часто забывают

• Не храните данные банковских карт в Битрикс24. CRM хранит ссылку, ID платежа и статус, но не номер карты и не CVV.
• Проверяйте сумму перед созданием ссылки. Если менеджер изменил товары после отправки ссылки, старая ссылка может стать неактуальной.
• Фиксируйте внешний ID платежа. Без него сложно сопоставить платёж в ЮKassa и сделку в Битрикс24.
• Продумайте возвраты. Возврат не должен просто закрывать сделку как проигранную — лучше хранить отдельный статус и причину.
• Учитывайте чеки. Если бизнес обязан фискализировать платежи, проверьте, кто формирует чек: платёжный сервис, онлайн-касса или учётная система.

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

Битрикс24 + CloudPayments: платёжные ссылки и уведомления в CRM

Ключевые запросы: cloudpayments битрикс24, платёжная ссылка битрикс24, cloudpayments CRM, оплата из CRM.

CloudPayments часто выбирают за удобный платёжный сценарий: платёжные ссылки, виджет оплаты, рекуррентные платежи, уведомления и онлайн-чеки. Для Битрикс24 это полезно, когда сделка уже создана, а оплату нужно быстро принять без отдельного сайта.

Что стоит передавать в платёж: ID сделки, номер заказа, сумму, email/телефон для уведомления и чека, состав заказа, UTM или источник. Менеджеру не нужно заходить в личный кабинет CloudPayments — он работает в Битрикс24, видит статус, получает задачу при ошибке и переводит сделку дальше только после успешной оплаты.

Важные нюансы

• Callback должен быть защищён. Нельзя слепо доверять входящему запросу: нужно проверять подпись или секрет.
• Платёжная ссылка должна быть одноразовой или привязанной к заказу. Иначе клиент может оплатить не тот заказ или старую сумму.
• Статус оплаты лучше хранить отдельно от стадии сделки. Стадия показывает бизнес-процесс, а поле оплаты — финансовый факт.
• Возвраты и отмены нужны в CRM. Иначе менеджер будет видеть «оплачено», хотя деньги уже вернули.

Битрикс24 + Т-Банк эквайринг: платёжная ссылка, СБП и эквайринг в CRM

Ключевые запросы: тинькофф касса битрикс24, т банк эквайринг битрикс24, эквайринг битрикс24, платёжная ссылка битрикс24.

Т-Банк эквайринг используют компании, которым нужен приём оплат на сайте, в приложении, мессенджерах или через платёжные ссылки. В связке с Битрикс24 это помогает принимать оплату прямо из сделки и автоматически менять статус заказа.

Что важно проверить перед внедрением

• Тестовый и боевой контур. Сначала проверить оплату на тестовой среде, затем переводить на production.
• Сопоставление ID заказа. В платёж нужно передавать ID сделки или номер заказа, чтобы потом найти нужную карточку.
• Состав чека. При фискализации нужно передавать товары, ставки НДС, количество, цену и признак способа расчёта.
• Отложенные статусы. Не все статусы приходят мгновенно — лучше делать повторную проверку по расписанию.
• Разные способы оплаты. Карта, СБП и pay-сервисы могут иметь разные статусы, комиссии и сценарии отказов.

Битрикс24 + СДЭК: накладная из CRM и статусы доставки в сделке

Ключевые запросы: сдэк битрикс24, накладная сдэк из CRM, СДЭК из Битрикс24, трек номер СДЭК в CRM.

СДЭК — частый выбор для интернет-магазинов, оптовых продавцов, сервисных компаний и B2B-доставки. Интеграция нужна, чтобы менеджер не оформлял отправку вручную в личном кабинете, а создавал накладную из сделки.

Для накладной нужны: ФИО и телефон получателя, город, адрес или код ПВЗ, вес, габариты, количество мест, состав отправления, объявленная стоимость, способ оплаты доставки, комментарий для курьера.

Нюансы СДЭК, которые важно учесть

• ПВЗ и адрес — разные сценарии. Для пункта выдачи нужен код ПВЗ, для курьерской — полный адрес.
• Габариты и вес обязательны для точного расчёта. Без них стоимость доставки будет неточной.
• Склад должен видеть, что печатать. В CRM лучше хранить ссылку на этикетку или кнопку печати.
• Статус доставки не равен стадии сделки. Сделка может быть «оплачена», а доставка — «создана», «передана», «в пути», «ожидает в ПВЗ», «вручена».
• Наложенный платёж требует отдельной логики. Если клиент платит при получении, CRM должна отличать оплату товара от оплаты доставки.

Битрикс24 + Яндекс Доставка: курьерская доставка из CRM

Ключевые запросы: яндекс доставка битрикс24, курьерская доставка из CRM, Яндекс Доставка из сделки.

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

Нюансы, которые стоит знать

• Создание заявки ≠ заказ принят в работу. Нужно получать и хранить итоговый статус заявки.
• Адреса лучше валидировать заранее. Ошибка в квартире или корпусе может сорвать срочную доставку.
• Курьерская доставка требует SLA. Если курьер не назначен или доставка задерживается, CRM должна ставить задачу ответственному.
• Для разных городов и тарифов условия отличаются. Не стоит жёстко зашивать правила без проверки доступности.
• Отмена доставки должна возвращаться в сделку. Иначе заказ будет выглядеть как доставляемый, хотя заявка отменена.

Битрикс24 + Почта России: трек-номер в CRM и контроль отправлений

Ключевые запросы: почта россии битрикс24, трек номер в CRM, отслеживание отправлений в CRM.

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

В CRM полезны статусы: отправление создано, передано в отделение, принято Почтой России, в пути, прибыло в место вручения, ожидает получателя, вручено, возврат, проблема доставки. Хранить стоит трек-номер, ID отправления, индексы отправителя и получателя, тип отправления, вес, объявленную ценность, стоимость, статус и дату последнего обновления.

Нюансы Почты России

• Трек-номер — отдельное поле, а не комментарий. Тогда его можно использовать в фильтрах, роботах и уведомлениях.
• Статусы нужно обновлять по расписанию. Не все события удобно получать мгновенно.
• Возвраты — отдельный бизнес-процесс. Возврат влияет на оплату, склад, повторную отправку и коммуникацию.
• Индекс и адрес лучше проверять до создания отправления. Ошибка может привести к возврату.
• Для массовых отправлений нужен журнал пачек. Иначе сложно понять, какие заказы уже переданы в отделение.

Оплата + доставка в одной сделке: лучшие сценарии

Сценарий 1. Интернет-магазин без сложной ERP

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

Сценарий 2. Услуга с предоплатой

Доставка не нужна, но важны статус оплаты, чек, напоминания и автоматическое назначение исполнителя.

Сценарий 3. B2B-продажа с доставкой документов

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

Сценарий 4. Региональная отправка товара

Ключевой показатель — не только факт оплаты, но и вручение. Руководителю важно видеть заказы, которые оплачены, но не доставлены.

Готовый набор полей для Битрикс24

Для внедрения можно создать отдельную группу полей в сделке — «Оплата и доставка».

Поля оплаты

Поля доставки

Дополнительно для синхронизации: внешний ID заказа (антидубли), дата последней синхронизации, статус синхронизации, количество попыток, ответственный за ошибку.

Технические нюансы, важные для бизнеса

1. Платёжная ссылка — это не просто URL

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

2. Статус оплаты должен приходить от платёжной системы

Нельзя считать сделку оплаченной только потому, что менеджер нажал «отправить ссылку». Оплаченным заказ становится после подтверждения от ЮKassa, CloudPayments или Т-Банка.

3. У доставки есть свой жизненный цикл

Доставка не ограничивается созданием накладной. У неё есть статусы: создана, передана в службу, в пути, прибыла, ожидает клиента, вручена, отменена, возвращается. Эти статусы нужно хранить отдельно.

4. Адрес — главный источник ошибок

Перед созданием доставки нужно проверять город, индекс, улицу, дом, квартиру, ПВЗ, телефон и комментарий. Хорошо, если CRM не даёт создать накладную без обязательных данных.

5. Нужно разделять оплату товара и оплату доставки

Клиент может платить товар онлайн, а доставку отдельно или при получении. Если не разделить эти суммы, отчёты будут неверными.

6. Webhook может не дойти

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

7. Роботы должны реагировать на факты, а не на намерения

Неправильно: отправили ссылку → перевели в «Оплачено». Правильно: получили подтверждение оплаты → перевели в «Оплачено». Неправильно: создали доставку → закрыли сделку. Правильно: доставка вручена → закрыли сделку или запустили запрос отзыва.

Что выбрать: готовое приложение, n8n или Python-интеграция

Готового приложения достаточно, если: один платёжный сервис, один канал доставки, простые статусы, мало заказов, нет сложной фискализации. Кастомная интеграция лучше при нескольких платёжных системах, разных юрлицах и складах, частичных оплатах, наложенном платеже, сложных возвратах, контроле SLA доставки и интеграции с 1С, МойСклад или интернет-магазином.

Пример архитектуры на Python

Bitrix24 CRM
    ↓ событие сделки
Integration API на Python
    ↓
Payment Provider API (ЮKassa / CloudPayments / Т-Банк)
    ↓ webhook статуса
Очередь обработки
    ↓
Bitrix24 обновляет оплату
    ↓
Delivery Provider API (СДЭК / Яндекс Доставка / Почта России)
    ↓ webhook или poll статуса
CRM обновляет доставку

В production-версии нужны очередь задач, retry, логирование, проверка подписи, хранение внешних ID и защита токенов.

Типовые ошибки при внедрении

Ошибка 1. Создают оплату без проверки состава заказа

Если в сделке поменялись товары, а ссылка уже отправлена, клиент может оплатить неправильную сумму. Решение: блокировать изменение суммы после создания ссылки или пересоздавать платёж.

Ошибка 2. Не сохраняют ID платежа

Без внешнего ID невозможно надёжно сопоставить платёж и сделку. Комментария «клиент оплатил» недостаточно.

Ошибка 3. Смешивают стадии сделки и статусы доставки

Стадия «в работе» и статус «доставляется» — разные вещи. Если их смешать, CRM станет неудобной для менеджеров и отчётов.

Ошибка 4. Не обрабатывают возвраты

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

Ошибка 5. Не валидируют адрес

Самая частая логистическая ошибка — неверный адрес, индекс, телефон или ПВЗ. Лучше проверить данные до создания накладной.

Ошибка 6. Не назначают ответственного за сбой

Если ошибка видна только разработчику в логах, бизнес-процесс остановится. Ошибка должна создавать задачу в Битрикс24.

Ошибка 7. Не проверяют статусы повторно

Webhook может не прийти. Критичные статусы оплаты и доставки нужно периодически сверять с провайдером.

Чек-лист перед запуском

• Какие платёжные системы нужны: ЮKassa, CloudPayments, Т-Банк.
• Какие доставки нужны: СДЭК, Яндекс Доставка, Почта России.
• Где формируется сумма заказа и где хранится состав товаров.
• Кто формирует чек.
• Нужен ли возврат и бывают ли частичные оплаты.
• Кто оплачивает доставку.
• Где хранится адрес доставки и как выбирается ПВЗ.
• Какие статусы доставки нужны менеджеру.
• Как клиент получает ссылку на оплату и трек-номер.
• Что делать при ошибке оплаты и отмене доставки.
• Какие отчёты нужны руководителю.
• Кто отвечает за поддержку интеграции.

FAQ