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

Коротко
Подтверждение — это включение транзакции в блок и набор блоков сверху. Чем больше сумма и медленнее сеть, тем выше порог. Для UX важны не только цифры «N подтверждений», но и правильно настроенные статусы: «создан», «ожидание оплаты», «ожидает подтверждений», «частично оплачено», «переплата», «оплачено», «просрочено», «возврат». Хорошая схема статусов, вебхуки и понятные письма клиенту дают рост конверсии и меньше споров.
Что такое подтверждения и почему они важны
Когда клиент отправляет крипту, транзакция попадает в мемпул и ждёт включения в блок. После включения у неё появляется 1 подтверждение; каждый следующий блок сверху — ещё по одному. Чем выше подтверждений, тем труднее «откатить» перевод. Для быстрых сетей и мелких чеков порог можно ставить низкий (1–2), для больших сумм и сетей с вероятностной финальностью — выше.
Рекомендуемые пороги подтверждений
Это практические ориентиры. Подстрой по риску и среднему чеку.
| Сеть / актив | Мелкие чеки (до $100) | Средние ($100–$1k) | Крупные ($1k+) | Комментарий |
|---|---|---|---|---|
| Bitcoin (L1) | 1 | 2–3 | 3–6 | Для дорогих товаров лучше 6 |
| Lightning | 0 (мгновенно) | 0 | 0 | Принимаем после успешного HTLC |
| Ethereum (ERC-20) | 3 | 6–12 | 12–20 | В пиковые часы — верхняя граница |
| Tron (TRC-20) | 1 | 1–2 | 2–3 | Хорош для частых мелких чеков |
| BNB Smart Chain (BEP-20) | 1 | 2–3 | 3–5 | Следи за нагрузкой сети |
| Polygon (PoS) | 2 | 3–6 | 6–12 | Для больших сумм — ближе к 12 |
| Arbitrum/Optimism (L2) | 2 | 4–8 | 8–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 и статусы