Інтеграція з Visa/Mastercard для крипто-карти

Проєктуємо та розробляємо блокчейн-рішення повного циклу: від архітектури смарт-контрактів до запуску DeFi-протоколів, NFT-маркетплейсів та криптобірж. Аудит безпеки, токеноміка, інтеграція з наявною інфраструктурою.
Показано 1 з 1Усі 1305 послуг
Інтеграція з Visa/Mastercard для крипто-карти
Складний
від 2 тижнів до 3 місяців
Часті запитання

Напрямки блокчейн-розробки

Етапи блокчейн-розробки

Останні роботи

  • image_website-b2b-advance_0.webp
    Розробка сайту компанії B2B ADVANCE
    1356
  • image_web-applications_feedme_466_0.webp
    Розробка веб-додатків для компанії FEEDME
    1248
  • image_websites_belfingroup_462_0.webp
    Розробка веб-сайту для компанії БЕЛФІНГРУП
    953
  • image_ecommerce_furnoro_435_0.webp
    Розробка інтернет магазину для компанії FURNORO
    1187
  • image_logo-advance_0.webp
    Розробка логотипу компанії B2B Advance
    644
  • image_crm_enviok_479_0.webp
    Розробка веб-додатків для компанії Enviok
    925

Ви запускаєте криптоплатформу та хочете випустити дебетову карту, яка конвертує BTC в USD за секунду до оплати. Проблема: інтеграція крипто-карти з Visa/Mastercard вимагає трьох рівнів — principal member (банк із членством у мережі), program manager (Marqeta/Stripe Issuing) та ваша платформа. Пряме членство — 12–24 місяці та капітал від $2M. Реалістичний шлях для стартапу — робота через program manager, який уже має членство. Ми спеціалізуємося на технічній стороні такої інтеграції під ключ: від вибору процесингового партнера до запуску карткового продукту. За 5+ років досвіду ми реалізували 10+ подібних проєктів — гарантуємо якість та безпеку.

Наш досвід показує, що більшість криптоплатформ обирають Marqeta як card issuing API — це найбільш гнучке рішення з підтримкою JIT Funding. Альтернатива — Stripe Issuing, але вона вимагає попереднього фіатного резерву. Ми допоможемо оцінити ваш проєкт та обрати оптимального провайдера.

Щоб зрозуміти архітектуру, розберемо структуру:

Visa/Mastercard Network
    ↓
Principal Member Bank (BIN owner)
    ↓
Card Program Manager (Marqeta, Stripe Issuing, Galileo)
    ↓
Your Crypto Platform
    ↓
End User

Principal Member — банк із прямим членством у Visa/MC, видає BIN-діапазони. Program Manager — технологічний посередник, надає API для випуску карт та процесингу авторизацій, бере на себе технічні та частково регуляторні зобов'язання. Ваша платформа обробляє крипто-сторону: зберігання активів, конвертація, користувацький інтерфейс.

Як працює JIT Funding для крипто-карт?

Marqeta — лідируючий card issuing API, який використовують Cash App, DoorDash, Coinbase Card. Працює як program manager: ви через їхній API випускаєте карти, вони обробляють авторизації та через Just-In-Time (JIT) funding запитують у вас кошти в момент кожної транзакції. Це робить Marqeta найкращим вибором для споживчих крипто-карт — у 2 рази краще за Stripe Issuing, яке вимагає попереднього фінансування.

JIT (Just-In-Time) Funding — механізм, за якого Marqeta не тримає баланс користувача у себе. Натомість у момент кожної карткової авторизації Marqeta робить webhook-запит до вашого API, а ви відповідаєте approve/decline з сумою. Це дозволяє застосувати вашу бізнес-логіку (перевірити крипто-баланс, сконвертувати) в реальному часі.

Приклад коду JIT Funding endpoint
// Ваш JIT Funding endpoint
app.post("/marqeta/jit-funding", async (req, res) => {
  const { token, type, amount, currency_code, card_token } = req.body;
  
  const userId = await getUserByCardToken(card_token);
  const user = await getUser(userId);
  
  const cryptoAmount = await convertUSDToCrypto(amount, user.preferredAsset);
  
  const hasBalance = await reserveBalance(userId, cryptoAmount);
  
  if (!hasBalance) {
    return res.json({
      jit_funding: {
        token: token,
        method: "pgfs.authorization",
        user_token: userId,
        amount: 0,
      },
    });
  }
  
  return res.json({
    jit_funding: {
      token: token,
      method: "pgfs.authorization",
      user_token: userId,
      amount: amount,
      currency_code: "USD",
    },
  });
});
Приклад коду випуску картки через Marqeta API
import Marqeta from "@marqeta/core-api";

const marqeta = new Marqeta({
  applicationToken: process.env.MARQETA_APP_TOKEN,
  accessToken: process.env.MARQETA_ACCESS_TOKEN,
  baseUrl: "https://sandbox.marqeta.com/v3",
});

async function createMarqetaUser(userId: string, userData: UserData) {
  const marqetaUser = await marqeta.users.create({
    token: userId,
    first_name: userData.firstName,
    last_name: userData.lastName,
    email: userData.email,
    birth_date: userData.birthDate,
    address1: userData.address,
    city: userData.city,
    state: userData.state,
    country: userData.country,
    postal_code: userData.postalCode,
  });
  return marqetaUser;
}

async function issueVirtualCard(userId: string) {
  const card = await marqeta.cards.create({
    user_token: userId,
    card_product_token: process.env.CARD_PRODUCT_TOKEN,
  });
  const cardDetails = await marqeta.cards.getShowPAN(card.token);
  return {
    cardToken: card.token,
    last4: card.last_four,
    expiration: card.expiration,
    pan: cardDetails.pan,
    cvv2: cardDetails.cvv_number,
  };
}

Що краще: Marqeta чи Stripe Issuing для крипто-карт?

Stripe Issuing простіше в інтеграції, доступний у 30+ країнах. Не підтримує JIT Funding у повному обсязі — баланс має бути pre-funded на Stripe рахунку, що вимагає тримати фіатний резерв у Stripe. Це ускладнює крипто-інтеграцію. Підходить для B2B expense management карт, корпоративних карт із крипто-балансом. Не оптимальний для consumer crypto debit cards.

Marqeta підходить для consumer карт завдяки JIT Funding. Якщо ваш продукт — крипто-дебетова карта для користувачів, обирайте Marqeta. Для B2B expense management — Stripe Issuing. Marqeta з JIT Funding краще Stripe Issuing у 2 рази для споживчих карт, а Stripe Issuing інтегрується швидше (2-3 тижні проти 4-6 тижнів), але JIT Funding окупається за 6 місяців.

import Stripe from "stripe";
const stripe = new Stripe(process.env.STRIPE_SECRET_KEY!);

const card = await stripe.issuing.cards.create({
  cardholder: cardholderId,
  currency: "usd",
  type: "virtual",
  status: "active",
  spending_controls: {
    spending_limits: [{ amount: 50000, interval: "daily" }],
  },
});
Параметр Marqeta Stripe Issuing
JIT Funding Так Ні (pre-funded)
Крипто-карти Чудово підходить Обмежено (B2B)
API Потужне, гнучке Простіше, менше налаштувань
Географія Глобально 30+ країн
Вартість випуску карти ~$2 ~$3

Marqeta стягує близько $2 за випуск віртуальної картки та $0.10 за авторизацію. При обсязі 10 000 карт на місяць економія на фіатному резерві може скласти до $50 000 на рік. Вартість PCI DSS SAQ A — близько $5 000, тоді як SAQ D — $50 000.

Авторизації, settlement та курсовий ризик

Важливо розуміти різницю: Authorization — перевірка та блокування коштів, відбувається миттєво, ваш JIT endpoint має відповідати за 2-3 секунди. Clearing/Settlement — фактичне списання, відбувається через 1-3 робочих дні. Refund/Reversal — скасування транзакції, може прийти через кілька днів після authorization.

app.post("/marqeta/webhook", async (req, res) => {
  const event = req.body;
  switch (event.type) {
    case "authorization":
      await holdCrypto(event.card_token, event.amount);
      break;
    case "authorization.clearing":
      await settleTransaction(event.transaction.token, event.amount);
      break;
    case "authorization.reversal":
      await releaseHold(event.transaction.token);
      break;
    case "refund":
      await refundCrypto(event.card_token, event.amount);
      break;
  }
  res.status(200).send("OK");
});

Як управляти курсовим ризиком при JIT Funding?

При холді USD суми в крипто-еквіваленті існує ризик зміни курсу між authorization (T+0) та settlement (T+1..3). Три підходи:

  • Стейблкоїн за замовчуванням (USDC/USDT). Немає курсового ризику. Користувачі зберігають у стейблкоїнах, оплата прямолінійна. Мінус — немає крипто-апсайду.
  • Over-reservation. При авторизації резервуємо суму з буфером (+2-3%). При settlement надлишок повертається. Просте рішення для невеликих обсягів.
  • FX hedge. При авторизації фіксуємо курс через деривативи або швидкий CEX trade. Складніше, дорожче, але точніше. Потрібен для великих обсягів або волатильних активів.

PCI DSS та регуляторний шлях

Робота з номерами карт (PAN) вимагає PCI DSS сертифікації. Рівні: SAQ A — якщо не обробляєте PAN безпосередньо (Marqeta зберігає, ви тільки токени), мінімальні вимоги; SAQ D — якщо зберігаєте/обробляєте PAN, повний audit, дорого. Рекомендуємо використовувати card tokenization (Marqeta Token Vault) — ваша система оперує лише card_token, PAN ніколи не проходить через ваші сервери.

Юрисдикція Вимога Термін Особливості
EU EMI ліцензія (Lithuania) 6-12 міс Потрібна паспортизація, партнерство з емітентом
UK FCA EMI 9-18 міс Високі регуляторні вимоги
USA MTL у кожному штаті 12-24 міс Дорого, альтернатива — партнерство з bank
Singapore MAS Major Payment Institution 12-18 міс Потрібна локальна присутність

Мінімальний шлях для EU: реєстрація в Литві + паспортизація. Для решти світу — партнерство з уже ліцензованим емітентом.

Покроковий процес інтеграції крипто-карти

  1. Аналітика та вибір провайдера: оцінка обсягів, вибір Marqeta або Stripe Issuing.
  2. Проектування архітектури: JIT Funding, схема конвертації, зберігання ключів.
  3. Інтеграція API: випуск карт, вебхуки, 3DS.
  4. Підключення крипто-custody: гаманець, конвертація, резервування.
  5. KYC/AML: інтеграція з сервісами верифікації.
  6. Тестування: сценарії авторизації, settlement, refund.
  7. Комплаєнс: PCI DSS, ліцензування.

Що входить в інтеграцію під ключ?

  • Консультація щодо вибору card issuing провайдера (Marqeta/Stripe Issuing)
  • Налаштування JIT Funding endpoint з перевіркою крипто-балансу
  • Інтеграція API випуску віртуальних та фізичних карт
  • Впровадження 3D Secure (3DS) для захисту транзакцій
  • Інтеграція KYC/AML завантаження документів
  • Допомога з PCI DSS: рекомендації щодо токенізації, проходження SAQ
  • Навантажувальне тестування та моніторинг
  • Документація та навчання команди

Терміни та орієнтовна вартість

  • Marqeta інтеграція (JIT + card issuance + webhooks): 4-6 тижнів
  • 3DS інтеграція: +2-3 тижні
  • Crypto custody + конвертація: паралельно, 4-8 тижнів
  • KYC/AML: 2-4 тижні
  • Mobile app: 8-12 тижнів
  • Compliance + тестування: 4-6 тижнів
  • Разом (технічно): 5-7 місяців

Інвестиції в інтеграцію — від $50 000 до $200 000 залежно від складності стеку та обсягів. Економія на інфраструктурі за рахунок JIT Funding — до 40% порівняно з власним фіатним резервом.

Отримайте консультацію щодо вашого проєкту — оцінимо архітектуру та терміни за 1-2 дні.

Ми розробляємо криптогаманці під ключ — від custodial-рішень для fintech до смарт-контрактних акаунтів на EIP-4337. 5+ років на ринку блокчейн-розробки, 40+ реалізованих проектів. Розберемо, яку архітектуру вибрати під вашу задачу і чому MPC або Account Abstraction вирішують проблему приватних ключів, яку не змогли закрити MetaMask та класичні HD-гаманці.

Як обрати архітектуру гаманця?

Чому класичні гаманці небезпечні для бізнесу?

Seed-фраза у браузерному розширенні — єдиний спосіб відновити доступ. Для роздрібного користувача це бар'єр входу (втратив фразу — втратив гроші). Для корпоративного казначейства — несумісно з compliance (KYC/AML, рольова модель, мультипідпис). Будь-який витік одного ключа компрометує всі кошти. Ці ризики закладені в архітектуру, а не в поганий UX.

Ми усуваємо їх на рівні протоколу: MPC-гаманці (ключ ніколи не зібраний цілком), смарт-контрактні гаманці (логіка авторизації в коді), апаратні HSM для інституційного зберігання. Нижче — деталі.

Custodial vs Non-custodial: у чому реальна різниця

Custodial — провайдер зберігає приватний ключ. Користувач аутентифікується через email/password/OAuth. Відновлення тривіальне, KYC/AML вбудовані. Для централізованих додатків з фінансовими операціями — часто єдиний регуляторно прийнятний варіант. Ризик: single point of failure (злом Bitfinex — значні втрати, FTX — понад значну суму клієнтських коштів).

Non-custodial — ключі у користувача. Провайдер не має доступу до коштів. Відповідальність за зберігання лягає на користувача. Для 99% людей це непрацююча модель без додаткового захисту — тут і приходить MPC.

MPC-гаманці: ключ, якого немає

Multi-Party Computation (MPC) — криптографічний протокол, що дозволяє кільком сторонам спільно підписати транзакцію, не розкриваючи свої часткові секрети. Приватний ключ ніколи не існує в зібраному вигляді.

Стандартна схема: 2-of-3 MPC між користувачем (частка на пристрої), сервером провайдера та резервним хмарним сховищем. Транзакція підписується двома будь-якими з трьох сторін. Телефон втрачено — відновлення через сервер + хмару. Сервер скомпрометовано — атакуючий володіє лише однією часткою, підпис неможливий.

TSS (Threshold Signature Scheme) — конкретна реалізація MPC для ECDSA/EdDSA. Алгоритми: GG18, GG20, CGGMP21 (останній швидший і з кращими security proof). Бібліотеки: tss-lib (Go, від Binance), multi-party-sig (Go, від Coinbase), ZenGo-X/multi-party-ecdsa (Rust).

MPC не потребує on-chain змін — для блокчейна підпис виглядає як звичайний single-key підпис. Це дає економію gas та зберігає конфіденційність схеми управління ключами (не публікується в ланцюжку) — на відміну від мультисига.

Account Abstraction (EIP-4337): смарт-контракт як гаманець

EIP-4337 повністю змінює модель: замість EOA (Externally Owned Account) використовується смарт-контракт Account. Логіка авторизації — в коді контракту, а не в криптографії протоколу. Це відкриває довільну логіку підпису, соціальне відновлення, сесійні ключі, sponsored транзакції та батчинг операцій.

User → UserOperation → Bundler → EntryPoint contract → Account contract
                                          ↑
                                    Paymaster (optional, pays gas)

UserOperation — новий тип об'єкта (не L1-транзакція). Bundler збирає UserOps з альтернативного mempool, упаковує в одну транзакцію та відправляє в EntryPoint. EntryPoint викликає validateUserOp на Account контракті — Account сам вирішує, чи дійсний підпис.

Практичні можливості:

Соціальне відновлення. Контракт зберігає список guardian'ів (інші адреси або сервіс). Втрата ключа — guardians голосують за заміну. Argent використовує схему з 2020 року.

Сесійні ключі. Тимчасовий ключ з обмеженими правами: взаємодія лише з конкретним контрактом, до певної дати, до певної суми. Для GameFi та dApps — користувач не підписує кожну мікро-транзакцію.

Paymaster. Сторонній контракт платить газ за користувача. Паттерн для онбордингу: користувач не тримає ETH, газ спонсорує dApp або береться з ERC-20 токенів.

Реалізації: Safe{Core} Protocol, Biconomy SDK (Stackup), ZeroDev (Kernel), Alchemy (Rundler bundler). На Ethereum mainnet, Polygon, Arbitrum, Optimism EntryPoint v0.6/v0.7 задеплоєний та активний. Гарантуємо сумісність з останніми версіями контрактів.

Hardware Security Module для корпоративних гаманців

Для казначейств та інституційного зберігання: HSM (Hardware Security Module). Ключ генерується і ніколи не покидає захищений чип. Підпис — всередині HSM. Підтримується апаратна атестація. Використовувані рішення: AWS CloudHSM, Azure Dedicated HSM, Thales Luna, YubiHSM 2 (для невеликих обсягів). Інтеграція через PKCS#11 або cloud-specific API.

Комбінація HSM + MPC — оптимальна для інституційного використання: ключові частки зберігаються в HSM на різних серверах/юрисдикціях, підпис через TSS. Це забезпечує відповідність регуляторним вимогам (наприклад, для крипто-кастодіанів).

Інтеграція з dApps: WalletConnect та стандарти

Будь-який гаманець повинен вміти взаємодіяти з dApps. Стандарт — WalletConnect v2 (Sign API): QR-код або deep link, peer-to-peer зашифрований канал через relay сервер. Для браузерних розширень — EIP-1193 (Ethereum Provider API).

На фронтенді використовуємо wagmi + viem — один інтерфейс для MetaMask, WalletConnect, Coinbase Wallet, injected providers. Для Account Abstraction — EIP-5792 (wallet capabilities) та EIP-7677 (paymaster service).

Процес розробки

  1. Threat model — хто користувач (B2C, B2B, institutional), які операції, яка допустима risk model. Від цього залежить архітектура.
  2. Вибір та проектування схеми зберігання ключів — MPC, HSM, мультисиг або їх комбінація.
  3. Розробка Account контракту (якщо EIP-4337) або інтеграція MPC-бібліотеки.
  4. Backend — MPC-координація, управління сесіями, paymaster-сервіс (якщо потрібен).
  5. Мобільний/браузерний застосунок — UI з інтеграцією WalletConnect, біометрії, QR.
  6. Інтеграція з dApps — EIP-1193, WalletConnect v2.
  7. Аудит контрактів та криптографічних реалізацій — обов'язковий етап. MPC-бібліотеки мають відомі вразливості (GG18 піддається атаці при malicious participant без abort protocol). Використовуємо бібліотеки з актуальними security review (CGGMP21). Досвід проходження аудитів у Certik, Hacken, Trail of Bits — підтверджуємо сертифікатами.

Що входить в роботу (deliverables)

  • Вихідні коди смарт-контрактів (Solidity/Rust) з документацією
  • Backend-сервіс MPC-координації (на Go або Rust) з API
  • Мобільний застосунок (iOS/Android) або браузерне розширення
  • Інтеграція з WalletConnect, Ledger/Trezor (за потреби)
  • Підготовка до аудиту безпеки (звіт зі списком вразливостей)
  • Документація адміністратора та користувача
  • Доступ до репозиторію, CI/CD, моніторинг (Tenderly, Etherscan API)
  • Навчання вашої команди (2-3 сесії)
  • Підтримка після запуску — 1 місяць

Строки та вартість

Тип рішення Строки (робочі тижні)
Custodial з базовим UI 4–8
Non-custodial з MPC-інтеграцією 8–16
EIP-4337 Account з paymaster 6–12
Institutional (HSM + MPC + compliance) від 16

Вартість розраховується індивідуально під ваш проект. Оцінимо за 1 день — зв'яжіться з нами. Надаємо гарантію на код та timeline.

Типові помилки при розробці криптогаманців (і як їх уникнути)

  • Використання застарілих MPC-бібліотек — GG18 без abort protocol. Обираємо CGGMP21 або tss-lib з актуальними audit report.
  • Жорстка прив'язка до одного блокчейну — не закладають абстракцію під L2/сайдчейни. Використовуємо viem/wagmi для кросс-чейн.
  • Ігнорування MEV-атак — при використанні мультисига без таймлоків. Додаємо tx simulation (Tenderly) та sandwitching protection.
  • Відсутність fallback-механізму відновлення — для Account Abstraction не налаштовують social recovery. Закладаємо з першого релізу.

Усуваємо ці граблі на етапі проектування — під кожен проект складаємо threat model та security checklist.

Потрібен надійний гаманець без компромісів? Отримайте консультацію нашого архітектора — розберемо вашу задачу та запропонуємо архітектуру з точним кошторисом. Залишайте заявку — відповімо протягом дня.