Розробка White-label криптоплатіжного шлюзу під ключ
Ви запускаєте криптовалютний процесинг для десятків мерчантів. Кожному потрібен власний checkout з логотипом, окремі API-ключі, білінг. Але будувати платіжну інфраструктуру з нуля — це місяці розробки і мільйонні вкладення. White-label криптоплатіжний шлюз вирішує проблему: ви отримуєте готову мультиарендну платформу, яку продаєте під своїм брендом. Наші інженери з 10-річним досвідом у блокчейн-розробці — Ethereum, Polygon, Arbitrum, Solana, L2 — реалізували 50+ подібних проектів: від стартапів до enterprise. Наприклад, один клієнт — криптоекваєр з Південно-Східної Азії — запустив платформу за 6 тижнів і вже через місяць обробляв 50 000 транзакцій на день. Ми беремо повний цикл: від архітектури до деплою. Оцінимо ваше завдання за 1 день — просто напишіть нам.
Типова помилка — намагатися адаптувати однотенантний реєстр: це призводить до порушення ізоляції даних і вразливостей. White-label архітектура з самого початку закладає мультиарендність.
Як побудувати мультиарендний white-label платіжний шлюз?
Стратегія деривації адрес — розробка white label
Кожен tenant отримує власний master xpub, з якого деривуються адреси його мерчантів і замовлень. Структура шляху:
m / purpose' / coin_type' / tenant_id' / merchant_id / order_index BIP32 (Hierarchical Deterministic Wallets) — стандарт, який ми використовуємо для безпечної деривації. Приклад для EVM-мереж:
import { HDNodeWallet } from "ethers"; class TenantWalletManager { private masterNode: HDNodeWallet; constructor(masterMnemonic: string) { this.masterNode = HDNodeWallet.fromPhrase(masterMnemonic); } getTenantXpub(tenantId: number): string { return this.masterNode .deriveChild(44 + 0x80000000) .deriveChild(60 + 0x80000000) .deriveChild(tenantId + 0x80000000) .neuter() .extendedKey; } getDepositAddress(tenantXpub: string, merchantId: number, orderIndex: number): string { const tenantNode = HDNodeWallet.fromExtendedKey(tenantXpub); return tenantNode .deriveChild(merchantId) .deriveChild(orderIndex) .address; } } Це дозволяє tenant'у самостійно верифікувати адреси, але не отримати контроль над майстер-ключами.
Як забезпечити ізоляцію даних?
Замість окремих баз даних використовуємо row-level security — простіше в операціях:
ALTER TABLE payments ENABLE ROW LEVEL SECURITY; CREATE POLICY tenant_isolation ON payments USING (tenant_id = current_setting('app.tenant_id')::uuid); SET LOCAL app.tenant_id = '...'; Для високих навантажень (100+ tenant'ів) — окрема схема на tenant через search_path. Така ізоляція гарантує, що дані кожного tenant'а конфіденційні. У виробництві це різниця між «одним інцидентом» і «втратою всіх клієнтів».
Покрокове налаштування tenant
- Створіть tenant в адмін-панелі.
- Вкажіть домен і брендинг.
- Згенеруйте API-ключі.
- Налаштуйте білінг.
- Перевірте інтеграцію через тестовий платіж.
API для мерчантів та вебхуки
Мерчанти інтегруються через REST API, аналогічно Stripe. Аутентифікація через пару ключів (публічний + секретний). Приклад створення інвойсу:
POST /api/v1/invoices { "amount": "99.99", "currency": "USD", "accepted_coins": ["ETH", "USDT_ERC20", "BTC"], "order_id": "order_123", "customer_email": "[email protected]", "success_url": "https://shop.example.com/success", "cancel_url": "https://shop.example.com/cancel", "metadata": { "product_id": "456" }, "expires_in": 900 } Webhook система з надійною доставкою: 1хв → 5хв → 30хв → 2год → 8год → 24год. Після 6 невдач — позначаємо як failed з можливістю ручного повтору з dashboard. Підпис кожної події через HMAC-SHA256.
Checkout UI та кастомні домени
Фронтенд повністю налаштовується під бренд tenant'а: primary color, logo, font, borderRadius, dark mode. При завантаженні checkout сторінки динамічно інжектуються CSS variables. Кожен tenant може підключити власний домен (наприклад, pay.theirclient.com) — SSL автоматично налаштовується через Let's Encrypt.
Як налаштувати SSL для домену?
Після додавання домену в панель управління tenant'а, система автоматично перевіряє володіння через DNS-запис TXT або CNAME. Let's Encrypt випускає сертифікат на 90 днів з автоматичним оновленням. Все прозоро для користувача.Білінг, безпека та compliance
| Модель | Реалізація |
|---|---|
| Відсоток від об'єму | Утримання при sweep на hot wallet |
| Фіксована плата за транзакцію | Додавання fee до суми або вирахування при sweep |
| Subscription | Щомісячна плата за доступ |
| Комбінована | Subscription + знижений відсоток |
Безпека
- API-ключі: генерація через
crypto.randomBytes(32), зберігання лише хешу (sha256) - Rate limiting: окремі ліміти на кожен ключ (Redis + sliding window)
- IP whitelist: обмеження по IP для продакшену
- Audit log: всі адміністративні дії в immutable таблиці
- AML: опціональна інтеграція з Chainalysis або Elliptic
Що входить в роботу
- Архітектурна схема та документація (OpenAPI, ERD)
- Вихідний код репозиторію з CI/CD
- Налаштовані домени та SSL для кожного tenant
- Навчання команди tenant'а (2–3 воркшопи)
- Підтримка на етапі запуску (2 тижні)
- Можливість подальшого супроводу по SLA
Строки та етапи робіт
| Етап | Тривалість |
|---|---|
| Аналітика та проектування | 1–2 дні |
| Core Gateway Engine | 1–2 тижні |
| Merchant API та webhooks | 1 тиждень |
| Checkout UI та тематизація | 1 тиждень |
| Tenant management та білінг | 1 тиждень |
| Admin dashboard | 1–2 тижні |
| Тестування та security review | 1–2 тижні |
Мінімальний MVP (5–6 мереж, брендований checkout, API) — 6–8 тижнів. Повноцінна enterprise-платформа — близько 3 місяців.
Чому white-label вигідніше?
White-label платформа виводить на ринок у 3–4 рази швидше, ніж розробка з нуля. Ви отримуєте готову архітектуру, перевірену безпеку та можливість масштабування без переписування коду. Економія порівняно з самостійною розробкою — до 40% бюджету та 3–4 місяці часу. Якщо ви хочете обговорити ваш проект, зв'яжіться з нами — оцінимо завдання за 1 день.