Подтверждения и статусы оплат: настройка без ошибок

Payment confirmations and statuses: error-free setup

Коротко

Подтверждение — это включение транзакции в блок и набор блоков сверху. Чем больше сумма и медленнее сеть, тем выше порог. Для UX важны не только цифры «N подтверждений», но и правильно настроенные статусы: «создан», «ожидание оплаты», «ожидает подтверждений», «частично оплачено», «переплата», «оплачено», «просрочено», «возврат». Хорошая схема статусов, вебхуки и понятные письма клиенту дают рост конверсии и меньше споров.

Что такое подтверждения и почему они важны

Когда клиент отправляет крипту, транзакция попадает в мемпул и ждёт включения в блок. После включения у неё появляется 1 подтверждение; каждый следующий блок сверху — ещё по одному. Чем выше подтверждений, тем труднее «откатить» перевод. Для быстрых сетей и мелких чеков порог можно ставить низкий (1–2), для больших сумм и сетей с вероятностной финальностью — выше.

Рекомендуемые пороги подтверждений

Это практические ориентиры. Подстрой по риску и среднему чеку.

Сеть / активМелкие чеки (до $100)Средние ($100–$1k)Крупные ($1k+)Комментарий
Bitcoin (L1)12–33–6Для дорогих товаров лучше 6
Lightning0 (мгновенно)00Принимаем после успешного HTLC
Ethereum (ERC-20)36–1212–20В пиковые часы — верхняя граница
Tron (TRC-20)11–22–3Хорош для частых мелких чеков
BNB Smart Chain (BEP-20)12–33–5Следи за нагрузкой сети
Polygon (PoS)23–66–12Для больших сумм — ближе к 12
Arbitrum/Optimism (L2)24–88–12На L2 финальность быстрая; для выплат на L1 действуют свои окна
Solana«finalized» статус«finalized»«finalized» + задержка 20–60 cОриентируйся на уровень finalized в RPC

Схема статусов для магазина

рекомендую завести именно такие статусы (они покрывают 99% кейсов)

  • Счёт создан — клиент видит сумму, сеть и таймер жизни счёта.
  • Ожидание оплаты — адрес выдан, средств ещё нет.
  • Платёж обнаружен — пришла транзакция, ждём N подтверждений.
  • Частично оплачено — сумма ниже требуемой (underpaid). Показываем «доплатить X».
  • Переплата — сумма выше требуемой (overpaid). Предлагаем зачислить полностью или вернуть разницу.
  • Оплачено — подтверждений достаточно, заказ закрыт в пользу клиента.
  • Просрочено — счёт истёк, транзакции не пришло.
  • Возврат отправлен — оформили возврат по регламенту.
  • Проверка AML/KYT — временный статус, если риск-скоринг выше порога.

Таймер счёта и «грэйс-период»

  • Время жизни счёта: 15–30 минут для динамического курса (когда показываешь «оплатить X USDT/ETH по курсу»).
  • Грэйс-период: ещё 15–30 минут после истечения счёта, чтобы не терять платежи, которые «летят» в сети.
  • Фиксация курса: для стейблкоинов курс ≈ фикс, для волатильных активов либо пересчитывай сумму каждые N минут, либо принимай с допуском ±0.5–1%.

Поддержка частичных оплат и переплат

  • Underpaid: покажи клиенту, сколько доплатить, дай кнопку «доплатить». Автопринятие, если недостача ≤0.5% для стейблкоинов и ≤1% для волатильных (можно настраивать).
  • Overpaid: по умолчанию зачисляй всю сумму; если политика магазина — «возврат разницы», делай его автоматически за вычетом сетевой комиссии.
  • Все решения логируй с tx-hash и временем.

Сети и типовые ошибки клиентов

  • Неверная сеть (TRC20 vs ERC20): пиши крупно «Вы выбрали сеть TRC20. Проверьте сеть в кошельке перед отправкой».
  • Недостаток газа: напоминание «в сети TRON комиссия списывается в TRX».
  • Длинные очереди: пояснение «в сети загруженность, подтверждение может занять до X минут».
  • Двойная оплата: «если вы отправили повторно, укажите хэш, мы вернём излишек».

Мини-регламент писем клиенту

  • Создан счёт: сумма, сеть, таймер, подсказка по сети и комиссии.
  • Платёж обнаружен: «мы видим перевод, ждём N подтверждений, обычно это X–Y минут».
  • Частично/переплата: «получили ХХ, необходимо доплатить YY / можем вернуть ZZ».
  • Оплачено: «платёж подтверждён, заказ в работе, хэш: …».
  • Проверка AML: «платёж на стандартной проверке, это до 24 часов».
  • Возврат: «отправили возврат, хэш: …».

Webhook/Callback: что передавать

Webhook/Callback: что передаёт процессинг
{
  "event": "payment.confirmations_updated",
  "invoice_id": "INV-12345",
  "status": "pending_confirmations",
  "network": "ERC20",
  "asset": "USDT",
  "required_confirmations": 6,
  "current_confirmations": 3,
  "amount_expected": "100.00",
  "amount_received": "100.00",
  "tx_hash": "0x...",
  "timestamp": 1739722222,
  "signature": "HMAC-SHA256..."
}

Другие события: invoice.created, invoice.expired, payment.detected, payment.confirmations_updated, payment.underpaid, payment.overpaid, payment.paid, payment.refund_initiated, payment.refund_sent, payment.aml_review.

Другие события: invoice.created, invoice.expired, payment.detected, payment.underpaid, payment.overpaid, payment.paid, payment.refund_initiated, payment.refund_sent, payment.aml_review.

Логирование для бухгалтерии и споров

Сохраняй: invoice_id, адрес получателя, сеть, сумма в крипте и фиате, tx-hash, число подтверждений и время, статусы, e-mail клиента, решения по under/overpaid, возвраты. Экспортируй CSV раз в неделю.

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

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

HTML-чек-лист для публикации

Чек-лист: подтверждения и статусы без ошибок

  • Заданы пороги подтверждений по сетям и размерам чеков.
  • Включены статусы: создан / ожидание / подтверждения / частично / переплата / оплачено / просрочено / AML / возврат.
  • Настроен таймер счёта и грэйс-период для «медленных» сетей.
  • Настроены пороги underpaid/overpaid и сценарии «доплатить/вернуть разницу».
  • Webhook передаёт tx-hash, текущие подтверждения и подписан HMAC.
  • Подготовлены письма клиенту для всех статусов.

Частые вопросы

Зачем столько подтверждений, если транзакцию уже видно? Видимость ≠ финальность. Подтверждения снижают риск отката и двойной траты.
Можно ли ставить 0 подтверждений? Для Lightning и некоторых L2 — да. Для L1 это риск; делай так только для микроплатежей и постоянных клиентов.
Почему клиенты иногда недоплачивают? Неправильно учли курс, неправильно скопировали сумму, истёк таймер, в кошельке «округление». Решается доплатой или допуском.
Что делать с задержавшимися оплатами после истечения счёта? Принимай в грэйс-период или выставляй новый счёт, объясняя клиенту в письме.

Читайте также

Криптопроцессинг: как это работает и чем лучше эквайринга

USDT для бизнеса: TRC20 vs ERC20 vs BEP20

AML в криптоплатежах: как работает проверка транзакций и кошельков на «чистоту»

WooCommerce + криптоплатежи: подключение, webhook и статусы

About The Author