Как принимать оплату картами рассрочки в RetailCRM

Карты «Халва», «Магнит» и «Карта покупок» можно учитывать в CRM как отдельные способы оплаты, если интернет-магазин подключил соответствующий сервис рассрочки через банк, платёжный сервис или платёжный шлюз. RetailCRM в таком сценарии хранит заказ, выбранный способ оплаты, статус платежа, возврат и историю общения с покупателем. В статье разберём, какие данные передавать между сайтом, оплатой и CRM, как построить обработку заказа и где чаще всего возникают ошибки.

Что нужно подготовить до подключения рассрочки?

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

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

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

Как связать сайт, сервис рассрочки и CRM?

Рабочая схема состоит из нескольких последовательных действий. Покупатель оформляет заказ на сайте, выбирает карту «Халва», «Магнит» или «Карта покупок», после чего переходит на платёжную страницу либо подтверждает операцию в подключённом сервисе. Сервис сообщает сайту результат операции. Сайт передаёт этот результат в CRM вместе с номером заказа и суммой.

1. Сайт создаёт заказ в CRM с признаком «ожидает оплаты».
2. CRM или сайт передаёт покупателю ссылку или форму оплаты.
3. Платёжный сервис возвращает результат: оплата подтверждена, отклонена, отменена или ещё обрабатывается.
4. CRM меняет статус заказа только после подтверждённого ответа сервиса.
5. Менеджер получает задачу на сборку и видит выбранный способ оплаты в карточке заказа.

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

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

Как настроить обработку заказов в RetailCRM?

В CRM создайте отдельные способы оплаты с понятными названиями. Например: «Халва», «Магнит», «Карта покупок», «банковская карта» и «наличные при получении». Такое разделение помогает фильтровать заказы и проверять, сколько операций по каждому методу завершилось успешно.

Затем настройте правила перехода по этапам. Заказ с выбранной картой рассрочки не должен автоматически уходить на сборку сразу после нажатия кнопки «Оплатить». Система может получить заказ, но платёж ещё не будет подтверждён. Перевод на сборку выполняйте после статуса успешной оплаты, который пришёл от платёжного сервиса.

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

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

Как проводить возврат по карте рассрочки?

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

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

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

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

Какие ошибки возникают при подключении рассрочки?

• Заказ переводят на сборку после нажатия кнопки оплаты, хотя сервис ещё не подтвердил операцию.
• В CRM передают только название карты, но не сохраняют внешний идентификатор платежа.
• Для «Халвы», «Магнита» и «Карты покупок» используют один общий способ оплаты, поэтому отчёты теряют детализацию.
• Возврат проводят вручную в банковском кабинете и не фиксируют его в карточке заказа.
• Повторную попытку оплаты связывают со старой операцией, из-за чего статусы заказов меняются ошибочно.
• Менеджер не видит причину отказа и повторно отправляет клиенту ту же нерабочую ссылку.

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

Оплату рассрочкой лучше рассматривать как отдельную ветку процесса продаж. Для неё нужны свои статусы, поля и правила возврата, но сама карточка клиента и история заказов остаются общими. Если магазин хочет связать платежи с рекламными источниками и фактической выручкой, пригодится сквозная аналитика для малого бизнеса в 2026 году: она помогает смотреть на завершённые заказы, а не только на заявки и посещения.