Гаманець фінансування

Цей посібник призначений для Agent Java SDK v0.3.0, Java 8+ і публічного контракту з тегами. Приклади виконуються в серверній частині партнера після ініціалізації client у Швидкий старт.

Приклад передумов

Фрагменти Java поділяють ці імпортовані файли. Ініціалізуйте client за допомогою швидкого запуску та отримайте platformUserId із збереженого зв’язування. Приклади ідентифікаторів користувача/замовлення потрібно замінити вашими постійними значеннями.

import com.sixmm.agent.*;
import com.sixmm.agent.model.*;
import java.util.*;

Запити та перекази гаманця

Розрізняють три гаманці

queryAccount Запитуйте маржинальний рахунок платформи торговця, а не гаманець користувача торговця. Цей інтерфейс не має параметрів environment і не може запитуватися як імітований актив користувача.

Запит двох гаманців платформи імітованих користувачів:

QueryUserAssetsResponse assets = client.queryUserAssets(
        QueryUserAssetsRequest.of(platformUserId)
                .withFunding()
                .withEnvironment(ExecutionEnvironment.SIMULATED));

Інтерфейс: POST /v1/agent/query-user-assets. Фінансування запитується лише тоді, коли includeFunding=true; за замовчуванням використовується оригінальна семантика запиту активу контракту.

Суми обробляються як рядки або BigDecimal, а не float/double.

Напрямки перерахування коштів

Створити: POST /v1/agent/wallet-transfer, SDK walletTransfer.

Поточна валюта підтримує лише USDT. Фіксована сума має бути позитивним рядком із 8 знаками після коми та не може використовувати наукову нотацію. Коли transferAll=true, пропустіть amount і запишіть його як остаточну відповідь amount; “усі” включає лише кошти, які можна вивести.

Приклад: Продавець переказує 10 USDT на імітаційне фінансування. Спочатку збережіть бізнес-замовлення та середовище в системі продавця, а потім надішліть запит:

String fundingOrderNo = "SIM-FUNDING-20261010-000001";
WalletTransferResponse transfer = client.walletTransfer(
        WalletTransferRequest.of(fundingOrderNo, "merchant-user-001",
                "PARTNER_TO_FUNDING", "10.00000000", false)
                .withEnvironment(ExecutionEnvironment.SIMULATED));

Переказ фінансування: усі кошти, які можна перерахувати в імітований контракт:

WalletTransferResponse move = client.walletTransfer(
        WalletTransferRequest.of("SIM-F2C-20261010-000001", "merchant-user-001",
                "FUNDING_TO_CONTRACT", null, true)
                .withEnvironment(ExecutionEnvironment.SIMULATED));

Ця сама операція повинна продовжувати використовувати оригінальний agentOrderNo; різні операції та різні середовища використовують різні номери замовлення. Зміна суми, користувача, напрямку або середовища з тим самим номером замовлення буде відхилена. Перекази фінансування/контрактів можна виконувати лише в тому самому середовищі, а змодельовані кошти не можна перевести в реальні кошти.

Підтвердження результату та відновлення невідомого результату

Відповіді про фінансування позначаються status, SUCCESS, PROCESSING або FAILED і повертаються orderNo, direction, currency, amount, resultCode тощо. code=0 лише означає, що запит успішно оброблено, і вам потрібно продовжувати оцінювати status.

Запит на фінансування використовує спеціальний інтерфейс POST /v1/agent/wallet-transfer-status:

WalletTransferResponse recovered = client.queryWalletTransfer(
        WalletTransferQueryRequest.of(fundingOrderNo)
                .withEnvironment(ExecutionEnvironment.SIMULATED));

Використовуйте цю виділену кінцеву точку, щоб відновити початкову операцію фінансування; queryOrder не може замінити його. Збережіть оригінальне середовище та передайте його явно під час відновлення. Якщо environment пропущено в wallet-transfer-status, сервер використовує середовище, збережене в оригінальному замовленні, включаючи змодельовані замовлення. Явно конфліктне середовище повертає 102002 (order environment mismatch). Коли абонент пропускає середовище, відповідь також пропускає environment; це не означає, що вихідне замовлення є виробничим замовленням.

Місцеві депозити та зняття коштів торговців є ідемпотентними; постійні замовлення та баланси резервуються перед ініціацією та резервуються для підтвердження, коли результат невідомий. Доступ до фінансування використовує спеціальний запит для підтвердження остаточного статусу; не припускайте, що старі методи передачі контракту Webhook або сторнування автоматично застосовуються до фінансування.

Існуючий потік передачі контракту

Початкові transfer, transferAllOut, reverse, queryOrder, listOrders продовжують обробляти початковий процес передачі контракту. queryOrder запитує замовлення на переказ коштів, listOrders — це список узгодження переказів; замість цього, Вічні запити використовуються для безстрокових торгових ордерів.

У вихідній відповіді про фінансування використовується orderStatus; у відповіді на фінансування використовується status, не змішуйте їх. Оригінальна передача Webhook перевіряється за допомогою X-Agent-Timestamp, X-Agent-Nonce, X-Agent-Signature, а оригінальний текст підпису — timestamp + nonce + rawBody; початкове тіло запиту спочатку перевіряється, потім десеріалізується та стає ідемпотентним. Явні сповіщення про змодельоване середовище містять environment=SIMULATED, сповіщення про виробництво залишаються сумісними зі старими полями. Суму, номер замовлення, статус і середовище потрібно перевірити в місцевому бізнес-замовленні.

Джерело та відповідні посібники

• Офіційне джерело v0.3.0
• Огляд запиту та розбивка на сторінки
• Посібник з оновлення

Поля запиту на фінансування

Поля відповіді щодо фінансування