QIWI: подключение

QIWI долго был популярным способом приёма платежей, но его текущий статус кардинально изменил картину. Прежде чем настраивать QIWI на 1С-Битрикс, важно понимать, что приём через КИВИ фактически недоступен, поэтому эта статья и об архитектуре прежней интеграции, и о том, на что корректно перевести оплату.

Актуальный статус QIWI

Если на вашем сайте на Битриксе исторически был подключён обработчик QIWI, его стоит проверить и, скорее всего, отключить, а поток оплат перевести на другой сервис. Ниже — как это было устроено технически (чтобы аккуратно демонтировать) и чем заменить.

• Проверьте, не показывается ли покупателям неработающий способ оплаты QIWI;
• Отключите обработчик в Магазин → Платёжные системы, чтобы не терять заказы на шаге оплаты;
• Настройте один из актуальных способов приёма (см. раздел об альтернативах).

Как была устроена интеграция

Исторически QIWI предлагал несколько продуктов для магазинов: приём на кошелёк, выставление счетов и p2p-платежи через публичное API. Для 1С-Битрикс использовался платёжный обработчик, который работал по токену.

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

Счета и форма оплаты (как это было)

Приём через выставление счёта строился на публичном API. Магазин формировал счёт с уникальным идентификатором и суммой, а покупатель оплачивал его на стороне QIWI.

1. Сгенерировать уникальный bill_id, привязанный к заказу Битрикса;
2. Создать счёт запросом с токеном (сумма, срок действия, комментарий с номером заказа);
3. Получить ссылку на оплату payUrl и отправить покупателя туда;
4. Дождаться уведомления о статусе PAID.

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

Вебхуки и смена статуса (как это было)

Смена статуса заказа выполнялась по вебхуку QIWI с проверкой подписи. Обработчик в Битриксе сверял подлинность, сумму и только затем проставлял оплату.

• Принять уведомление о смене статуса счёта;
• Проверить подпись по секрету вебхука (HMAC);
• Сверить сумму и bill_id с заказом;
• Проставить оплату методом Payment::setPaid('Y') и вернуть корректный ответ.

Чем заменить приём оплаты

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

Для самозанятых и небольших продаж как временный вариант подойдёт кошелёк ЮMoney, но под 54-ФЗ и рост оборота правильнее полноценный эквайринг или агрегатор.

Порядок миграции на Битриксе

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

1. Подключаем и тестируем новый платёжный обработчик на тестовом контуре;
2. Проверяем фискализацию: чек по 54-ФЗ формируется и уходит в ОФД;
3. Настраиваем вебхуки/callback нового сервиса и смену статусов;
4. Переключаем способ оплаты на боевом, отключаем обработчик QIWI;
5. Следим за первыми боевыми заказами и логами уведомлений.

Итог

Планировать новую интеграцию QIWI с 1С-Битрикс сегодня не имеет смысла: после отзыва лицензии у КИВИ Банка приём через сервис для магазинов фактически недоступен. Технически прежняя связка была стандартной — токен, счёт с bill_id, форма оплаты и подписанный вебхук на смену статуса, — поэтому её несложно демонтировать и заменить. Главное — не оставлять неработающий способ оплаты в корзине.

Мы помогаем магазинам на Битриксе безопасно уйти с недоступных платёжных сервисов и перевести приём оплаты на ЮKassa, банковский эквайринг, CloudPayments или СБП: подключаем обработчик, настраиваем фискализацию и вебхуки, тестируем и переключаем без потери заказов. Если у вас в корзине всё ещё «висит» QIWI — поможем аккуратно мигрировать.