Интеграция платежей и статусов: как связать эквайринг, кассу и…
  • Интеграции
  • Автор: Команда CrmAI
  • Опубликовано:
Интеграция платежей с CRM: схема связи эквайринга, кассы и маркетплейсов с системой управления продажами

Понедельник, 9 утра. Марат из Караганды открывает ноутбук и вздыхает — опять этот цирк. За выходные в Kaspi прошло 47 оплат, три корпоративных перевода висят в банке, шесть заказов с маркетплейса требуют внимания. И всё это нужно вручную сверить с CRM, где сделки томятся в статусе "Ожидает оплаты". А ведь клиенты-то уже заплатили! Только CRM об этом не знает.

«Каждый понедельник — одно и то же, — Марат потягивает остывший кофе. — Два часа тупо сверяю, кто заплатил. Потом ещё час разгребаю расхождения: эта оплата вообще к какой сделке? А тут недоплатили 500 тенге — это они забыли про доставку или просто округлили? К обеду голова раскалывается, а работа только началась. Иногда думаю: может, в Казахтелеком устроиться — там хоть рутина предсказуемая».

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

Сегодня я покажу, как избавиться от этого кошмара раз и навсегда. Не буду грузить теорией — только рабочие схемы с учётом казахстанских реалий. Потому что у нас всё особенное: Kaspi тут король, банковские API — это лотерея (повезёт или не повезёт), а половина клиентов до сих пор любит платить наличкой.

«Интеграция платежей — это не про технологии. Это про то, чтобы менеджер видел статус оплаты в момент звонка клиенту, а не лез в три разных системы. Одна секунда вместо пяти минут — вот реальная ценность»

Принцип «деньги видны сразу»
Revenue Operations
Цитата

Почему ручная сверка платежей убивает бизнес (медленно, но верно)

Знаете, что обычно говорят собственники? «Подумаешь, бухгалтер пару часов посидит с Excel — не сахарная же». И в этот момент я всегда хочу спросить: а вы посчитали, во сколько реально обходятся эти «пара часов»? Потому что цена гораздо выше, чем кажется. И платит её не только бухгалтер — платит весь бизнес. Причём такими способами, о которых вы даже не догадываетесь.

Вчера разговаривал с владельцем мебельного магазина в Алматы. Он думал, что проблема только в том, что бухгалтер устаёт. Оказалось — у него каждую неделю теряется по 2-3 платежа, клиенты психуют, менеджеры нервничают. А самое обидное: он терял заказы из-за того, что конкуренты отгружали быстрее просто потому, что у них всё автоматом.

Скрытые потери от ручной сверки платежей

Время = деньги (буквально)

Давайте посчитаем: 100 платежей в день, по 3 минуты на каждый — это 5 часов ежедневно. Больше 100 часов в месяц! Целая зарплата человека, который мог бы делать что-то полезное вместо перекладывания цифр из одной таблички в другую.

Ошибки и «потерянные» платежи

Люди — не роботы. К пятничному вечеру глаза уже не видят, внимательность на нуле. Платёж не привязался к сделке — менеджер решает, что клиент не заплатил, и звонит с напоминанием. А клиент-то уже заплатил! И теперь он в бешенстве.

Задержки в отгрузке

Вот классика жанра: клиент оплатил в субботу. Бухгалтер увидела только в понедельник. Склад узнал во вторник. Клиент уже три дня нервничает и пишет гневные сообщения. А ведь мог бы получить товар ещё в понедельник!

Кривая аналитика

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

Выгорание команды

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

Потолок масштабирования

Вот вам простая математика: при 100 платежах в день — ещё терпимо. При 500 — нужен отдельный человек только на сверку. При 1000 — целый отдел. Ручная работа не масштабируется, а нанимать людей всё дороже каждый год.

Знаю компанию в Шымкенте — они пять лет жили в режиме ручной сверки. «Ну работает же как-то», — говорил директор. Работало до тех пор, пока в один прекрасный день не потеряли платёж на 3 миллиона тенге. Представляете, какой это стресс? Нашли через две недели, но клиент успел разозлиться и уйти к конкуренту. А потом ещё и бухгалтер уволилась прямо перед налоговой проверкой — передать дела толком не успела, началась паника. Директор потом признался: «Дешевле было бы сразу автоматизировать, чем вот это всё разгребать».

Автоматизация платежей — это не «было бы неплохо когда-нибудь». Это базовая гигиена, как мыть руки перед едой. Без неё нормально расти не получится. Можно, конечно, продолжать терпеть и надеяться на авось, но давайте честно — оно того не стоит.

Карта платёжных источников в Казахстане: откуда приходят деньги

Ладно, хватит страшилок — давайте к делу. Прежде чем что-то интегрировать, надо понять, с чем мы вообще имеем дело. А у нас тут своя, особенная платёжная экосистема — совсем не такая, как в России, и уж точно не как на Западе. Я насчитал шесть основных источников, через которые деньги прилетают казахстанскому бизнесу. И у каждого, как водится, свои заморочки.

Kaspi QR / Kaspi Pay

Тут и объяснять не надо — Kaspi в рознице король. Уведомления прилетают мгновенно, API нормальный. Для B2C это уже стандарт.

API: Хороший

Банковский эквайринг

Классика — карточные платежи через терминалы и онлайн. Halyk, Jusan, Forte — у каждого свои причуды и особенности интеграции. Готовьтесь к сюрпризам.

API: Средний

Банковские переводы

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

API: Разный

Kaspi Магазин

Заказы с маркетплейса — это отдельная история. Оплата через Kaspi, но со своей логикой статусов и хитрыми сроками выплат продавцу. Не путайте с Kaspi QR!

API: Хороший

Другие маркетплейсы

Wildberries, Ozon — там, где они работают в Казахстане. У каждого своя система статусов, свои сроки выплат, свои API. Короче, ещё одна головная боль.

API: Разный

Наличные / Касса

Да-да, наличка никуда не делась. Особенно в регионах её по-прежнему любят. Для автоматизации нужна интеграция с онлайн-кассой (ККМ) и передача чеков в ОФД.

API: Через ККМ

Улавливаете масштаб проблемы? Обычная казахстанская компания крутится минимум с тремя источниками одновременно. Розничные клиенты платят через Kaspi, корпоративы переводят через банк, возможно, ещё и на маркетплейсе что-то продаётся. И у каждого свои правила игры: свой формат данных, свои статусы, свои задержки. Пытаешься всё это держать в голове — и к вечеру мозги закипают.

Но не пугайтесь раньше времени! Это просто реальность казахстанского рынка. Не баг, а фича, с которой приходится работать. Хорошая новость: если грамотно подойти, всё это можно привести к общему знаменателю. Плохая: просто так, за пару часов, не получится — нужно продумать архитектуру. И вот тут начинается самое интересное...

Архитектура интеграции: три уровня сложности

Окей, давайте к самому интересному — как технически всё это связать воедино. Подходов несколько: от простого «на коленке за вечер» до серьёзной архитектуры с очередями и микросервисами. Что выбрать — зависит от того, сколько у вас платежей, есть ли бюджет на разработку и найдётся ли в команде человек, который не падает в обморок от слова «webhook». Главное правило: не надо сразу строить космический корабль, когда достаточно велосипеда. Я видел, как компании тратили месяцы на «правильную» архитектуру, а потом выяснялось, что хватило бы простого решения.

1

Webhooks + простая логика

Платёжная система отправляет уведомление (webhook) при каждой оплате. CRM принимает это уведомление и обновляет статус сделки. Самый простой и распространённый подход.

Как это работает:
  1. Клиент оплачивает через Kaspi QR
  2. Kaspi отправляет webhook на ваш сервер: «Оплата 50,000 тг от +7 777 123 4567»
  3. Ваш сервер ищет сделку по номеру телефона или номеру заказа
  4. Находит → обновляет статус на «Оплачено»
  5. Не находит → создаёт задачу «Разобраться с платежом»

Плюсы: Быстро внедрить, дёшево, понятно

Минусы: Нет гарантии доставки, ручной разбор «непривязанных»

2

Webhooks + очередь сообщений + сверка

Более надёжный подход. Webhooks приходят в очередь (RabbitMQ, Redis Queue), обрабатываются асинхронно. Плюс периодическая сверка с API платёжной системы для «подбора» пропущенных.

Ключевые улучшения:
  • Очередь сообщений: webhook не теряется, даже если CRM временно недоступна
  • Идемпотентность: повторная обработка того же webhook не создаёт дубль
  • Сверка по расписанию: каждый час запрашиваем API и проверяем, не пропустили ли что-то
  • Алерты: если платёж не привязался за N минут — уведомление ответственному

Плюсы: Надёжно, масштабируется, минимум ручной работы

Минусы: Сложнее в разработке, нужна инфраструктура очередей

3

Полноценный платёжный хаб

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

Что даёт платёжный хаб:
  • Единый формат: неважно, Kaspi это или Halyk — для CRM всё выглядит одинаково
  • Бизнес-логика в одном месте: правила сопоставления, частичные оплаты, возвраты
  • Аналитика: сквозная статистика по всем каналам оплаты
  • Гибкость: добавить новый источник = подключить к хабу, CRM трогать не нужно

Плюсы: Максимальная гибкость и масштаб

Минусы: Дорого, долго, требует постоянной поддержки

Как понять, какой уровень вам нужен? Просто посчитайте платежи. До 50 в день — хватит первого уровня, не усложняйте. От 50 до 500 — переходите на второй. Больше 500 или у вас сложная логика с частичными оплатами, рассрочками и возвратами — без третьего уровня будет тяжко. Видел компанию, которая пыталась на 800 платежах в день жить с первым уровнем — в итоге каждую неделю что-то ломалось, а менеджеры просто перестали доверять системе и вернулись к Excel. Зачем тогда вообще внедряли?

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

Главная головная боль: как сопоставить платёж со сделкой

А теперь — к главной боли. Получить webhook от Kaspi или банка — это вообще не проблема, там реально пара строк кода. Настоящая засада начинается дальше: понять, к какой сделке в CRM относится этот конкретный платёж. Казалось бы, что тут сложного? Но на практике — это сплошное минное поле. Клиенты как будто специально придумывают способы усложнить вам жизнь. И сейчас я расскажу почему.

Почему сопоставление — это сложно

Разные телефоны

Классика: клиент оформил заказ со своего номера, а оплатил с Kaspi жены. Или мамы. Или друга. Номера не совпадают — автоматика молчит, платёж «висит».

Неточные суммы

Заказ на 47,500 тг, а клиент перевёл 47,000 — «забыл» про доставку. Или 48,000 — решил округлить. Или вообще 50,000 — «чтобы не мелочиться». Строгий поиск по сумме тут бесполезен.

Одинаковые суммы

А вот обратная ситуация: три разных заказа по 10,000 тг, приходит платёж на 10,000 — и какой из трёх это? Угадайка начинается. Нужны дополнительные критерии.

Частичные оплаты

Заказ на 100,000 тг. Клиент внёс аванс 30,000. Потом ещё 50,000. Потом доплатил 20,000. Три платежа — одна сделка.

Комментарии с ошибками

Вы просили написать «Заказ #12345». Клиент написал «Заказ 12345». Или «зкз12345». Или «за мебель». Или вообще ничего — забыл. Парсинг комментариев — это отдельный вид искусства.

Задержки

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

Как решать проблему сопоставления

Волшебной кнопки, которая решит всё разом, я вам не дам — её просто не существует. Зато есть четыре проверенных приёма, которые вместе дают автоматическое сопоставление для 95% платежей. Оставшиеся 5% придётся разбирать руками — но согласитесь, это уже не три часа в день, а пятнадцать минут. Совсем другая жизнь!

1
Уникальный идентификатор в назначении платежа

Генерируйте короткий код (например, «KZ-7A3B») для каждого заказа. Просите клиента указать его при оплате. Даже если напишет с ошибкой — алгоритм нечёткого поиска найдёт.

2
Каскадный матчинг

Сначала ищем по точному совпадению кода. Не нашли — по телефону + сумме (±5%). Не нашли — по сумме + дате (±3 дня). Не нашли — в очередь на ручной разбор.

3
Ссылка на оплату с «зашитым» ID

Отправляйте клиенту персональную ссылку на оплату, где уже указан номер заказа. Платёжная система вернёт этот ID в callback — 100% точное сопоставление.

4
Интерфейс для ручного разбора

Для тех 5%, что не сопоставились — удобный интерфейс: слева список «висящих» платежей, справа — поиск по сделкам. Клик — привязка. Быстрее, чем копаться в трёх системах.

Давайте без иллюзий: довести автоматизацию до 100% не получится. Всегда найдётся какой-нибудь клиент, который сделает что-то совершенно невообразимое, и придётся разбираться вручную. На прошлой неделе видел платёж с комментарием «за то, помнишь, я звонил» — ну как такое автоматизировать? Но когда вы переходите с 50% на 95% автоматического сопоставления — это небо и земля. Это разница между ежедневным хаосом и спокойной жизнью.

Хотите автоматизировать сверку платежей?

Поможем настроить интеграцию CRM с Kaspi, банковским эквайрингом и маркетплейсами. Автоматическое сопоставление, статусы в реальном времени, аналитика по каналам оплаты.

Обсудить проект

Интеграция с Kaspi: подводные камни и лайфхаки

Раз уж заговорили про конкретику — давайте про Kaspi. Это отдельная песня. С одной стороны, скажу честно, у них один из самых адекватных API в Казахстане (а это, поверьте мне, редкость — я насмотрелся на банковские API, от которых хочется плакать и биться головой об стену). С другой стороны — есть куча нюансов, которых вы не найдёте в официальной документации. Зато узнаете на собственной шкуре, когда всё внезапно сломается. По закону подлости — в пятницу вечером перед длинными выходными.

Что работает хорошо

Kaspi QR webhooks

Вот это реально радует: уведомления прилетают мгновенно, буквально секунды после оплаты. Есть номер телефона плательщика, сумма, время. Для розницы — просто идеально.

Kaspi Магазин API

Тоже молодцы: полный контроль над заказами — статусы, оплаты, отмены. Можно забирать заказы автоматом и сразу создавать сделки в CRM. Если интересно копнуть глубже: интеграция CRM с Kaspi.

На что обратить внимание

Два разных продукта

Вот это важно понять сразу: Kaspi QR (прямые оплаты) и Kaspi Магазин (маркетплейс) — это совершенно разные API, разные кабинеты, разная логика. Не путайте их, иначе будет больно.

Выплаты ≠ оплаты

Ловушка для новичков: в Kaspi Магазин клиент оплатил сегодня, а деньги на ваш счёт придут через 3-14 дней. Не путайте дату оплаты клиентом и дату поступления денег к вам — для бухгалтерии это разные вещи.

Лимиты API

Есть ограничения на количество запросов. При высокой нагрузке можно упереться. Планируйте кэширование и очереди.

Возвраты и споры

Обрабатывайте не только оплаты, но и возвраты. Иначе в CRM сделка будет «оплачена», а деньги уже вернулись клиенту.

Вот вам совет из окопов: если у вас и Kaspi QR, и Kaspi Магазин — делайте две отдельные интеграции. Не пытайтесь впихнуть их в одну систему, сэкономив пару строк кода. Я видел, как один разработчик две недели бился, пытаясь сделать «универсальный обработчик» для обоих API. В итоге получилась монструозная конструкция из if-ов, которую боялись трогать. Потом всё переписали за три дня на две простых интеграции — и жизнь наладилась. Поверьте, две простые интеграции поддерживать в сто раз легче, чем одну «универсальную», которая постоянно падает на граничных условиях.

Банковские переводы: когда API нет или он «особенный»

А теперь давайте поговорим о грустном — о банках. Тут у нас ситуация... как бы помягче выразиться... творческая, что ли. Halyk и Jusan молодцы — предоставляют нормальные API, можно забирать выписки программно, документация есть, техподдержка отвечает. А вот остальные... Некоторые банки дают только выгрузку в Excel, и то раз в сутки. А есть такие, у которых вообще ничего нет, кроме интернет-банка, куда надо руками заходить. Один клиент рассказывал, как их бухгалтер каждое утро логинилась в три разных банка и вручную выгружала три Excel-файла. Каждый день. Пять лет подряд. Представляете?

Как с этим жить? Вот несколько вариантов разной степени боли. Выбирайте, что вам ближе — или что технически возможно с вашим банком.

Если есть API

Настраиваете polling (запрос новых транзакций каждые 5-15 минут) или webhook (если банк поддерживает). Данные приходят структурированные: сумма, отправитель, назначение платежа, время.

Банки с API: Halyk (Open Banking), Jusan, Kaspi (для бизнес-счетов)

Если только выгрузка

Автоматизируете загрузку файла выписки (Excel/CSV) в CRM. Можно вручную раз в день, можно через RPA-робота, если банк позволяет автоматизировать экспорт.

Минус: задержка минимум сутки, ручной этап

Через 1С / бухгалтерию

Если у вас уже настроена выгрузка банковской выписки в 1С — берите данные оттуда. CRM интегрируется с 1С, а не напрямую с банком. Один источник правды.

Плюс: данные уже «почищены» бухгалтерией

Уведомления на почту

Крайний случай: парсинг email-уведомлений о поступлениях. Настраиваете фильтр, извлекаете сумму и реквизиты из текста письма. Костыль, но работает.

Минус: хрупко, зависит от формата писем банка

Если у вас реально много корпоративных платежей — подумайте о смене банка на тот, у кого есть адекватный API. Да, перенос расчётного счёта — это гемор, никто не спорит. Придётся уведомлять контрагентов, менять реквизиты в документах, переоформлять всякие автоплатежи. Но один раз помучаетесь, зато потом годами будете жить спокойно. Это лучше, чем каждый день проклинать жизнь, сверяя Excel-файлы, и срываться на бухгалтере, который тут вообще ни при чём. Знаю компанию, которая сменила банк именно из-за отсутствия API — и говорят, что лучшее решение за последние три года.

Статусы оплаты: что должна знать CRM

Кстати, раз уж мы говорим про CRM — давайте про статусы. Если у вас только два варианта — «Оплачено» и «Не оплачено» — это слишком грубо для реальной жизни. Представьте: клиент внёс аванс 30% из 100 тысяч, а система показывает либо «оплачено», либо «не оплачено». И что делать менеджеру? Отгружать или нет? Он звонит клиенту уточнять, клиент раздражается. А всё из-за того, что система не может сказать простую вещь: «оплачено 30 из 100, осталось 70».

Жизненный цикл платежа в CRM

Начало Ожидает оплаты
Частично Аванс получен
Полностью Оплачено
Финал Сверено

Возврат: из «Оплачено» можно перейти в «Частичный возврат» или «Полный возврат»

Отмена: из «Ожидает оплаты» — в «Отменено» (клиент передумал)

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

Минимальный набор полей для каждого платежа:

Поле Пример Зачем нужно
payment_id PAY-2025-001234 Уникальный идентификатор в CRM
external_id kaspi_txn_789xyz ID транзакции в платёжной системе
source kaspi_qr / halyk_api / manual Откуда пришёл платёж
amount 50000.00 Сумма платежа
currency KZT Валюта (для мультивалютных операций)
status completed / pending / refunded Текущий статус
deal_id 12345 Связь со сделкой в CRM
payer_phone +7 777 123 4567 Телефон плательщика (если есть)
payment_date 2025-01-15 14:32:00 Дата и время платежа
matched_at 2025-01-15 14:32:15 Когда привязали к сделке (для аналитики)

Обратите внимание на external_id — это ID транзакции в самой платёжной системе (Kaspi, банк и т.д.). Обязательно храните его! Это ваша страховка от дублей и единственная зацепка, когда клиент через полгода начнёт спорить, что платил не ту сумму или вообще не платил. Был случай: клиент утверждал, что оплатил 50 тысяч, а мы видим только 30. Благодаря external_id за две минуты нашли его платёж в системе Kaspi, показали скриншот — действительно 30 тысяч. Без этого ID спорили бы до посинения.

Шесть ошибок, которые убивают интеграцию платежей

Знаете, что самое обидное? За годы работы с интеграциями я видел одни и те же грабли раз по двадцать. И каждый раз думаю: «Ну вот, опять!». Поэтому держите топ-6 ошибок, на которые наступают почти все. Если вы только планируете внедрение — считайте, что я сэкономил вам пару недель отладки и кучу нервов. А может, и месяц — если вы из тех, кто любит учиться исключительно на собственных ошибках.

1
Нет идемпотентности

Ситуация: платёжная система отправила webhook дважды (да, такое бывает чаще, чем хотелось бы). Вы обработали оба — и записали платёж два раза. В системе клиент «переплатил», хотя реально заплатил один раз. Весело, правда? Как защититься: идемпотентность и ретраи в webhooks.

2
Игнорирование возвратов

О, это классика! Интегрировали приход денег, а про возвраты «забыли». Клиент получил refund, а в CRM сделка всё ещё «оплачена». Менеджер, ничего не подозревая, отгружает товар. Сюрприз обнаруживается потом. Обычно неприятный.

3
Нет fallback-сверки

Полагаетесь только на webhooks и думаете, что они всегда доходят? Наивно! Webhook потерялся (сеть моргнула, баг, сервер перезагрузился) — платёж не попал в CRM. Без периодической сверки с API источника вы этого даже не узнаете. До звонка разъярённого клиента.

4
Жёсткий матчинг

Ищете сделку только по точному совпадению суммы. Клиент округлил на 100 тенге — платёж «потерялся». Нужен fuzzy matching с допуском и каскадный поиск по нескольким критериям.

5
Нет логирования

Что-то пошло не так, но что именно — непонятно. Логи не пишутся или пишутся без деталей. При разборе инцидента — только догадки и ручной поиск по трём системам.

6
Нет алертов

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

Кейс: как интернет-магазин сократил сверку с 3 часов до 15 минут

Ладно, хватит пугать — давайте про хорошее. Помните Марата из Караганды, с которого мы начинали? Того, который каждый понедельник тратил три часа на сверку платежей? Через полтора месяца после внедрения интеграции я созвонился с ним узнать, как дела. Первое, что он сказал: «Слушай, я теперь в понедельник утром прихожу на работу и не хочу сразу уволиться». Неплохой результат, да? Вот что конкретно изменилось.

Было

  • 3+ часа ежедневно на ручную сверку
  • 5 вкладок браузера: Kaspi, банк, маркетплейс, CRM, Excel
  • Ошибки: 2-3 «потерянных» платежа в неделю
  • Задержки отгрузки на 1-2 дня после оплаты
  • Конфликты с клиентами: «Я уже оплатил!»
  • Аналитика по каналам оплаты — отсутствует

Стало

  • 15 минут в день на разбор исключений (5% платежей)
  • Одно окно: все платежи видны в CRM
  • 95% платежей сопоставляются автоматически
  • Отгрузка в тот же день при оплате до 14:00
  • Менеджер видит статус оплаты в момент звонка
  • Дашборд: конверсия по каналам, средний чек, динамика

Что мы сделали:

  1. Прикрутили Kaspi QR через webhook — теперь уведомление об оплате прилетает мгновенно
  2. Подключили API Kaspi Магазина — заказы автоматом сыплются в CRM
  3. С банковскими переводами договорились через Halyk API — выгрузка каждый час
  4. Настроили каскадный поиск: сначала по коду заказа, не нашли — по телефону и сумме, не нашли — в очередь на ручной разбор
  5. Сделали простой интерфейс, где можно за пару кликов привязать «висячие» платежи
  6. Добавили дашборд с метриками и настроили алерты на косяки

Внедрение заняло три недели. Окупилось за первый же месяц — только на времени, которое бухгалтер перестал тратить на сверку. Марат говорит, что это лучшее вложение в бизнес за последние три года. А ещё у него теперь есть дашборд с аналитикой, и он впервые за всё время точно знает, сколько денег придёт сегодня и откуда. Раньше это была гадалка на кофейной гуще.

Чек-лист: как внедрить интеграцию платежей

Окей, мы уже много поговорили — теперь к практике. Если решились внедрять — вот вам пошаговый план действий. Проверено на практике, работает. И честно скажу: если чётко следовать этому плану, вы избежите 90% типичных косяков. А это, поверьте, дорогого стоит.

Пошаговый план внедрения

Шаг 1
Инвентаризация источников

Составьте список: откуда приходят деньги? Kaspi, банк, маркетплейсы, наличные? Какой объём по каждому каналу?

Шаг 2
Аудит API и возможностей

Что можно получать автоматически? Webhooks, API, выгрузка файлов? Какие лимиты и ограничения?

Шаг 3
Проектирование логики сопоставления

По каким полям связывать платёж со сделкой? Какие допуски? Что делать с «непривязанными»?

Шаг 4
MVP с одним источником

Начните с самого массового канала (обычно Kaspi). Отладьте, проверьте на реальных данных.

Шаг 5
Добавьте остальные источники

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

Шаг 6
Настройте мониторинг и алерты

Дашборд с метриками, уведомления об ошибках, алерт если нет платежей слишком долго.

Шаг 7
Обучите команду

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

Заключение: деньги должны быть видны

Давайте подведём итог. Интеграция платежей — это не техническая прихоть айтишников и уж точно не «было бы неплохо когда-нибудь». Это основа вменяемой работы. Когда менеджер видит статус оплаты прямо в карточке клиента — он не лезет в Kaspi, не дёргает бухгалтера, а просто смотрит и знает. Склад получает сигнал на отгрузку автоматически — никаких «а мне не сказали». Бухгалтер тратит на сверку 15 минут вместо трёх часов. И вот тогда бизнес может спокойно расти, а не тушить пожары каждый божий день.

Да, первая настройка — это возня. Да, всегда будут какие-то исключения и странные случаи, которые придётся разруливать вручную (помните того клиента с комментарием «за то, помнишь, я звонил»?). Но когда вы переходите с режима «всё руками» на «95% автоматом» — это небо и земля. Это разница между ежедневным хаосом и спокойной жизнью. Между упором в потолок и возможностью масштабироваться.

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

Готовы автоматизировать платежи?

Поможем настроить интеграцию CRM с Kaspi, банками и маркетплейсами. От аудита до запуска — полный цикл. Автоматическое сопоставление, статусы в реальном времени, аналитика.

Обсудить проект

Часто задаваемые вопросы

Зависит от того, сколько источников подключаете и насколько сложная у вас логика. Один только Kaspi QR можно прикрутить за неделю-две — это самый простой вариант, с которого я всегда рекомендую начинать. А если нужно Kaspi + банк + маркетплейс + хитрый каскадный матчинг — готовьтесь к месяцу-двум работы. Совет из личного опыта: начните с одного самого массового источника, отладьте его до блеска, а потом уже добавляйте остальные. Так меньше шансов утонуть в багах и не понять, где именно что-то сломалось.

Это совершенно нормально — такие исключения будут всегда, обычно процентов 5-10 от общего объёма. Люди непредсказуемы, и всегда найдётся кто-то, кто напишет «за вчерашнее» вместо номера заказа. Главное, чтобы был удобный интерфейс для ручной привязки: слева список «висячих» платежей, справа поиск по сделкам, клик — и готово. Пять минут работы вместо того, чтобы лазить по трём разным системам и гадать, где же этот чёртов платёж. Поверьте, даже эти 5% ручной работы — это в разы лучше, чем 100% ручной сверки.

В CRM у сделки должно быть поле «Сумма оплачено», а не просто галочка «оплачено/не оплачено». Каждый новый платёж добавляется к этой сумме, и статус движется по цепочке: «Ожидает оплаты» → «Частично оплачено» → «Полностью оплачено». И обязательно храните историю всех платежей, а не только итоговую цифру — иначе через месяц придёте и не поймёте, откуда что взялось. Был случай: клиент платил по частям четыре раза, а в системе только итоговая сумма. Когда начали разбираться с возвратом — никто не мог вспомнить, как именно он платил.

Да, можно, только у каждого банка будет свой API (а может и вообще не быть API, и тогда привет Excel-файлы). Самый правильный путь — сделать отдельный адаптер для каждого банка, который нормализует данные в единый формат. Тогда CRM просто получает стандартизированный поток платежей, не вникая в то, от Halyk это или от Jusan. Меньше головной боли при поддержке. У одного клиента было три банка с тремя разными форматами — сделали три адаптера, CRM получает один стандартный формат. Работает как часы.

Наличка идёт через онлайн-кассу (ККМ). Если касса умеет интегрироваться с CRM — чек автоматом привязывается к сделке, красота. Если нет — менеджер вручную ставит галочку «оплачено» в момент пробития чека. Да, это не идеально, но наличные вообще сложно автоматизировать до конца — это та самая «последняя миля», где без человека пока не обойтись. Честно говоря, в эпоху Kaspi доля наличных постоянно падает, так что эта проблема со временем сама уходит.

Читайте также

iPaaS vs ESB vs кастом: выбор архитектуры интеграций

Критерии, риски и стоимость разных подходов к интеграции систем

Интеграция CRM с Kaspi: заявки, оплаты, статусы

Подробное руководство по подключению Kaspi к CRM

Идемпотентность и ретраи в webhooks

Как сделать синхронизацию устойчивой к сбоям

Синхронизация товаров и цен: 1С ↔ CRM

Паттерны интеграции без «разъезда» справочников

Единый case management: CRM + helpdesk + омниканал

Как объединить все обращения клиентов в одной системе

Revenue leakage: где теряется выручка

Диагностика и алерты для процессов продаж и биллинга