Monedero de financiación
Funding Wallet: Agent Java SDK integración v0.3.0, ejemplos, parámetros y semántica de respuesta.
Esta guía está dirigida a Agent Java SDK v0.3.0, Java 8+ y el contrato público etiquetado. Los ejemplos se ejecutan en un backend asociado después de inicializar client en Inicio rápido.
Requisitos previos de ejemplo
Los fragmentos Java comparten estas importaciones. Inicialice client usando el Inicio rápido y obtenga platformUserId del enlace guardado. Los ID de usuario/pedido de ejemplo deben reemplazarse con sus propios valores persistentes.
Consultas y transferencias de Wallet
Distinguir las tres carteras.
queryAccount Consulta la cuenta de margen de la plataforma comercial, no la billetera del usuario comerciante. Esta interfaz no tiene environment parámetros y no se puede consultar como un activo de usuario simulado.
Consulta las dos billeteras de plataforma de usuarios simulados:
Interfaz: POST /v1/agent/query-user-assets. Se solicita financiación únicamente cuando includeFunding=true; La semántica de consulta de activos del contrato original se utiliza de forma predeterminada.
Las cantidades se manejan como cadenas o BigDecimal, no float/double.
Direcciones de transferencia de fondos
Crear: POST /v1/agent/wallet-transfer, SDK walletTransfer.
La moneda actual solo admite USDT. La cantidad fija debe ser una cadena positiva con hasta 8 decimales y no puede utilizar notación científica. Cuando transferAll=true, omita amount y regístrelo como la respuesta final amount; “todos” solo incluye los fondos retirables.
Ejemplo: El comerciante transfiere 10 USDT a una financiación simulada. Primero guarde el pedido comercial y el entorno en el sistema comercial y luego envíe la solicitud:
Financiamiento Transfiera todos los fondos que se puedan transferir al Contrato simulado:
La misma operación debe continuar usando el agentOrderNo original; diferentes operaciones y diferentes entornos utilizan diferentes números de pedido. Se rechazará el cambio de importe, usuario, dirección o entorno con el mismo número de pedido. Las transferencias de fondos/contratos solo se pueden realizar dentro del mismo entorno y los fondos simulados no se pueden transferir a fondos reales.
Confirmación de resultados y recuperación de resultados desconocidos
Las respuestas de financiación están representadas por status, SUCCESS, PROCESSING o FAILED, y se devuelven orderNo, direction, currency, amount, resultCode, etc. code=0 solo significa que la solicitud se procesó exitosamente y debes continuar juzgando status.
La consulta de financiación utiliza la interfaz dedicada POST /v1/agent/wallet-transfer-status:
Utilice este punto final dedicado para recuperar la operación de financiación original; queryOrder no puede reemplazarlo. Guarde el entorno original y páselo explícitamente durante la recuperación. Si se omite environment de wallet-transfer-status, el servidor utiliza el entorno guardado en el pedido original, incluidos los pedidos simulados. Un entorno explícitamente en conflicto devuelve 102002 (order environment mismatch). Cuando la persona que llama omite el entorno, la respuesta omite environment también; Esto no significa que el pedido original sea un pedido de producción.
Los depósitos y retiros locales de los comerciantes son idempotentes; Las órdenes y saldos persistentes se reservan antes del inicio y se reservan para confirmación cuando se desconoce el resultado. El acceso a la financiación utiliza una consulta dedicada para confirmar el estado final; No asuma que la transferencia del contrato anterior Webhook o los métodos de reversión sean automáticamente aplicables a la Financiación.
Flujo de transferencia de contrato existente
Los transfer, transferAllOut, reverse, queryOrder, listOrders originales continúan procesando el proceso de transferencia del contrato original. queryOrder está consultando órdenes de transferencia de fondos, listOrders es una lista de conciliación de transferencias; en cambio, Consultas perpetuas se utilizan para órdenes comerciales perpetuas.
La respuesta de financiación original utiliza orderStatus; la respuesta de financiación utiliza status, no los mezcle. La transferencia original Webhook se verifica usando X-Agent-Timestamp, X-Agent-Nonce, X-Agent-Signature, y el texto de la firma original es timestamp + nonce + rawBody; el cuerpo de la solicitud original primero se verifica, luego se deserializa y se vuelve idempotente. Las notificaciones explícitas del entorno simulado contienen environment=SIMULATED, las notificaciones de producción siguen siendo compatibles con los campos antiguos. La cantidad, el número de pedido, el estado y el entorno deben verificarse con el pedido comercial local.