Система крипто-інвойсингу: архітектура, моделі, інтеграція

Розробка системи крипто-інвойсингу

Ми часто отримуємо запити на створення крипто-інвойсингу — і це не просте завдання. Це не 'приймати оплату в крипті', а побудувати систему, в якій клієнт отримує рахунок, оплачує його в криптовалюті, а продавець отримує підтвердження з точним прив'язуванням до рахунку. Головна інженерна проблема — волатильність: якщо рахунок виставлено на $500, а курс ETH зрушився на 3% під час переказу, алгоритм має вирішити, як компенсувати розбіжність. Додатковий виклик — обробка часткових платежів, overpayment та мультивалютність. Наш досвід — понад 5+ років у блокчейн-розробці, 20+ впроваджених платіжних систем, гарантія дотримання термінів і безпеки. Системи проходять аудит смарт-контрактів і відповідають найкращим практикам безпеки. Оракули є критичним компонентом для точної фіксації курсу, як зазначено в документації Chainlink.

Чому крипто-інвойсинг потребує індивідуальної архітектури?

Кожен бізнес має свої правила ціноутворення. Ми виділяємо три основні моделі, підбираємо під вашу специфіку.

Моделі ціноутворення інвойсів

Фіксована крипто-сума: рахунок на 0.5 ETH. Клієнт платить рівно 0.5 ETH — волатильність фіатного еквіваленту лягає на продавця. Підходить для crypto-native B2B.

Фіксована фіатна сума з lock-in: рахунок на $500, система конвертує в крипто за курсом моменту і фіксує на 15–30 хвилин. Якщо вікно вичерпалося — перерахунок. Найпопулярніша модель.

Floating з tolerance: прийом оплати в діапазоні ±1–2% від очікуваної суми. Дрібні розбіжності через комісії або рух курсу не блокують платіж. Underpayment policy налаштовується — кредит на оплачену суму або запит доплати.

Архітектура системи

Життєвий цикл інвойсу

DRAFT → PENDING_PAYMENT (адреса присвоєна, таймер запущено) → PARTIALLY_PAID → PAID → CONFIRMED → EXPIRED → OVERPAID 

interface Invoice { id: string; merchantId: string; fiatAmount: Decimal; fiatCurrency: 'USD' | 'EUR' | 'GBP'; cryptoAmount: Decimal; cryptoCurrency: 'ETH' | 'USDT' | 'USDC' | 'BTC'; depositAddress: string; exchangeRateLockedAt: Date; expiresAt: Date; status: InvoiceStatus; paidAmount: Decimal; txHashes: string[]; } 

Генерація адрес

Для кожного інвойсу — унікальна адреса деривації з HD wallet xpub. Це дозволяє однозначно зіставити вхідний платіж без memo/тегів. HD-деривація на 60% ефективніша за газовими витратами ніж on-chain адресація з використанням смарт-контракту.

function deriveInvoiceAddress( xpub: string, invoiceIndex: number, network: Network ): string { const node = HDNodeWallet.fromExtendedKey(xpub); // path: m/44'/60'/0'/0/{invoiceIndex} для EVM return node.deriveChild(invoiceIndex).address; } 

Для Bitcoin — нативні SegWit (bech32) через BIP84. Для TRON USDT — окремий xpub для TRC-20.

Моніторинг вхідних платежів

EVM-мережі: підписка через WebSocket eth_subscribe("logs") на Transfer події ERC-20 токенів з фільтром по активних адресах. Для нативного ETH — моніторинг блоків через eth_subscribe("newHeads") + eth_getTransactionReceipt.

const monitorERC20Transfers = async ( activeAddresses: Set<string>, provider: WebSocketProvider ) => { const filter = { topics: [ ethers.id("Transfer(address,address,uint256)"), null, [...activeAddresses].map(addr => ethers.zeroPadValue(addr, 32)) ] }; provider.on(filter, async (log) => { const invoiceAddress = ethers.getAddress('0x' + log.topics[2].slice(26)); const amount = BigInt(log.data); await handleIncomingPayment(invoiceAddress, amount, log.transactionHash); }); }; 

Як агрегуються курси валют?

Для фіксації курсу ми використовуємо агрегатор з кількох бірж із захистом від аномалій. Максимальне відхилення від медіани — 1%.

class PriceAggregator: SOURCES = ['binance', 'coinbase', 'kraken'] MAX_DEVIATION_PCT = 1.0 async def get_price(self, base: str, quote: str) -> Decimal: prices = await asyncio.gather(*[ self.fetch_price(source, base, quote) for source in self.SOURCES ]) valid_prices = [p for p in prices if p is not None] median = statistics.median(valid_prices) filtered = [ p for p in valid_prices if abs(p - median) / median * 100 < self.MAX_DEVIATION_PCT ] return Decimal(str(statistics.mean(filtered))) 

Webhooks та інтеграція мерчантів

Сповіщення про статуси інвойсів через signed webhooks. Підпис HMAC-SHA256 з перевіркою timestamp (захист від replay-атак — події старші за 5 хвилин відхиляються). Retry-політика: експоненційний backoff (1 хв → 5 хв → 30 хв → 2 год → 24 год).

function signWebhookPayload(payload: object, secret: string): string { const body = JSON.stringify(payload); const timestamp = Math.floor(Date.now() / 1000); const signature = crypto .createHmac('sha256', secret) .update(`${timestamp}.${body}`) .digest('hex'); return `t=${timestamp},v1=${signature}`; } 

Порівняння методів інтеграції

WebSocket забезпечує затримку 2-5 секунд, що в 4-10 разів швидше ніж REST API polling (20-30 секунд). Signed webhook ще швидший — 1-3 секунди.

Як налаштувати webhook-сповіщення

1. Зареєструйте ендпоінт у панелі мерчанта.
2. Налаштуйте HMAC-ключ.
3. Обробіть сповіщення згідно зі специфікацією.
4. Перевірте підпис та timestamp.
5. Відповідайте HTTP 200 OK протягом 5 секунд.

Що входить у роботу?

Ми надаємо рішення під ключ:

• Архітектурну документацію та вибір моделі ціноутворення
• Розгортання інфраструктури (PostgreSQL, Redis, черги BullMQ)
• REST API + WebSocket для статусів інвойсів
• Signed webhooks з гарантованою доставкою
• PDF-інвойси та CSV-експорт для бухгалтерії
• Інтеграцію з accounting API (Xero, QuickBooks) опціонально
• Супровід протягом місяця після запуску

Стек та розгортання

Backend: Node.js/TypeScript або Go. Queue: BullMQ (Redis). DB: PostgreSQL + Redis. Ноди: Alchemy/QuickNode з failover або власні.

Вартість базового MVP починається від €20,000. Клієнти економлять до 30% на комісіях при використанні L2 рішень.

MVP з підтримкою ETH, USDT, USDC та базовим мерчант-порталом — за 3–4 тижні. Повна система — 8–10 тижнів. Оцініть ваш проект — пишіть нам для точної калькуляції вартості та термінів.