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

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

Ситуация

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

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

Задача

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

Как решали

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

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

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

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

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

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

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

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

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

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

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

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

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

Результат

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

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

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

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

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

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

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

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

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

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

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

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