Интеграция платёжного шлюза: что учесть кроме приёма карт

Что входит кроме самой оплаты

Полная интеграция закрывает весь жизненный цикл платежа:

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

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

Вебхуки: главный источник ошибок

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

Уведомление может прийти дважды. Сеть ненадёжна, провайдер повторяет попытку, и ваш обработчик получит одно и то же сообщение несколько раз. Если он при каждом вызове выдаёт товар, вы раздадите его втрое.

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

Уведомление может не прийти вовсе. Поэтому статус платежа нельзя считать финальным только по вебхуку: нужна периодическая сверка через API провайдера.

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

Это свойство операции давать один и тот же результат при повторном выполнении. Пользователь нажал кнопку дважды, браузер повторил запрос, сеть продублировала пакет — списание должно произойти один раз.

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

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

Что влияет на выбор провайдера

Не только комиссия. Смотреть стоит на:

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

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

Безопасность и данные карт

Самое простое правило: не храните данные карт у себя. Если данные карты попадают на ваш сервер, вы попадаете под требования стандарта PCI DSS, а это отдельный проект с аудитом и постоянными расходами.

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

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

Что проверить до запуска

Пройдите эти сценарии в тестовой среде, а не надейтесь на удачу:

• Двойное нажатие кнопки оплаты.
• Закрытие вкладки сразу после оплаты.
• Вебхук пришёл дважды.
• Вебхук не пришёл вовсе.
• Оплата прошла, а создание заказа упало с ошибкой.
• Частичный возврат.
• Отказ банка на этапе подтверждения.