API для приёма платежей: подключение онлайн-оплаты на сайте и в приложении

Чтобы принимать оплату на сайте, в Telegram-боте или мобильном приложении, компания подключается к платёжному сервису и интегрирует его API. В Узбекистане распространены Payme, Click, Uzum и банковский интернет-эквайринг. Технически они устроены по-разному, но общие принципы похожи: заказ создаётся у вас, оплата проходит у платёжного сервиса, а результат передаётся обратно на ваш сервер.

Подключение

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

Основные схемы

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

Данные карт клиент вводит на стороне платёжного сервиса. Ваша система не должна их получать и хранить.

Как сервис сообщает об оплате

Ключевой момент интеграции — подтверждение оплаты. Платёжный сервис отправляет запросы на ваш сервер. Например, в протоколе Payme сервис вызывает методы на стороне мерчанта: проверка возможности оплаты, создание транзакции, её проведение, отмена. Click использует двухэтапную схему подготовки и завершения платежа. У банковского эквайринга — свои уведомления. Точный порядок и формат описаны в документации каждого сервиса. Ваш сервер должен быть доступен для этих запросов из интернета по HTTPS и отвечать быстро: если ответ задерживается, сервис может посчитать платёж неуспешным.

Ваш сервер должен проверить, что заказ существует, сумма совпадает, заказ ещё не оплачен, и только после этого подтвердить платёж.

Проверки на вашей стороне

• Подлинность запроса: подпись, ключ или ограничение по адресам сервиса
• Соответствие суммы сумме заказа, рассчитанной на сервере
• Защита от повторной обработки одного платежа
• Корректная обработка отмен и возвратов
• Сохранение всех запросов и ответов в журнал

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

Статусы заказа

Заказ проходит статусы: создан, ожидает оплаты, оплачен, отменён, возвращён. Переход в «оплачен» происходит только по подтверждению от сервиса. Если подтверждение не пришло, сервер периодически проверяет статус транзакции через API сервиса.

Возвраты

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

Фискализация

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

Тестирование

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

Несколько сервисов

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