Переход с эквайринга Сбербанка на ЮKassa: интеграция по API

Когда банк меняет платёжный сервис, у интернет-магазина нет выбора: либо интеграция готова к дате отключения старого эквайринга, либо сайт перестаёт принимать деньги. Мы подключили ЮKassa собственной интеграцией по API и уложились на 10% раньше срока.

Ситуация

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

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

Задача

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

Как решали

Сбор требований и доступы

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

Собственная интеграция вместо модуля

В 1С-Битрикс есть встроенный модуль для работы с ЮKassa, и для базового сценария его достаточно. Мы выбрали другой путь. Написали собственную интеграцию по API.

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

Тестовый контур

Интеграцию собрали и прогнали в тестовой среде ЮKassa, затем показали заказчику и получили обратную связь. На этом этапе всплыли сценарии, которые заказчик изначально не учёл, — именно для этого тестовый контур и нужен.

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

Боевой запуск

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

Поддержка после запуска

Хорошо сделанная платёжная интеграция не требует постоянного обслуживания — она работает. Но полностью исключить сбои нельзя: проблема может возникнуть и на стороне магазина, и на стороне сервиса, и на стороне банка.

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

Результат

Переход завершён на 10% быстрее поставленного срока. Заказчик получил рабочий приём оплаты через ЮKassa и продолжил работу без сбоев. Покупатели не заметили смены эквайринга.

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

Показатели: до и после

Метрики из проекта — «до» и «после», с источником замера. Данные те же, что в кейсе ниже.

Что не сработало

• Готовый модуль покрывал только базовый сценарий. То, что в него не заложено, пришлось бы обходить костылями — написали свою интеграцию по API.
• Тестовый контур выявил непредусмотренные сценарии. Часть случаев заказчик изначально не учёл; их нашли и закрыли до боевого запуска, а не после первых оплат.
• Дедлайн задавал банк, а не заказчик. После отключения старого приёма оплаты заказы перестали бы оплачиваться: работа шла в жёсткие сроки, и выиграла точность требований на старте, а не скорость кода.

Что забрали в другие проекты

• Тестовый контур — обязателен. На нём находятся сценарии, о которых заказчик не подумал.
• Своя интеграция окупается на поддержке. Когда платёж не проходит, вы точно знаете, где искать.
• Требования важнее кода. При внешнем дедлайне выигрывает тот, кто быстрее и точнее собрал вводные.

Частые вопросы

Что делать, если банк переводит интернет-магазин на ЮKassa?

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

Нужен ли готовый модуль ЮKassa для 1С-Битрикс?

Для базового приёма оплаты модуля достаточно. Если у магазина есть свои сценарии — частичные возвраты, повторные попытки, нестандартная логика статусов, — собственная интеграция по API оказывается надёжнее и проще в поддержке.

Что происходит с оплатами в момент перехода?

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

Проект выполнен по услугам «Программирование и доработка сайтов» и «SEO на 1С-Битрикс». Если у вас похожий дедлайн — напишите нам.