Portfel finansowania

Ten przewodnik jest przeznaczony dla Agent Java SDK v0.3.0, Java 8+ i oznaczonych zamówień publicznych. Przykłady działają w zapleczu partnera po inicjalizacji client w Szybki start.

Przykładowe wymagania wstępne

Fragmenty Java dzielą ten import. Zainicjuj client za pomocą Szybki start i uzyskaj platformUserId z zapisanego powiązania. Przykładowe identyfikatory użytkowników/zamówień należy zastąpić własnymi, utrwalonymi wartościami.

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

Zapytania i przelewy w portfelu

Rozróżnij trzy portfele

queryAccount Zapytaj o konto depozytu zabezpieczającego platformy sprzedawcy, a nie o portfel użytkownika sprzedawcy. Ten interfejs nie ma parametrów environment i nie można go sprawdzać jako symulowanego zasobu użytkownika.

Zapytaj dwa portfele platformy symulowanych użytkowników:

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

Interfejs: POST /v1/agent/query-user-assets. O finansowanie wnioskuje się tylko wtedy, gdy includeFunding=true; Domyślnie używana jest semantyka zapytań o zasobach kontraktu.

Kwoty są obsługiwane jako ciągi znaków lub BigDecimal, a nie float/double.

Kierunki transferu środków

Utwórz: POST /v1/agent/wallet-transfer, SDK walletTransfer.

Obecna waluta obsługuje tylko USDT. Stała kwota musi być ciągiem dodatnim z maksymalnie 8 miejscami po przecinku i nie może być stosowana w notacji naukowej. Kiedy transferAll=true, pomiń amount i zapisz to jako ostateczną odpowiedź amount; „wszystko” obejmuje tylko środki do wypłaty.

Przykład: Sprzedawca przekazuje 10 USDT na symulowane finansowanie. Najpierw zapisz zamówienie biznesowe i środowisko w systemie sprzedawcy, a następnie wyślij żądanie:

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));

Transfer środków wszystkie środki, które można przelać na symulowany kontrakt:

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

Ta sama operacja musi nadal korzystać z oryginału agentOrderNo; różne operacje i różne środowiska używają różnych numerów porządkowych. Zmiana ilości, użytkownika, kierunku lub środowiska o tym samym numerze zamówienia zostanie odrzucona. Transfer środków/umów może odbywać się wyłącznie w tym samym środowisku, a środków symulowanych nie można przenieść na środki rzeczywiste.

Potwierdzenie wyniku i odzyskanie nieznanego wyniku

Odpowiedzi na finansowanie są reprezentowane przez status, SUCCESS, PROCESSING lub FAILED i są zwracane orderNo, direction, currency, amount, resultCode itd. code=0 oznacza jedynie, że żądanie zostało pomyślnie przetworzone i należy kontynuować ocenę status.

Zapytanie o finansowanie wykorzystuje dedykowany interfejs POST /v1/agent/wallet-transfer-status:

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

Użyj tego dedykowanego punktu końcowego, aby odzyskać pierwotną operację finansowania; queryOrder nie może go zastąpić. Zapisz oryginalne środowisko i przekaż je jawnie podczas odzyskiwania. Jeżeli w wallet-transfer-status pominięto environment, serwer korzysta ze środowiska zapisanego na pierwotnym zamówieniu, w tym także na zamówieniach symulowanych. Środowisko jawnie sprzeczne zwraca 102002 (order environment mismatch). Kiedy osoba wywołująca pomija otoczenie, odpowiedź pomija także environment; nie oznacza to, że oryginalne zamówienie jest zleceniem produkcyjnym.

Lokalne wpłaty i wypłaty sprzedawców są idempotentne; stałe zlecenia i salda są rezerwowane przed rozpoczęciem i są rezerwowane do potwierdzenia, gdy wynik jest nieznany. Dostęp do finansowania wykorzystuje dedykowane zapytanie w celu potwierdzenia ostatecznego statusu; nie zakładaj, że stare metody przeniesienia umowy Webhook lub odwrócenia umowy mają automatyczne zastosowanie do Finansowania.

Istniejący przepływ przeniesienia kontraktu

Oryginały transfer, transferAllOut, reverse, queryOrder, listOrders kontynuują proces pierwotnego przeniesienia umowy. queryOrder sprawdza zlecenia przelewu środków, listOrders jest listą uzgodnień przelewów; Zamiast, Ciągłe zapytania wykorzystywane są do zleceń w obrocie wieczystym.

Oryginalna odpowiedź na finansowanie wykorzystuje orderStatus; odpowiedź Funding wykorzystuje status, nie mieszaj ich. Oryginalny przelew Webhook jest weryfikowany za pomocą X-Agent-Timestamp, X-Agent-Nonce, X-Agent-Signature, a oryginalna treść podpisu to timestamp + nonce + rawBody; pierwotna treść żądania jest najpierw weryfikowana, następnie deserializowana i idempotentna. Jawne powiadomienia o symulowanym środowisku zawierają environment=SIMULATED, powiadomienia produkcyjne pozostają zgodne ze starymi polami. Kwotę, numer zamówienia, status i środowisko należy sprawdzić w lokalnym zamówieniu biznesowym.

Źródło i powiązane przewodniki

• Oficjalne źródło v0.3.0
• Przegląd zapytań i paginacja
• Przewodnik po aktualizacji

Pola żądania finansowania

Pola odpowiedzi na finansowanie