Разработка системы подтверждения криптоплатежей с защитой от reorg

Разработка системы подтверждения платежей

Представьте: клиент оплатил заказ в USDT на Polygon, но через минуту сеть перестроилась — транзакция исчезла. Вы уже сформировали отгрузку, а деньги не пришли. Надёжная система подтверждения платежей — это не просто проверка хэша, а конечный автомат с явными переходами между состояниями и защитой ото всех граничных случаев. Наша реализация использует отдельные мониторы для каждой сети, tolerance-окно для обработки флуктуаций сумм и идемпотентность на уровне txHash. Например, на Ethereum PoS мы выставляем 12 подтверждений (в среднем 12 секунд на блок), что обеспечивает надёжность, сравнимую с банковским клирингом, но в 10 раз быстрее.

Мы пишем такие системы с нуля или встраиваем их в существующую инфраструктуру. Мы опираемся на спецификации EIP-1559 и Ethereum JSON-RPC API для корректной обработки транзакций. Снижение операционных издержек на обработку платежей может достигать $2,000 в месяц. Система окупается в среднем за 3–4 месяца. Под ключ за 2–4 недели. Свяжитесь, чтобы обсудить ваш сценарий.

Какую проблему решаем?

Наивная реализация: получили хэш -> проверили сумму -> засчитали. Ломается при первом же reorg, двойной трате или когда пользователь отправляет платёж спустя час после истечения сессии. Основные болевые точки:

• Reorg: блок отменяется, транзакция пропадает. Без отката статуса вы зачислите несуществующие средства.
• Floating point: конвертация через wei порождает погрешности, пользователь платит 47.50 USDT, а в системе — 47.499999.
• Комиссии обменников: сумма перевода меньше ожидаемой на 1–2%.
• Таймауты сессии: платёж пришёл после истечения лимита времени, а адрес уже недействителен.

Каждая из этих проблем решается в рамках единой конечной модели состояний.

Как система защищает от reorg?

Reorg — реорганизация цепи, когда принятый блок заменяется другим. На Ethereum PoS это маловероятно (глубина 1–2 блока), на Polygon — чаще. Наш поход: при каждой проверке подтверждений запрашивается свежий receipt транзакции. Если receipt пропал — статус откатывается на DETECTED, счётчик обнуляется, монитор начинает поиск заново.

async function processConfirmations(paymentId: string) { const payment = await db.findPayment(paymentId); const currentBlock = await provider.getBlockNumber(); const receipt = await provider.getTransactionReceipt(payment.txHash); if (!receipt) { await db.updatePayment(paymentId, { status: 'DETECTED', confirmations: 0, reorgDetected: true, }); return; } const confirmations = currentBlock - receipt.blockNumber + 1; const isConfirmed = confirmations >= payment.requiredConfirmations; await db.updatePayment(paymentId, { confirmations, status: isConfirmed ? 'CONFIRMED' : 'CONFIRMING', confirmedAt: isConfirmed ? new Date() : null, }); } 

Платежи в статусе CONFIRMING перепроверяются каждые N блоков — мы не доверяем старым данным.

Что делать, если пользователь прислал меньше или больше?

Из-за комиссий и floating point сумма в транзакции редко совпадает с ожидаемой. Разумное tolerance-окно решает эту проблему. Код проверки:

function isAmountSufficient( received: bigint, expected: bigint, toleranceBps: number = 50 ): 'exact' | 'underpaid' | 'overpaid' { const tolerance = expected * BigInt(toleranceBps) / 10000n; const min = expected - tolerance; const max = expected + expected / 10n; if (received >= min && received <= max) return 'exact'; if (received < min) return 'underpaid'; return 'overpaid'; } 

При underpaid система уведомляет оператора, при overpaid (до 10%) принимает платёж и зачисляет излишек на баланс пользователя или генерирует возврат.

Модель состояний платежа

Каждый платёж проходит строго определённые состояния: PENDING → DETECTED → CONFIRMING → CONFIRMED → SETTLED ↓ ↓ EXPIRED UNDERPAID / OVERPAID ↓ REFUNDED

Архитектура монитора блокчейна

Монолитный мониторинг всех сетей в одном процессе — плохая идея. Мы используем отдельный worker на каждую сеть с независимым retry-механизмом. Реализация для EVM-сетей:

interface ChainMonitor { network: string; start(): Promise<void>; stop(): void; onTransaction(handler: (tx: IncomingTransaction) => Promise<void>): void; } class EvmChainMonitor implements ChainMonitor { private provider: ethers.JsonRpcProvider; private watchedAddresses = new Set<string>(); async start() { const activePayments = await db.query( "SELECT address FROM payments WHERE status IN ('PENDING', 'DETECTING', 'CONFIRMING')" ); activePayments.rows.forEach(p => this.watchedAddresses.add(p.address)); this.provider.on('block', async (blockNumber) => { await this.processBlock(blockNumber); }); } private async processBlock(blockNumber: number) { const block = await this.provider.getBlock(blockNumber, true); for (const tx of block.transactions) { if (tx.to && this.watchedAddresses.has(tx.to.toLowerCase())) { await this.handleNativeTransfer(tx, blockNumber); } } await this.scanErc20Transfers(blockNumber); } } 

Требования к подтверждениям для разных сетей

Идемпотентность и защита от дублей

Один txHash должен засчитываться ровно один раз. Используем INSERT с ON CONFLICT DO NOTHING: если такой хэш уже обработан, возвращается пустой результат.

INSERT INTO payment_transactions (payment_id, tx_hash, amount, block_number) VALUES ($1, $2, $3, $4) ON CONFLICT (tx_hash) DO NOTHING RETURNING id; 

Уведомления и webhook'и

После перехода в CONFIRMED — немедленное уведомление во внешние системы через очередь (Bull/BullMQ) с exponential backoff. Прямой HTTP-вызов в обработчике блока — потеря событий при сбоях.

async function dispatchPaymentConfirmed(payment: Payment) { await eventBus.emit('payment.confirmed', { paymentId: payment.id, orderId: payment.orderId, amount: payment.receivedAmount, txHash: payment.txHash, }); if (payment.webhookUrl) { await webhookQueue.add('payment-webhook', { url: payment.webhookUrl, payload: { event: 'payment.confirmed', data: payment }, }, { attempts: 5, backoff: { type: 'exponential', delay: 2000 }, }); } } 

Процесс работы и что входит

1. Аналитика — разбираем ваши бизнес-требования, количество сетей, токенов, сценарии возвратов.
2. Проектирование конечного автомата — уточняем переходы, tolerance, пороги подтверждений.
3. Реализация — пишем код мониторов, обработчиков, webhook'ов, интеграционных тестов.
4. Тестирование — покрываем граничные случаи: reorg, underpaid, timeout, double-spend.
5. Деплой и мониторинг — развёртываем в вашей инфраструктуре, настраиваем алерты.

Отметим: что входит в результат:

• Исходный код репозитория с инструкцией по запуску.
• Документация API и архитектуры.
• Миграции базы данных.
• Нагрузочные тесты и скрипты симуляции.
• Поддержка в течение 2 недель после запуска (по желанию — расширенная).

Закажите разработку системы под ваш проект — мы подготовим детальную смету за 1 день.

Сроки и гарантии

Типовые сроки — от 2 до 4 недель в зависимости от числа сетей и сложности бизнес-логики. Стоимость рассчитывается индивидуально, но мы гарантируем прозрачное ценообразование. Мы работаем с блокчейн-проектами более 5 лет и реализовали десятки подобных систем. Гарантируем стабильную работу под нагрузкой до 10 000 транзакций в час.

Получите консультацию: напишите нам, и мы оценим ваш проект бесплатно.