Покупка криптовалюти через банківський переказ — задача, з якою стикається кожен on-ramp сервіс, що прагне мінімальних комісій та максимальних лімітів. Картки Mastercard/Visa беруть 2–4%, а SEPA або SWIFT обходяться в 0–1%, що при обсягах $100K+ дає реальну економію. Наприклад, на одній з наших платформ перехід з карток на SEPA знизив комісійні витрати на $40 000 на рік при обсязі $2M. На іншому проєкті економія склала $150 000 на рік при обсязі $5M. Ми налаштували десятки таких інтеграцій для криптоплатформ: від вибору провайдера (Modulr, ClearBank, Railsr) до повної автоматизації матчингу платежів.
Типи банківських переказів
| Тип | Регіон | Час | Комісія (приблизно) | Ліміти |
|---|---|---|---|---|
| SEPA Credit Transfer | Європа (EUR) | 1 робочий день | 0–1% | $100K+ |
| SEPA Instant | Європа (EUR) | До 10 секунд | 0–1% | Обмежений банком |
| SWIFT | Міжнародний | 2–5 днів | $15–50 + курс | $1M+ |
| ACH | США (USD) | 1–3 дні | 0–0.5% | $100K+ |
| Faster Payments | Великобританія (GBP) | Миттєво | 0% | £1M |
| Open Banking | ЄС/UK | Миттєво | 0–0.5% | Залежить від банку |
Чому банківський переказ вигідніше карткового?
Порівняння комісій: картковий on-ramp бере 2–4%, банківський переказ — 0–1%, що в 3 рази дешевше при великих сумах. Ліміти: карти зазвичай обмежені $10K за транзакцію, банківські перекази — $100K і вище. Мінус — швидкість, але Open Banking вирішує і це. Для великих інвесторів та інституційних клієнтів банківські перекази стають єдиним варіантом — карти не можуть пропустити суми від $500K.
Архітектура прийому банківських переказів
Приклад реалізації сервісу депозитів
class BankTransferDepositService: async def create_deposit_order( self, user: User, amount: Decimal, currency: str, crypto_currency: str, ) -> DepositOrder: reference = self.generate_reference(user.id) order = await self.db.create_pending_deposit( user_id=user.id, reference=reference, expected_amount=amount, currency=currency, crypto_currency=crypto_currency, expires_at=datetime.now() + timedelta(hours=24), ) return DepositOrder( order_id=order.id, bank_name="Modulr Finance", account_name="Platform Name Ltd", iban="GB29NWBK60161331926819", bic="NWBKGB2L", reference=reference, amount=amount, currency=currency, expires_at=order.expires_at, ) def generate_reference(self, user_id: int) -> str: import random, string code = ''.join(random.choices(string.ascii_uppercase + string.digits, k=8)) return f"DEP{user_id:06d}{code}" Що входить в налаштування
- Інтеграція з банківським провайдером (Modulr, ClearBank, Railsr) через API
- Генерація унікального reference та його відображення користувачу
- Webhook-обробник для вхідних платежів з матчингом по reference
- Автоматичне повернення неідентифікованих платежів
- Вибір стратегії курсового захисту (фіксація або розрахунок за фактом)
- Тестування повного циклу: створення заявки → переказ → зарахування
- Документація з інтеграції та підтримка на етапі запуску
Open Banking інтеграція (TrueLayer)
Open Banking дозволяє користувачеві авторизувати платіж прямо зі свого банку, без ручного введення реквізитів та затримки SEPA. Це усуває головний бар'єр — швидкість. Детальніше про протокол можна прочитати в Wikipedia.
import httpx class TrueLayerClient: BASE_URL = "https://payment.truelayer.com" def __init__(self, client_id: str, client_secret: str): self.client_id = client_id self.client_secret = client_secret async def create_payment( self, amount_in_minor: int, currency: str, beneficiary_name: str, beneficiary_iban: str, reference: str, user_email: str, ) -> dict: token = await self.get_access_token() resp = await httpx.AsyncClient().post( f"{self.BASE_URL}/v3/payments", headers={"Authorization": f"Bearer {token}"}, json={ "amount_in_minor": amount_in_minor, "currency": currency, "payment_method": { "type": "bank_transfer", "provider_filter": {"countries": ["GB", "DE", "FR", "NL"]}, "beneficiary": { "type": "merchant_account", "account_holder_name": beneficiary_name, "account_identifier": { "type": "iban", "iban": beneficiary_iban, } } }, "user": {"email": user_email}, "metadata": {"reference": reference}, } ) data = resp.json() return { "payment_id": data["id"], "redirect_url": data["authorization_flow"]["actions"][0]["uri"] } Користувач отримує redirect на сторінку свого банку для підтвердження. Після підтвердження — гроші надходять миттєво.
Як працює матчинг вхідних платежів?
Головна складність банківських переказів — правильна ідентифікація відправника. Система отримує сповіщення про вхідні платежі від Banking-as-a-Service провайдера через webhook:
@app.post("/webhooks/banking/incoming") async def incoming_payment_webhook(request: Request): data = await request.json() payment = data["payment"] reference = extract_reference(payment["remittance_information"]) if not reference: await flag_for_manual_review(payment) return pending_order = await db.find_pending_deposit(reference=reference) if not pending_order: await flag_for_manual_review(payment) return if abs(payment["amount"] - float(pending_order.expected_amount)) > 0.01: await flag_for_manual_review(payment, pending_order.id) return await process_confirmed_deposit(pending_order.id, payment) def extract_reference(remittance_info: str) -> str | None: import re match = re.search(r'DEP\d{6}[A-Z0-9]{8}', remittance_info) return match.group(0) if match else None Як захиститися від коливань курсу?
На відміну від карткових платежів, при банківських переказах є затримка 1–3 дні. За цей час курс може значно змінитися. Два підходи:
| Стратегія | Курс | Ризик для платформи | UX |
|---|---|---|---|
| Фіксація курсу при заявці | Відомий відразу | Високий (потрібне хеджування) | Хороший |
| Розрахунок курсу при отриманні | Невідомий до зарахування | Низький | Середній |
- Курс фіксується в момент створення заявки — користувач бачить скільки крипто отримає. Ризик несе платформа. Потрібно хеджувати через форвардний контракт або негайну покупку крипто після отримання фіату.
- Курс розраховується в момент отримання — користувач отримує крипто за актуальним курсом. Менше ризику для платформи, гірше UX.
Більшість платформ використовує другий підхід для банківських переказів і явно повідомляє про це користувача.
Повернення неідентифікованих платежів
Обов'язковий процес: якщо вхідний платіж не вдалося зіставити з депозитом протягом 24–48 годин, він повертається відправнику через reverse transfer. Зберігання чужих коштів без ідентифікації — регуляторне порушення.
Як ми працюємо
- Аналітика — вивчаємо вашу платформу, обсяги, вимоги до ліквідності.
- Проектування — обираємо провайдера, визначаємо схему матчингу та курсову стратегію.
- Реалізація — пишемо інтеграцію з API банку, налаштовуємо webhook, автоматизуємо повернення.
- Тестування — покриваємо unit-тестами, симуляція депозитів, тест з реальним банком.
- Розгортання — поетапний rollout з моніторингом та підтримкою.
Наші інженери мають 10+ років досвіду в блокчейн-розробці та успішно запустили 50+ фіатних on-ramp інтеграцій. Гарантуємо якість та строки.
Зв'яжіться з нами для оцінки вашого проєкту — наша команда готова обговорити деталі. Замовте консультацію, і ми запропонуємо оптимальну архітектуру для вашої криптоплатформи.