Integrar
Uno de los principales puntos de interacción con la Anchor Platform es notificar a la Plataforma sobre eventos relacionados con las transacciones.
En general, querrás proporcionar actualizaciones para los siguientes eventos.
- Tu negocio requiere que el usuario envíe información KYC para procesar una transacción
- Tu negocio actualizó los montos de entrada/salida/tasa para una transacción
- Tu negocio está listo para recibir fondos del usuario
- Tu negocio ha recibido fondos del usuario
- Tu negocio ha enviado fondos al usuario
- Tu negocio ha procesado un reembolso para la transacción del usuario
- Tu negocio experimentó un error inesperado
Esto se realiza haciendo solicitudes JSON-RPC al endpoint de la API de la Plataforma. Las solicitudes JSON-RPC permiten actualizar el estado de la transacción. Para mover la transacción a un estado específico, es necesario hacer una solicitud JSON-RPC correspondiente y pasar los datos que requiere el método RPC.
La API JSON-RPC de la Anchor Platform está diseñada para notificar a la plataforma sobre cambios en el estado de la transacción. Dado esto, la API se llamará cada vez que un usuario o el ancla realicen alguna acción que avance el estado de la transacción en el flujo.
La comunicación desde la Anchor Platform sobre actualizaciones de transacciones, actualizaciones de clientes y creación de cotizaciones se maneja a través del servicio de eventos. Esta es una función opcional que necesita ser configurada por separado de la integración SEP-6. Para más información, consulta Manejo de Eventos.
Puedes encontrar más sobre el flujo y los estados de las transacciones en el documento del protocolo SEP-6.
Callbacks
La Anchor Platform se basa en el servidor comercial para proporcionar y almacenar información sobre los clientes y las cotizaciones.
Información del Cliente
La Anchor Platform no almacena información del cliente. En su lugar, reenvía todas las solicitudes de clientes SEP-12 al servidor comercial. El servidor comercial es responsable de almacenar y gestionar esta información. Por lo tanto, tu servidor comercial debe implementar las API de cliente para manejar actualizaciones KYC.
Cotizaciones y Tarifas
Para admitir el exchange de activos no equivalentes, la Anchor Platform expone una API compatible con SEP-38 para proporcionar cotizaciones para el exchange. La API de cotizaciones se utiliza para proporcionar al usuario la cantidad esperada del activo que recibirá a cambio del activo que está enviando. La API de cotizaciones también se utiliza para proporcionar al usuario las tarifas esperadas para la transacción. Por lo tanto, tu servidor comercial debe implementar la API de tasas para proporcionar cotizaciones a la Anchor Platform.
Asegurando la API de la Plataforma
Por defecto, los endpoints de la API de la Plataforma como GET /transactions
y GET /transactions/:id
no están protegidos y son accesibles por cualquier persona que tenga acceso al servidor, incluidas las aplicaciones de billeteras.
Se recomienda mantener el servidor de la Plataforma accesible solo desde la red privada. Sin embargo, es posible que desees añadir una capa adicional de protección mediante la seguridad de la API.
Usando la Clave API
Para habilitar la autenticación mediante clave de API, modifica tu archivo dev.env
:
- bash
# dev.env
PLATFORM_SERVER_AUTH_TYPE=api_key
# Will be used as API key
SECRET_PLATFORM_API_AUTH_SECRET="your API key that business server will use"
Una vez habilitado, todas las solicitudes deben incluir un encabezado válido X-Api-Key
, establecido en la clave de API configurada.
Usando JWT
Para habilitar la autenticación JWT, modifica tu archivo dev.env
:
- bash
# dev.env
PLATFORM_SERVER_AUTH_TYPE=jwt
# Will be used to sign the JWT token
SECRET_PLATFORM_API_AUTH_SECRET="your secret that business server will use"
Anchor Platform utiliza el algoritmo HMAC SHA-256 (HS256) para firmar los tokens JWT. Asegúrate de que SECRET_PLATFORM_API_AUTH_SECRET
tenga al menos 32 caracteres de longitud por seguridad.
Una vez habilitado, todas las solicitudes deben incluir un encabezado Authorization
válido con el formato Bearer <JWT token>
.
Realizando Solicitudes JSON-RPC
Antes de hacer solicitudes JSON-RPC, primero vamos a crear una plantilla para hacer una solicitud a la Anchor Platform.
- bash
# call-json-rpc.sh
#!/usr/bin/env bash
curl localhost:8085 \
-X POST \
-H 'Content-Type: application/json' \
--data "@$1"
Este pequeño script hará una solicitud JSON-RPC a la Anchor Platform alojada en el puerto predeterminado (8085). Los datos de transacción JSON almacenados en el archivo proporcionado se usarán como cuerpo (las solicitudes deben ser un array).
Solicitud JSON-RPC
El objeto Request debe contener los siguientes atributos:
ATRIBUTOTIPO DE DATO
DESCRIPCIÓN
jsonrpccadena
Una cadena que especifica la versión del protocolo JSON-RPC. DEBE ser exactamente "2.0"
métodocadena
Una cadena que contiene el nombre del método a invocar. La lista de métodos disponibles la puedes ver en [Métodos JSON-RPC][json-rpc-methods]
paramsobjeto
Un valor estructurado que contiene los valores de parámetro, correspondientes a la llamada al método, que se utilizarán durante la invocación del método
idcadena
Un identificador establecido por el cliente. El servidor responderá con el mismo valor en el objeto Response
Es posible proporcionar múltiples actualizaciones en una única solicitud JSON-RPC (colocando múltiples objetos de solicitud JSON-RPC). Cuando se realiza una actualización de esta manera, todas las actualizaciones se realizarán secuencialmente.
Lo más importante es que cada solicitud JSON-RPC no es atómica. Si una actualización falla, todas las actualizaciones anteriores SE APLICARÁN y todas las actualizaciones posteriores SE PROCESARÁN y APLICARÁN también.
Respuesta JSON-RPC
La respuesta se expresa como un único objeto JSON, con los siguientes atributos:
ATRIBUTOTIPO DE DATO
DESCRIPCIÓN
jsonrpccadena
Una cadena que especifica la versión del protocolo JSON-RPC. It's set to "2.0"
resultadoobjeto
Un valor estructurado que contiene los detalles actualizados de la transacción
idcadena
Un identificador enviado por el cliente
errorobjeto
Un valor estructurado que contiene los detalles del error
Mostrar atributos secundarios
idcadena
Id único de la transacción para la cual ocurrió un error
códigonúmero
Un número que indica el tipo de error que ocurrió. Consulta una lista de códigos de error a continuación
mensajecadena
Una cadena que proporciona una breve descripción del error
datoscadena
Un valor primitivo o estructurado que contiene información adicional sobre el error
Códigos de Error
Código de error | Significado |
---|---|
-32600 | El JSON enviado no es un objeto Request válido |
-32601 | El método no existe / no está disponible |
-32602 | Invalid method parameter(s) |
-32603 | Error interno de JSON-RPC |
También harás referencia a una variable $transaction_id
. Esta es una identificación de la transacción que se está devolviendo desde la Anchor Platform en una solicitud de inicio de retirada de fondos o depósito. Puedes obtener el ID de la transacción conectando la billetera de prueba a tu instancia local de Anchor Platform.
Actualizando Transacción de Depósito (Exchange) Vía JSON-RPC
El diagrama de flujo de depósito SEP-6 define las secuencias/reglas de la transición del estado de la transacción y un conjunto de métodos JSON-RPC que deben ser llamados para cambiar ese estado. No puedes definir el estado que deseas establecer para una transacción específica en tus solicitudes. Cada método JSON-RPC define estructuras de datos que espera en la solicitud. Si la solicitud no contiene los atributos requeridos, la Anchor Platform devolverá un error y no cambiará el estado de la transacción.
El flujo de intercambio de depósitos es el mismo que el flujo de depósito, excepto que los montos no necesitan ser recalculados al solicitar fondos offchain, si el usuario ha proporcionado una cotización firme del ancla.
Los estados en verde son obligatorios y definen el camino más corto.
Los estados en amarillo son opcionales y pueden ser omitidos.
Los estados en rojo significan que la transacción está en un estado de error o ha caducado.
Verificando Información KYC
Aunque la Anchor Platform no requiere que un cliente tenga su información KYC recopilada antes de iniciar un depósito, tu negocio puede querer recopilar esta información antes de que el cliente realice una transferencia. Al escuchar eventos de transacción creados, o al consultar el GET /transactions
endpoint, puedes determinar si una transacción requiere que el cliente actualice su información. Los campos requeridos de SEP-9 se pueden comunicar al usuario retornando un estado NEEDS_INFO
con los campos requeridos en el atributo fields
.
- JSON
// reuest-customer-info-update.json
[
{
"id": "1",
"jsonrpc": "2.0",
"method": "request_customer_info_update",
"params": {
"id": "<transaction_id>",
"message": "Please update your information to continue"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh request-customer-info-update.json
Listo para Recibir Fondos
Después de que el usuario haya enviado su información KYC, el ancla puede notificar a la Plataforma que está listo para recibir fondos. El ancla debe usar el RPC request_offchain_funds
para proporcionar los montos finales al usuario. Para hacerlo, realiza la siguiente solicitud JSON-RPC.
- JSON
// request-offchain-funds.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "request_offchain_funds",
"params": {
"transaction_id": "<transaction_id>",
"message": "Request offchain funds",
"amount_in": {
"amount": 10,
"asset": "iso4217:USD"
},
"amount_out": {
"amount": 9,
"asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
},
"amount_fee": {
"amount": 1,
"asset": "iso4217:USD"
},
"amount_expected": {
"amount": 10
},
"instructions": {
"organization.bank_number": {
"value": "123456789",
"description": "US Bank routing number"
},
"organization.bank_account_number": {
"value": "123456789",
"description": "US Bank account number"
}
}
}
}
]
amount_in
es la cantidad que el usuario debe enviar al negocio.amount_out
es la cantidad que el usuario recibirá.amount_fee
es el total de tarifas recaudadas por el negocio.asset
es parte del campoamount_x
y está en formato SEP-38. En este ejemplo, se establece en USD, asumiendo que el usuario realizó una transferencia bancaria al sistema usando USD.instructions
es el conjunto de campos estándar SEP-9 que el usuario debe usar para enviar fondos al negocio. En este ejemplo, el usuario debe enviar fondos a la cuenta bancaria con el número de ruta123456789
y el número de cuenta123456789
.
La información sobre montos (entrada/salida/tasa) es requerida si deseas mover la transacción al estado pending_user_transfer_start
.
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh request-offchain-funds.json
Para depósitos de exchange con una cotización firme (la solicitud está asociada con un quote_id
), no se deben proporcionar montos.
Fondos Recibidos
Si se recibieron fondos offchain, querrás proporcionar información actualizada sobre la transacción.
- JSON
// offchain-funds-received.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_offchain_funds_received",
"params": {
"transaction_id": "<transaction_id>",
"message": "Offchain funds received",
"funds_received_at": "2023-07-04T12:34:56Z",
"external_transaction_id": "7...9",
"amount_in": {
"amount": 10
},
"amount_out": {
"amount": 9
},
"amount_fee": {
"amount": 1
},
"amount_expected": {
"amount": 10
}
}
}
]
funds_received_at
es la fecha y hora de recepción de fondos.external_transaction_id
es el ID de la transacción en la red externa.
Los campos de cantidad son opcionales. Si se omiten, se usarán los valores anteriores a esta solicitud.
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh offchain-funds-received.json
Esperando Fondos del Usuario
En el mundo real, el proceso de confirmación de la transferencia puede llevar tiempo. En tales casos, las transacciones deben establecerse en un nuevo estado que indique que se ha recibido la confirmación de la transferencia, pero los fondos mismos no han sido recibidos aún.
- JSON
// offchain-funds-sent.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_offchain_funds_sent",
"params": {
"transaction_id": "<transaction_id>",
"message": "Offchain funds sent",
"funds_received_at": "2023-07-04T12:34:56Z",
"external_transaction_id": "7...9"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh offchain-funds-sent.json
Enviando Fondos Onchain
A continuación, envía una transacción en la red Stellar para cumplir con el depósito del usuario. Después de que se haya enviado la transacción Stellar, es necesario enviar la solicitud JSON-RPC notify_onchain_funds_sent
para notificar a un usuario que los fondos se enviaron con éxito.
- JSON
// onchain-funds-sent.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_onchain_funds_sent",
"params": {
"transaction_id": "<transaction_id>",
"message": "Onchain funds sent",
"stellar_transaction_id": "7...9"
}
}
]
stellar_transaction_id
es el id de la transacción en la red Stellar de la transferencia.
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh onchain-funds-sent.json
Después de esta solicitud JSON-RPC, la transacción se transferirá al estado completed
.
Enviando Pago a Través de Servicio de Custodia
La Anchor Platform ofrece la posibilidad de enviar un pago a través de servicios de custodia, como Fireblocks. Para realizar un pago a través de un servicio de custodia, realiza la siguiente solicitud JSON-RPC.
- JSON
// do-stellar-payment.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "do_stellar_payment",
"params": {
"transaction_id": "<transaction_id>",
"message": "Custody payment started"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh do-stellar-payment.json
Después de que se procese con éxito el pago en un servicio de custodia, la Anchor Platform automáticamente realizará la solicitud JSON-RPC notify_onchain_funds_sent
y el estado de la transacción cambiará a completed
.
Una cuenta de usuario puede no estar lista para recibir fondos. Puedes verificar que la cuenta haya establecido una trustline. De lo contrario, puedes establecer el estado de la transacción en pending_trust
para indicar que el ancla está esperando que el usuario establezca la trustline.
Si la integración de custodia está habilitada, la Anchor Platform realizará esta validación automáticamente por ti.
Confianza Pendiente
Este estado debe establecerse si un pago requiere una trustline de activo que no fue configurada por el usuario. Hay dos formas de cómo la transacción puede moverse al estado pending_trust
. La primera es procesar un pago a través de un servicio de custodia en caso de que detecte que la trustline no está configurada. La segunda es cuando el negocio mismo detecta que falta la trustline y desea notificar al usuario que debe ser configurada. Para mover la transacción al estado pending_trust
, haz la siguiente solicitud JSON-RPC.
- JSON
// request-trust.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "request_trust",
"params": {
"transaction_id": "<transaction_id>",
"message": "Asset trustine not configured"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh request-trust.json
El pago a través del servicio de custodia verifica periódicamente si la trustline fue configurada. Si fue así, enviará automáticamente un pago a un servicio de custodia y cambiará el estado de la transacción a pending_stellar
.
Trust Set
Este estado debe establecerse si el negocio ha detectado que la trustline fue o no configurada por el usuario.
- JSON
// trust-set.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_trust_set",
"params": {
"transaction_id": "<transaction_id>",
"message": "Asset trustine set",
"success": "true"
}
}
]
success
flag que define si la trustline fue o no configurada por el usuario
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh trust-set.json
Dependiendo del success
flag, el estado de la transacción cambiará a pending_stellar
si la trustline fue configurada, o a pending_anchor
si no lo fue.
Reembolso Enviado
A veces, es necesario devolver fondos al usuario (reembolso). Puedes reembolsar la suma total (reembolso completo) o hacer un conjunto de reembolsos parciales de vuelta a la source_account
usando el refund_memo
y refund_memo_type
asociados con la transacción, si están presentes. Además, si el usuario envió más dinero del esperado, puedes reembolsar una parte de la suma de vuelta al usuario y enviar el resto como fondos onchain.
- JSON
// refund-sent.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_refund_sent",
"params": {
"transaction_id": "<transaction_id>",
"message": "Refund sent",
"refund": {
"id": "1c186184-09ee-486c-82a6-aa7a0ab1119c",
"amount": {
"amount": 10,
"asset": "iso4217:USD"
},
"amount_fee": {
"amount": 1,
"asset": "iso4217:USD"
}
}
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh refund-sent.json
Si la suma de reembolsos es menor que amount_in
, el estado de la transacción se establecerá en pending_anchor
. Solo si la suma de reembolsos es igual a amount_in
, el estado de la transacción se establecerá en refunded
.
Reembolso Pendiente
Esto es similar a Reembolso Enviado, pero maneja el caso cuando un reembolso ha sido enviado a la red externa pero no ha sido confirmado aún. El estado de la transacción se establece en pending_external
. Este es el estado que se establecerá cuando se espere que la red externa de Bitcoin u otra red de criptomonedas complete una transacción, o cuando se esté esperando una transferencia bancaria.
Error de Transacción
Si encuentras un error irrecuperable al procesar la transacción, es necesario establecer el estado de la transacción en error
. Puedes usar el campo de mensaje para describir los detalles del error.
- JSON
// transaction-error.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_transaction_error",
"params": {
"transaction_id": "<transaction_id>",
"message": "Error occurred"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh transaction-error.json
Si un usuario ha realizado una transferencia, deberías hacer una recuperación de transacción, y luego puedes volver a intentar procesar la transacción o iniciar un reembolso.
Transacción Caducada
Tu negocio puede querer caducar transacciones que han sido abandonadas por el usuario después de un tiempo. Es una buena práctica limpiar transacciones inactivas en estado incomplete
. Para hacerlo, realiza la siguiente solicitud JSON-RPC para caducar una transacción.
- JSON
// transaction-expired.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_transaction_expired",
"params": {
"transaction_id": "<transaction_id>",
"message": "Transaction expired"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh transaction-expired.json
Este método JSON-RPC no se puede utilizar después de que el usuario haya realizado una transferencia.
Recuperación de Transacción
El estado de la transacción puede cambiar de error/expired
a pending_anchor
. Después de la recuperación, puedes reembolsar los activos recibidos o continuar con el procesamiento de la transacción. Para recuperar una transacción, realiza la siguiente solicitud JSON-RPC.
- JSON
// transaction-recovery.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_transaction_recovery",
"params": {
"transaction_id": "<transaction_id>",
"message": "Transaction recovered"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh transaction-recovery.json
Actualizando Transacción de Retirada (Exchange) a Través de JSON-RPC
El diagrama de flujo de retirada SEP-6 define la secuencia/reglas de la transición de estado de la transacción. No puedes definir el estado que deseas establecer para una transacción específica en tus solicitudes. Cada método JSON-RPC define estructuras de datos que espera en la solicitud. Si la solicitud no contiene atributos requeridos, la Anchor Platform devolverá un error y no cambiará el estado de la transacción.
El flujo de intercambio de retiradas es el mismo que el flujo de retiradas, excepto que los montos no necesitarán ser recalculados al solicitar fondos en la cadena, si el usuario ha proporcionado una cotización firme del anchor.
Los estados en verde son obligatorios y definen el camino más corto.
Los estados en amarillo son opcionales y pueden ser omitidos.
Los estados en rojo significan que la transacción está en un estado de error o ha caducado.
Una vez que el flujo de retirada ha terminado, implementar la retirada es sencillo. Algunas partes del flujo son similares y pueden ser reutilizadas.
El punto de partida tanto para la retirada como para el depósito es el mismo.
Listo para Recibir Fondos
De manera similar al depósito, el paso después de haber recopilado la KYC es notificar al usuario que el anchor está listo para recibir fondos. Sin embargo, dado que tu servicio recibirá transacciones a través de la red Stellar, la solicitud RPC será diferente. El anchor debe usar el RPC request_onchain_funds
para proporcionar los montos finales al usuario. Para hacerlo, haz la siguiente solicitud JSON-RPC.
- JSON
// request-onchain-funds.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "request_onchain_funds",
"params": {
"transaction_id": "<transaction_id>",
"message": "Request onchain funds",
"amount_in": {
"amount": 10,
"asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
},
"amount_out": {
"amount": 9,
"asset": "iso4217:USD"
},
"amount_fee": {
"amount": 1,
"asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
},
"amount_expected": {
"amount": 10
},
"destination_account": "GD...G",
"memo": "12345",
"memo_type": "id"
}
}
]
amount_in
es el monto que el usuario debe enviar al negocio.amount_out
es el monto que el usuario recibirá.amount_fee
es el monto total de las tarifas cobradas por el negocio.asset
es parte del campoamount_x
y está en un formato SEP-38. En este ejemplo, está configurado a USD, asumiendo que el usuario realizó una transferencia bancaria al sistema usando USD.memo
es el memo que el usuario debe usar al enviar sus fondos en la cadena al anchor.memo_type
es el tipo de memo que el usuario debe usar al enviar sus fondos en la cadena al anchor.destination_account
es la cuenta a la que el usuario debe enviar los fondos.
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh request-onchain-funds.json
Para retiradas de exchange con una cotización firme (la solicitud está asociada con un quote_id
), no se deben proporcionar montos.
Establecer memo
, memo_type
y destination_account
es opcional.
Si la integración con un custodio de terceros está habilitada, la Anchor Platform puede generar memo
, memo_type
y destination_address
si se elige un deposit_info_generator_type
correspondiente. Además, puedes proporcionar memo
y memo_type
a la solicitud como se mostró arriba. Ten en cuenta que el memo debe ser único, esto es lo que ayuda a asociar las transacciones de Stellar con las transacciones SEP.
Si tu negocio gestiona los activos, la Anchor Platform puede generar memos para ti. Cuando el estado cambie a pending_user_transfer_start
, la Anchor Platform establecerá el memo
y el memo_type
automáticamente (solo si no están incluidos en la solicitud).
La cuenta Stellar que se usará para recibir fondos debe estar configurada.
Fondos Recibidos
Si se recibieron fondos en la cadena, necesitas proporcionar montos y cambiar el estado de la transacción a pending_anchor
.
- JSON
// onchain-funds-received.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_onchain_funds_received",
"params": {
"transaction_id": "<transaction_id>",
"message": "Onchain funds received",
"stellar_transaction_id": "7...9",
"amount_in": {
"amount": 10
},
"amount_out": {
"amount": 9
},
"amount_fee": {
"amount": 1
}
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh onchain-funds-received.json
Este método será llamado automáticamente por el servidor de custodia si la integración de custodia está habilitada.
Monto Actualizado
Si se recibieron fondos en la cadena, pero por alguna razón el amount_in
difiere del especificado en el flujo interactivo (amount_expected
), puedes actualizar amount_out
y amount_fee
para que correspondan al amount_in
real. El estado de la transacción en este caso no se cambiará y será igual a pending_anchor
.
- JSON
// amounts-updated.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_amounts_updated",
"params": {
"transaction_id": "<transaction_id>",
"message": "Amounts updated",
"amount_out": {
"amount": 9
},
"amount_fee": {
"amount": 1
}
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh amounts-updated.json
Solo amount_out
y amount_fee
pueden ser actualizados usando esta solicitud JSON-RPC, y no necesitas especificar los activos de los montos.
Fondos Fuera de la Cadena Disponibles
Puedes mover el estado de la transacción a pending_user_transfer_complete
si se enviaron fondos fuera de la cadena, y si está listo para que el usuario / destinatario lo recoja.
- JSON
// offchain-funds-available.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_offchain_funds_available",
"params": {
"transaction_id": "<transaction_id>",
"message": "Offchain funds available",
"external_transaction_id": "a...c"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh offchain-funds-available.json
Fondos Fuera de la Cadena Pendientes
Otra opción es mover el estado de la transacción a pending_external
. Este estado significa que el pago ha sido enviado a una red externa, pero aún no está confirmado.
- JSON
// offchain-funds-pending.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_offchain_funds_pending",
"params": {
"transaction_id": "<transaction_id>",
"message": "Offchain funds pending",
"external_transaction_id": "a...c"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh offchain-funds-pending.json
Fondos Fuera de la Cadena Enviados
Para completar la transacción y cambiar su estado a completed
, necesitas hacer la solicitud JSON-RPC notify_offchain_funds_sent
.
- JSON
// offchain-funds-sent.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "notify_offchain_funds_sent",
"params": {
"transaction_id": "<transaction_id>",
"message": "Offchain funds sent",
"funds_sent_at": "2023-07-04T12:34:56Z",
"external_transaction_id": "a...c"
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh offchain-funds-sent.json
Reembolso Enviado
La lógica de reembolso funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Reembolso Enviado del flujo de depósito.
Enviar Reembolso a Través del Servicio de Custodia
La integración con un servicio de custodia te permite hacer un reembolso a través de un servicio de custodia, como Fireblocks.
- JSON
// do-stellar-refund.json
[
{
"id": 1,
"jsonrpc": "2.0",
"method": "do_stellar_refund",
"params": {
"transaction_id": "<transaction_id>",
"message": "Do stellar refund",
"refund": {
"amount": {
"amount": 9,
"asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
},
"amount_fee": {
"amount": 1,
"asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
}
}
}
}
]
Para procesar esto, necesitas ejecutar:
- bash
./call-json-rpc.sh do-stellar-refund.json
De manera similar al flujo de depósito, puedes hacer un reembolso completo o un conjunto de reembolsos parciales. La transacción permanecerá en estado pending_anchor
hasta que la suma de los reembolsos sea inferior a amount_in
. Si la suma de los reembolsos es igual a amount_in
, la Anchor Platform cambiará automáticamente el estado de la transacción a refunded
.
Error de Transacción
Funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Error de Transacción del flujo de depósito.
Transacción Caducada
Funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Transacción Caducada del flujo de depósito.
Recuperación de Transacciones
Funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Recuperación de Transacciones del flujo de depósito.
Rastrear Transacciones Stellar
Utilizar el Observador de Pagos te permite delegar este paso a la Anchor Platform. Para habilitar el Observador de Pagos, usa el --stellar-observer
flag en la sección de comandos del archivo de composición.
El Observador de Pagos rastreará todas las transacciones enviadas a la cuenta de distribución. Cuando la transacción con el memo esperado se detecte en la red, el estado cambiará automáticamente a pending_anchor
y se emitirá el evento (si se usa Kafka).
Para actualizar los estados de la transacción, el observador realiza peticiones JSON-RPC correspondientes a la plataforma. Debería usar la siguiente URL.
- bash
# dev.env
PLATFORM_API_BASE_URL=http://platform-server:8085
El Observador de Pagos no validará los montos. Es tu responsabilidad verificar que el monto enviado por el usuario sea correcto.
Si ya tienes un sistema que monitorea los pagos, asegúrate de que la lógica del sistema iguale la descripción a continuación:
Primero, espera a que la transacción se incluya en el ledger (usando un SDK). Esta transacción debe tener el memo esperado y la dirección de destino (cuenta de distribución). Una vez que esta transacción haya sido detectada y verificada, notifica al usuario que los fondos han sido recibidos usando la solicitud JSON-RPC notify_onchain_funds_received.
El servicio de custodia de Fireblocks rastreará automáticamente las transacciones y notificará al usuario que los fondos han sido recibidos. Consulta la documentación del servicio de custodia de Fireblocks para más detalles.