Integration Guide for Banks
[UKR] Посібник з інтеграції для банку
[UKR] Посібник з інтеграції для банку
  • General
    • 💰Загальний опис
      • Перекази між цифровізованими сутностями
        • Варіант 1. Швидке створення/видалення ідентифікаторів
        • Варіант 2. Стандартне створення/видалення ідентифікаторів (опціонально)
      • Історія версій
      • Журнал змін API
      • Глосарій
    • 🌐Загальні вимоги
    • 👉Базовий варіант впровадження
    • 📅План інтеграції
      • План інтеграції (Бізнес)
      • План інтеграції (Технічна команда)
      • Мультипідпис
    • ❗Повідомлення про помилки
  • 🛠️API МЕТОДИ
    • Автентифікація
      • Авторизація через JWT
      • Служба Аутентифікації Банку
      • JWT формат
    • Працівники
      • Призначити роль працівнику
      • Управління ролями
    • Клієнти
      • Сегмент
    • Цифровізовані сутності
    • Ідентифікатори
    • Трансфер (перерозподілення ідентифікаторів)
      • Мультипідпис для трансферів
      • Зворотні виклики
      • Категорія
    • Ліміти
    • Реконсиляція
    • [необов’язково] Відділення
      • Відділення (доступ)
      • Як додати працівника до віддлення (філії)
      • Фільтр по відділенню
      • Трансфери (Відділення)
Powered by GitBook
On this page
  • Ключові принципи
  • Підтвердити оплату мультипідписом
  • POST /sign
  • Створення Клієнта з мультипідписом
  1. API МЕТОДИ
  2. Трансфер (перерозподілення ідентифікаторів)

Мультипідпис для трансферів

PreviousТрансфер (перерозподілення ідентифікаторів)NextЗворотні виклики

Last updated 1 year ago

За замовчуванням лише ключ користувача підписує транзакції в Прозорій Мережі Stellar.

Як варіант, з метою зниження ризику таємної підробки транзакція також може бути підписана кількома учасниками.

Цей потік поєднує підписи з двох сторін (Контрагента та DCM):

Ключові принципи

  1. Контрагент з самого початку вирішує, який підхід використовувати (мультипідпис або використовувати за замовчуванням з єдиним підписом)

    • Контрагент генерує 2 пари ключів і надає публічні частини в DCM перед ініціюванням операції

  2. Для публікації транзакції потрібні 3 підписи (Контрагент, DCM і Клієнт)

  3. Початкове значення Клієнта зашифровано на стороні DCM

  4. Секрет (зберігається Контрагентом) потрібен для розшифровки початкового коду Клієнта

  5. Контрагент використовує власне початкове значення для підписання транзакції.

Підтвердити оплату мультипідписом

На кроках 4, 5 і 9 усі три підписи додаються до конверта транзакції.

POST /sign

Приклад запиту

Аутентифікація не використовується

{
"address":[
    "GALY4D4HZ6XMC2YI5FOWXZ3JKMEOYPWZPADPXBC7ZA232SSEEUCGAR5X"    
    ],
"transaction_xdr":"AAAAAgAAAAAOc/Ep0SpnfQ9wyROTSWSDI5dnsJpSL15kDAmaTEqyIwAAAMgAExmIAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAQAAAAC9uikHe+PC/4jPg01zIk3O7mOC0oFATGCEC3VG3Sz8BAAAAAFlVUFIAAAAAL26KQd748L/iM+DTXMiTc7uY4LSgUBMYIQLdUbdLPwEAAAAAAABhqAAAAAAAAAACgAAAAxwYXltZW50X2d1aWQAAAABAAAAJGRiNzhjNzVjLTFhNTAtMTFlZS1iZDVmLTNhNmFhNDQzNmZlZQAAAAAAAAAA"
}
Decoded example:
v1
  tx
    sourceAccount: [keyTypeEd25519]
      ed25519: GAHHH4JJ2EVGO7IPODERHE2JMSBSHF3HWCNFEL26MQGATGSMJKZCGJYJ
    fee: 200
    seqNum: 5376096463749122
    cond: [precondTime]
      timeBounds
        minTime: 0
        maxTime: 0
    operations: Array[2]
      [0]
        sourceAccount: none
        body: [payment]
          paymentOp
            destination: [keyTypeEd25519]
              ed25519: GC63UKIHPPR4F74IZ6BU24ZCJXHO4Y4C2KAUATDAQQFXKRW5FT6AJKYS
            asset: [assetTypeNative]
              alphaNum4
                assetCode: UAH
                issuer: [publicKeyTypeEd25519]
                  ed25519: GC63UKIHPPR4F74IZ6BU24ZCJXHO4Y4C2KAUATDAQQFXKRW5FT6AJKYS
              amount: 0.00001 (raw: 100)
      [1]
        sourceAccount: none
        body: [manageData]
          manageDataOp
            dataName: payment_guid [hex: ZXh0ZXJuYWxfcGF5bWVudF9ndWlk]
            dataValue: db78c75c-1a50-11ee-bd5f-3a6aa4436fee [hex: ZGI3OGM3NWMtMWE1MC0xMWVlLWJkNWYtM2E2YWE0NDM2ZmVl]
    ext: [undefined]
  signatures: Array[1] Signatures checked!
    [0]
      hint: G______________________________________________MJKZC____
      signature: C26wsxgT6q/Pdelp7wEXYfZJUZxfU24yyK7nomVPRMEZ/bUELq1fzL4A7OEjSPeBzzekG+R+Oc9lteZKA0OuAQ== 

Приклад відповіді

{
"address": [
    "GALY4D4HZ6XMC2YI5FOWXZ3JKMEOYPWZPADPXBC7ZA232SSEEUCGAR5X"
    ],
"transaction_xdr": "AAAAAgAAAAAOc/Ep0SpnfQ9wyROTSWSDI5dnsJpSL15kDAmaTEqyIwAAAMgAExmIAAAAAgAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAQAAABB0ZXN0IG1hbmFnZV9kYXRhAAAAAgAAAAAAAAABAAAAAL26KQd748L/iM+DTXMiTc7uY4LSgUBMYIQLdUbdLPwEAAAAAAAAAAAAAABkAAAAAAAAAAoAAAAVZXh0ZXJuYWxfcGF5bWVudF9ndWlkAAAAAAAAAQAAACRkYjc4Yzc1Yy0xYTUwLTExZWUtYmQ1Zi0zYTZhYTQ0MzZmZWUAAAAAAAAAAUxKsiMAAABAC26wsxgT6q/Pdelp7wEXYfZJUZxfU24yyK7nomVPRMEZ/bUELq1fzL4A7OEjSPeBzzekG+R+Oc9lteZKA0OuAQ=="
}

У відповіді обов'язкові обидва атрибути: адреса та підпис на конверті. У транзакції_xdr потрібен принаймні 1 підпис.

Stellar SDK для роботи з підписами:

Очікувані помилки

  1. 400 Bad request: якщо конверт має неправильну форму

    • трансфер припинено

  2. 401 Unauthorized: жодна з адрес з запиту недоступна для підпису

    • трансфер припинено

  3. 404 Not found: у випадку, якщо відповідь від GET /payments не повертає результатів.

    • повторна спроба буде надіслана пізніше до POST /sign (до 5 повторів)

Створення Клієнта з мультипідписом

Щоб обліковий запис клієнта мав 3 підписантів, процес створення Клієнта змінюється кроком 9, коли попередньо налаштований набір відкритих ключів приписується адресі Stellar як підписантом.

Що стосується інтеграції з API, створення відбувається як зазвичай.

Адреса атрибута містить список усіх очікуваних підписантів для платежу. Конверт із tranasction_xdr для цілей тестування можна розшифрувати вручну за допомогою .

Блок «manageDataOp» містить атрибут payment_guid, який слід використовувати в методі щоб отримати реквізити трансферу.

🛠️
Stellar.Laboratory
Генерація ключів
Підписати угоду
Трансфер (перерозподілення ідентифікаторів)
Default flow with a single signer
Relations between private keys and secrets
Confirm a payment
Create a customer