Платёжный сценарий
Согласуем, как создаётся платёжное требование, выбираются актив и сеть и связывается поступление с заказом клиента.
Встройте приём криптовалюты в свой сервис: платёжный адрес, QR-код, обнаружение поступления и статус операции в вашем интерфейсе.
Согласуем, как создаётся платёжное требование, выбираются актив и сеть и связывается поступление с заказом клиента.
Клиент получает реквизиты перевода в выбранной сети. QR помогает передать платёжные данные, но не заменяет проверку актива, сети и суммы.
Поступления определяются в блокчейн-контуре. Число подтверждений и момент изменения статуса согласуются для каждой сети и суммы операции.
Ваш продукт получает информацию об операции через согласованный интерфейс. Формат статусов, уведомления и обработка повторных событий входят в проект интеграции.
AML-контроль и разбор нестандартных платежей включаются в рабочий процесс. Правила недоплаты, переплаты и позднего поступления фиксируются до запуска.
Кастодиальная инфраструктура обеспечивает работу с полученными активами. Вывод и выплаты оформляются как отдельные управляемые операции.
Заказ связывается с суммой, активом, сетью и реквизитами.
Плательщик отправляет криптовалюту со своего кошелька.
Система наблюдает поступление и применяет правила обработки.
Ваш сервис получает статус и продолжает выполнение заказа.
Здесь QR содержит данные криптовалютного перевода. Это отдельный механизм от СБП и банковского эквайринга. Если проект включает рублёвую оплату, подключение банка или платёжного провайдера рассматривается отдельно.
Недостаточная сумма, другая сеть, позднее поступление и повторное уведомление не должны автоматически превращаться в успешную оплату. На пилоте проверяем такие сценарии и согласуем действия системы и оператора. Возврат также требует проверки получателя и отдельного подтверждения.
Обсудим ограничения и проверим выбранный сценарий на пилоте.
Возможность зависит от выбранной сети и комплектации. Перед внедрением фиксируем точный актив, контракт, сеть и поддерживаемые операции.
После выполнения согласованных правил: поступление, необходимое число подтверждений и предусмотренные проверки. Одного появления транзакции в сети может быть недостаточно.
Да, интеграция проектируется под ваш клиентский путь. Нужны описание заказа, способ передачи статусов и правила обработки ошибок.
Конвертация и фиатные расчёты требуют отдельного маршрута и подключённых партнёров. Их нельзя считать включёнными только по факту подключения криптопроцессинга.
Опишем необходимые операции, интеграции и критерии результата. Состав поставки и стоимость определим по вашему сценарию.
Оставить заявку ↗