Понедельник, 9 утра. Марат из Караганды открывает ноутбук и начинает ежедневный ритуал, от которого хочется выть: сверка платежей. В одном окне — личный кабинет Kaspi, где за выходные прошло 47 оплат. В другом — выписка из Halyk Bank с тремя корпоративными переводами. В третьем — админка маркетплейса с шестью заказами. В четвёртом — CRM, где нужно вручную отметить, какие сделки оплачены.
«Каждый понедельник я трачу два часа на то, чтобы найти, кто заплатил, и проставить галочки в CRM, — вздыхает Марат. — А потом ещё час разбираюсь с расхождениями. Вот эта оплата — к какой сделке? А эта частичная оплата — это аванс или доплата? Иногда хочется всё бросить и вернуться к тетрадке».
Знакомо? Если у вас больше десяти продаж в день и несколько каналов оплаты — вы точно сталкивались с этим хаосом. Деньги приходят из разных источников, каждый со своим форматом, своими статусами, своей логикой. А CRM живёт своей жизнью и понятия не имеет, что клиент уже заплатил.
Сегодня разберём, как это исправить. Не в теории, а на практике — с учётом реалий казахстанского рынка, где Kaspi QR стал почти национальной валютой, а банковские API до сих пор работают через боль и страдания.
«Интеграция платежей — это не про технологии. Это про то, чтобы менеджер видел статус оплаты в момент звонка клиенту, а не лез в три разных системы. Одна секунда вместо пяти минут — вот реальная ценность»
Принцип «деньги видны сразу»
Revenue Operations
Почему ручная сверка платежей убивает бизнес (медленно, но верно)
Прежде чем лезть в технические детали, давайте честно поговорим о том, во что обходится «ручной режим». Многие владельцы бизнеса машут рукой: «Ну подумаешь, бухгалтер потратит пару часов на сверку. Это же её работа».
Проблема в том, что последствия выходят далеко за пределы бухгалтерии.
Скрытые потери от ручной сверки платежей
Время = деньги (буквально)
При 100 платежах в день и 3 минутах на сверку каждого — это 5 часов ежедневно. 100+ часов в месяц. Зарплата целого сотрудника, который мог бы делать что-то полезное.
Ошибки и «потерянные» платежи
Человек устаёт. К пятничному вечеру внимательность падает. Платёж не привязался к сделке — менеджер думает, что клиент не заплатил, и звонит с напоминанием. Клиент в бешенстве.
Задержки в отгрузке
Клиент оплатил в субботу. Бухгалтер увидела в понедельник. Склад получил информацию во вторник. Клиент ждёт товар уже три дня и нервничает. А мог бы получить в понедельник.
Кривая аналитика
Сколько денег пришло сегодня? Какой канал оплаты самый популярный? Какая конверсия из счёта в оплату? Без автоматической интеграции — только гадание на кофейной гуще.
Выгорание команды
Никто не мечтал в детстве вручную сверять платежи. Это рутина, которая демотивирует. Хорошие сотрудники уходят туда, где автоматизация уже работает.
Потолок масштабирования
При 100 платежах — терпимо. При 500 — нужен отдельный человек. При 1000 — целый отдел. Ручная сверка не масштабируется, а наём людей дорожает каждый год.
Знаю компании, которые годами живут в режиме ручной сверки, потому что «ну как-то работает». Работает — пока не рванёт. Пока не потеряется крупный платёж, пока клиент не уйдёт к конкуренту, пока бухгалтер не уволится в самый неподходящий момент.
Автоматическая интеграция платежей — это не «было бы неплохо». Это гигиенический минимум для бизнеса, который хочет расти.
Карта платёжных источников в Казахстане: откуда приходят деньги
Прежде чем строить интеграцию, нужно понять ландшафт. В Казахстане сложилась уникальная экосистема платежей, которая отличается от российской и тем более от западной. Вот основные источники, с которыми приходится работать.
Kaspi QR / Kaspi Pay
Доминирует в рознице. Мгновенные уведомления, удобный API. Для B2C — практически стандарт.
API: ХорошийБанковский эквайринг
Карточные платежи через терминалы и онлайн. Halyk, Jusan, Forte — у каждого свои особенности интеграции.
API: СреднийБанковские переводы
Корпоративные платежи, B2B-сделки. Приходят на расчётный счёт, видны в выписке. Автоматизация сложнее.
API: РазныйKaspi Магазин
Заказы с маркетплейса. Оплата через Kaspi, но со своей логикой статусов и выплат продавцу.
API: ХорошийДругие маркетплейсы
Wildberries, Ozon (где работают). Своя система статусов, свои сроки выплат, свои API.
API: РазныйНаличные / Касса
Всё ещё актуально, особенно в регионах. Требует интеграции с онлайн-кассой (ККМ) и передачи чеков в ОФД.
API: Через ККМТипичная казахстанская компания работает минимум с тремя источниками: Kaspi для розницы, банковские переводы для корпоративных клиентов и, возможно, маркетплейс. У каждого — свой формат данных, своя логика статусов, свои задержки.
Это не баг, это реальность. И с ней нужно уметь работать.
Архитектура интеграции: три уровня сложности
А теперь к мясу — как технически связать платёжные источники с CRM. Есть несколько подходов, от простенького до навороченного. Что выбрать — зависит от объёмов, бюджета и наличия в команде человека, который не боится слова «webhook».
Webhooks + простая логика
Платёжная система отправляет уведомление (webhook) при каждой оплате. CRM принимает это уведомление и обновляет статус сделки. Самый простой и распространённый подход.
Как это работает:
- Клиент оплачивает через Kaspi QR
- Kaspi отправляет webhook на ваш сервер: «Оплата 50,000 тг от +7 777 123 4567»
- Ваш сервер ищет сделку по номеру телефона или номеру заказа
- Находит → обновляет статус на «Оплачено»
- Не находит → создаёт задачу «Разобраться с платежом»
Плюсы: Быстро внедрить, дёшево, понятно
Минусы: Нет гарантии доставки, ручной разбор «непривязанных»
Webhooks + очередь сообщений + сверка
Более надёжный подход. Webhooks приходят в очередь (RabbitMQ, Redis Queue), обрабатываются асинхронно. Плюс периодическая сверка с API платёжной системы для «подбора» пропущенных.
Ключевые улучшения:
- Очередь сообщений: webhook не теряется, даже если CRM временно недоступна
- Идемпотентность: повторная обработка того же webhook не создаёт дубль
- Сверка по расписанию: каждый час запрашиваем API и проверяем, не пропустили ли что-то
- Алерты: если платёж не привязался за N минут — уведомление ответственному
Плюсы: Надёжно, масштабируется, минимум ручной работы
Минусы: Сложнее в разработке, нужна инфраструктура очередей
Полноценный платёжный хаб
Отдельный сервис, который агрегирует все платёжные источники, нормализует данные в единый формат и предоставляет унифицированный API для CRM и других систем. Подход для серьёзных объёмов.
Что даёт платёжный хаб:
- Единый формат: неважно, Kaspi это или Halyk — для CRM всё выглядит одинаково
- Бизнес-логика в одном месте: правила сопоставления, частичные оплаты, возвраты
- Аналитика: сквозная статистика по всем каналам оплаты
- Гибкость: добавить новый источник = подключить к хабу, CRM трогать не нужно
Плюсы: Максимальная гибкость и масштаб
Минусы: Дорого, долго, требует постоянной поддержки
Какой подход выбрать? Зависит от масштаба. До 50 платежей в день — первый уровень. 50-500 — второй. Больше 500 или сложная логика (частичные оплаты, рассрочки, возвраты) — третий.
Подробнее об архитектуре интеграций и выборе между разными подходами читайте в нашем руководстве по iPaaS vs ESB vs кастом.
Главная головная боль: как сопоставить платёж со сделкой
Технически получить webhook — дело несложное. Настоящая головная боль — понять, к какой именно сделке относится этот платёж. Вроде бы задача очевидная. А на практике — минное поле.
Почему сопоставление — это сложно
Разные телефоны
Клиент оформил заказ с одного номера, а оплатил с Kaspi другого члена семьи. Номера не совпадают, автоматика не срабатывает.
Неточные суммы
Заказ на 47,500 тг, а клиент перевёл 47,000 — забыл про доставку. Или 48,000 — округлил. Строгое сопоставление по сумме не работает.
Одинаковые суммы
Три заказа по 10,000 тг, приходит платёж на 10,000 — какой из трёх? Нужны дополнительные критерии.
Частичные оплаты
Заказ на 100,000 тг. Клиент внёс аванс 30,000. Потом ещё 50,000. Потом доплатил 20,000. Три платежа — одна сделка.
Комментарии с ошибками
Просили написать «Заказ #12345». Клиент написал «Заказ 12345» или «зкз12345» или вообще «за мебель». Парсинг — боль.
Задержки
Клиент заказал сегодня, а оплатил через неделю. Сделка уже в архиве или у другого менеджера.
Как решать проблему сопоставления
Серебряной пули нет, но есть набор приёмов, которые в сумме дают 95%+ автоматического сопоставления.
Уникальный идентификатор в назначении платежа
Генерируйте короткий код (например, «KZ-7A3B») для каждого заказа. Просите клиента указать его при оплате. Даже если напишет с ошибкой — алгоритм нечёткого поиска найдёт.
Каскадный матчинг
Сначала ищем по точному совпадению кода. Не нашли — по телефону + сумме (±5%). Не нашли — по сумме + дате (±3 дня). Не нашли — в очередь на ручной разбор.
Ссылка на оплату с «зашитым» ID
Отправляйте клиенту персональную ссылку на оплату, где уже указан номер заказа. Платёжная система вернёт этот ID в callback — 100% точное сопоставление.
Интерфейс для ручного разбора
Для тех 5%, что не сопоставились — удобный интерфейс: слева список «висящих» платежей, справа — поиск по сделкам. Клик — привязка. Быстрее, чем копаться в трёх системах.
Давайте честно: 100% автоматизация — это сказка. Всегда найдётся клиент, который сделает что-то неожиданное. Но разница между 50% и 95% автоматического сопоставления — это разница между хаосом и нормальной работой.
Хотите автоматизировать сверку платежей?
Поможем настроить интеграцию CRM с Kaspi, банковским эквайрингом и маркетплейсами. Автоматическое сопоставление, статусы в реальном времени, аналитика по каналам оплаты.
Обсудить проектИнтеграция с Kaspi: подводные камни и лайфхаки
Kaspi — отдельная история. С одной стороны, у них один из лучших API в Казахстане. С другой — есть нюансы, о которых не пишут в документации.
Что работает хорошо
Kaspi QR webhooks
Уведомления приходят мгновенно (секунды после оплаты). Есть номер телефона плательщика, сумма, время. Для розницы — идеально.
Kaspi Магазин API
Полный контроль над заказами: статусы, оплаты, отмены. Можно забирать заказы автоматически и сразу создавать сделки в CRM. Подробнее: интеграция CRM с Kaspi.
На что обратить внимание
Два разных продукта
Kaspi QR (прямые оплаты) и Kaspi Магазин (маркетплейс) — это разные API, разные личные кабинеты, разная логика. Не путайте.
Выплаты ≠ оплаты
В Kaspi Магазин клиент оплатил сегодня, но деньги на ваш счёт придут через 3-14 дней (зависит от условий). Это важно для учёта.
Лимиты API
Есть ограничения на количество запросов. При высокой нагрузке можно упереться. Планируйте кэширование и очереди.
Возвраты и споры
Обрабатывайте не только оплаты, но и возвраты. Иначе в CRM сделка будет «оплачена», а деньги уже вернулись клиенту.
Практический совет: если работаете и с Kaspi QR, и с Kaspi Магазин — это два отдельных потока интеграции. Не пытайтесь объединить их в один. Проще поддерживать две простые интеграции, чем одну сложную.
Банковские переводы: когда API нет или он «особенный»
С банками в Казахстане ситуация... творческая. Некоторые (Halyk, Jusan) предоставляют нормальные API для получения выписок. Другие — только выгрузку в Excel раз в сутки. Третьи — вообще ничего, кроме интернет-банка.
Как жить в этой реальности?
Если есть API
Настраиваете polling (запрос новых транзакций каждые 5-15 минут) или webhook (если банк поддерживает). Данные приходят структурированные: сумма, отправитель, назначение платежа, время.
Банки с API: Halyk (Open Banking), Jusan, Kaspi (для бизнес-счетов)
Если только выгрузка
Автоматизируете загрузку файла выписки (Excel/CSV) в CRM. Можно вручную раз в день, можно через RPA-робота, если банк позволяет автоматизировать экспорт.
Минус: задержка минимум сутки, ручной этап
Через 1С / бухгалтерию
Если у вас уже настроена выгрузка банковской выписки в 1С — берите данные оттуда. CRM интегрируется с 1С, а не напрямую с банком. Один источник правды.
Плюс: данные уже «почищены» бухгалтерией
Уведомления на почту
Крайний случай: парсинг email-уведомлений о поступлениях. Настраиваете фильтр, извлекаете сумму и реквизиты из текста письма. Костыль, но работает.
Минус: хрупко, зависит от формата писем банка
Мой совет: если корпоративных платежей много — выбирайте банк с нормальным API. Да, придётся повозиться с переходом. Но это лучше, чем годами мучиться с ручной сверкой и ругаться на бухгалтера.
Статусы оплаты: что должна знать CRM
«Оплачено / Не оплачено» — слишком грубо. В реальности жизненный цикл платежа сложнее, и CRM должна это отражать.
Жизненный цикл платежа в 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 из платёжной системы. Это ваша защита от дублей и возможность отследить платёж «до источника» при разборе спорных ситуаций.
Шесть ошибок, которые убивают интеграцию платежей
За годы работы насмотрелся на одни и те же грабли. Вот на что наступают чаще всего.
Нет идемпотентности
Платёжная система отправила webhook дважды (такое бывает). Вы обработали оба — и записали платёж два раза. Клиент «переплатил» в системе, хотя реально заплатил один раз. Подробнее о защите: идемпотентность и ретраи в webhooks.
Игнорирование возвратов
Интегрировали только приход денег, про возвраты забыли. Клиент получил refund, а в CRM сделка всё ещё «оплачена». Менеджер отгрузил товар, которого не должен был отгружать.
Нет fallback-сверки
Полагаетесь только на webhooks. Webhook потерялся (сеть, баг, перезагрузка сервера) — платёж не попал в CRM. Без периодической сверки с API источника вы этого даже не узнаете.
Жёсткий матчинг
Ищете сделку только по точному совпадению суммы. Клиент округлил на 100 тенге — платёж «потерялся». Нужен fuzzy matching с допуском и каскадный поиск по нескольким критериям.
Нет логирования
Что-то пошло не так, но что именно — непонятно. Логи не пишутся или пишутся без деталей. При разборе инцидента — только догадки и ручной поиск по трём системам.
Нет алертов
Интеграция сломалась в пятницу вечером. Все выходные платежи не попадали в CRM. Узнали в понедельник, когда клиенты начали звонить. Настройте мониторинг: если за час не было ни одного платежа — что-то не так.
Кейс: как интернет-магазин сократил сверку с 3 часов до 15 минут
Вернёмся к Марату из начала статьи. Вот что изменилось после внедрения автоматической интеграции.
Было
- 3+ часа ежедневно на ручную сверку
- 5 вкладок браузера: Kaspi, банк, маркетплейс, CRM, Excel
- Ошибки: 2-3 «потерянных» платежа в неделю
- Задержки отгрузки на 1-2 дня после оплаты
- Конфликты с клиентами: «Я уже оплатил!»
- Аналитика по каналам оплаты — отсутствует
Стало
- 15 минут в день на разбор исключений (5% платежей)
- Одно окно: все платежи видны в CRM
- 95% платежей сопоставляются автоматически
- Отгрузка в тот же день при оплате до 14:00
- Менеджер видит статус оплаты в момент звонка
- Дашборд: конверсия по каналам, средний чек, динамика
Что сделали:
- Подключили Kaspi QR через webhook — моментальные уведомления об оплате
- Настроили API-интеграцию с Kaspi Магазин — заказы падают в CRM автоматически
- Для банковских переводов — ежечасная выгрузка через API Halyk
- Каскадный матчинг: по коду заказа → по телефону + сумме → в очередь на ручной разбор
- Интерфейс для быстрой привязки «висящих» платежей
- Дашборд с ключевыми метриками и алертами
Внедрение заняло три недели. Окупилось за первый месяц — только на экономии времени бухгалтера.
Чек-лист: как внедрить интеграцию платежей
Резюмирую в формате пошагового плана.
Пошаговый план внедрения
Инвентаризация источников
Составьте список: откуда приходят деньги? Kaspi, банк, маркетплейсы, наличные? Какой объём по каждому каналу?
Аудит API и возможностей
Что можно получать автоматически? Webhooks, API, выгрузка файлов? Какие лимиты и ограничения?
Проектирование логики сопоставления
По каким полям связывать платёж со сделкой? Какие допуски? Что делать с «непривязанными»?
MVP с одним источником
Начните с самого массового канала (обычно Kaspi). Отладьте, проверьте на реальных данных.
Добавьте остальные источники
Поочерёдно подключайте другие каналы: банк, маркетплейсы. Используйте ту же логику сопоставления.
Настройте мониторинг и алерты
Дашборд с метриками, уведомления об ошибках, алерт если нет платежей слишком долго.
Обучите команду
Менеджеры должны знать, где смотреть статус оплаты. Бухгалтерия — как работать с исключениями.
Заключение: деньги должны быть видны
Интеграция платежей с CRM — это не какое-то техническое упражнение для айтишников. Это основа нормальной работы. Когда менеджер видит статус оплаты прямо в момент разговора с клиентом, когда склад получает сигнал на отгрузку автоматом, когда бухгалтер тратит на сверку минуты вместо часов — вот тогда бизнес может думать о росте, а не о тушении пожаров.
Да, первая настройка — это возня. Да, будут исключения и странные случаи. Но разница между «всё вручную» и «95% на автомате» — это разница между хаосом и порядком. Между вечным стрессом и нормальной работой. Между потолком и возможностью расти.
Постройте интеграцию один раз — и она будет работать на вас годами. А время, которое освободится, потратьте на то, что действительно важно: на клиентов, на продукт, на развитие.
Готовы автоматизировать платежи?
Поможем настроить интеграцию CRM с Kaspi, банками и маркетплейсами. От аудита до запуска — полный цикл. Автоматическое сопоставление, статусы в реальном времени, аналитика.
Обсудить проектЧасто задаваемые вопросы
Читайте также
iPaaS vs ESB vs кастом: выбор архитектуры интеграций
Критерии, риски и стоимость разных подходов к интеграции систем
Интеграция CRM с Kaspi: заявки, оплаты, статусы
Подробное руководство по подключению Kaspi к CRM
Идемпотентность и ретраи в webhooks
Как сделать синхронизацию устойчивой к сбоям
Синхронизация товаров и цен: 1С ↔ CRM
Паттерны интеграции без «разъезда» справочников
Единый case management: CRM + helpdesk + омниканал
Как объединить все обращения клиентов в одной системе
Revenue leakage: где теряется выручка
Диагностика и алерты для процессов продаж и биллинга