Платёжный шлюз для приёма USDT и USDC: checkout, KYT и сеттлмент
Приём стейблкоинов в СНГ — это в первую очередь USDT-TRC20: дешёвый рельс, привычный отправителям, но требующий жёсткого комплаенса на входе. PSP, который собирает платёж, обязан отскринить его до того, как деньги уйдут мерчанту, и при этом не задвоить учёт при повторной доставке вебхука. Ниже — сборка платёжного шлюза, где сбор через checkout, скрининг входящих и сеттлмент мерчантам работают на одном ключе и одном балансе.
Задача
Мерчант хочет принимать USDT и USDC и получать чистый сеттлмент. PSP нужно сгенерировать счёт, показать плательщику hosted-checkout, отследить статус (недоплата, переплата, число подтверждений), проверить входящий платёж на санкции и риск — и только после этого рассчитать мерчанта. Две отдельные проблемы ломают наивную реализацию: без скрининга на входе грязные деньги попадают в сеттлмент, а без идемпотентности повторная доставка события об оплате приводит к двойному зачислению. Обычно это три интеграции: прайс/чтение сети, вендор скрининга и выплатной рельс.
- Invoices / checkoutC2
- Transaction screening / KYTC3
- Sanctions check + feedC2
- Mass payout / settlementC2
Hosted-checkout и трекинг статуса платежа
Под каждый заказ выпускается invoice с hosted-checkout: плательщик видит адрес и сумму, а платформа отслеживает недоплату, переплату и число подтверждений в сети. Чтение статуса идёт с собственных нод TRON и ETH, поэтому подтверждения USDT-TRC20 приходят без задержек и лимитов rps, характерных для публичных RPC-эндпоинтов.
Скрининг входящих до сеттлмента
Каждый входящий платёж проходит KYT и sanctions-скрининг до того, как попадёт в расчёт мерчанту. Платёж с высоким risk-score или связью с санкционным кластером не уходит в сеттлмент автоматически, а поднимается на разбор — вы не рассчитываете мерчанта средствами, которые не прошли проверку.
Идемпотентный сеттлмент с одного баланса
События об оплате подписаны и идемпотентны: повторная доставка вебхука не приводит к двойному учёту платежа. Выплата мерчанту (settlement) идёт mass payout с того же prepaid-баланса, что и checkout со скринингом, — приём, проверка и расчёт списываются с единого баланса кредитов, а подпись выплатных транзакций остаётся на вашей стороне.
Что даёт сборка
- Приём USDT/USDC, KYT/sanctions-скрининг и сеттлмент мерчантам — на одном ключе и одном балансе кредитов.
- В сеттлмент попадают только прошедшие скрининг платежи, рискованные входящие уходят на ручной разбор.
- Подписанные идемпотентные события исключают двойной учёт при повторной доставке вебхука об оплате.
Частые вопросы
Как отслеживаются недоплаты и переплаты по счёту?
Hosted-checkout привязывает ожидаемую сумму к invoice и сверяет её с фактически пришедшим объёмом. Недоплата, переплата и текущее число подтверждений видны в статусе счёта, так что вы решаете судьбу платежа по реальному состоянию, а не по факту прихода любой суммы.
Что защищает от двойного зачисления при повторных вебхуках?
События подписаны и идемпотентны: у каждого есть устойчивый идентификатор, и повторная доставка того же события распознаётся как дубликат. Учёт платежа происходит один раз, сколько бы раз провайдер доставки ни повторил уведомление.
Пополнили, получили ключ, запустили.
Полное самообслуживание. Оплата криптой или картой. Тарификация в кредитах — тяжёлые примитивы дороже, простые дёшевы.
Получить API-ключ