Saltar al contenido principal
Versión: Siguiente

Integración

Uno de los principales puntos de interacción con la Anchor Platform es notificar a la Anchor Platform sobre eventos relacionados con la transacción.

En general, querrás proporcionar actualizaciones para los siguientes eventos:

  • Tu negocio está procesando la información KYC proporcionada por el usuario
  • 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 Platform. Las solicitudes JSON-RPC te 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 requeridos por este 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. Dicho esto, la API será llamada cada vez que un usuario o la anchor realice una acción que haga avanzar 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 gestiona a través del servicio de eventos. Esta es una función opcional que debe configurarse por separado de la integración SEP-6. Para más información, consulta Gestión de Eventos.

Puedes obtener más información sobre el flujo y los estados de la transacción en el documento del protocolo SEP-24

Callbacks

La Anchor Platform depende del servidor de negocio para proporcionar y almacenar información sobre las cotizaciones.

Cotizaciones y Tarifas

Para admitir el intercambio 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 envía. La API de cotizaciones también se usa para proporcionar al usuario las tarifas esperadas para la transacción. Por lo tanto, tu servidor de negocio debe implementar la API de tarifa para proporcionar cotizaciones a la Anchor Platform.

Asegurando la API de la Platform

advertencia

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 cualquiera que tenga acceso al servidor, incluidas las billeteras.

información

Se recomienda mantener el servidor de la plataforma accesible solo desde la red privada. Sin embargo, puede que quieras añadir una capa adicional de protección al asegurar la API.

Uso de la clave API

Para habilitar la autenticación por clave de API, modifica tu archivo dev.env:

# dev.env
PLATFORM_API_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, configurado con la clave de API establecida.

Uso de JWT

Para habilitar la autenticación JWT, modifica tu archivo dev.env:

# dev.env
PLATFORM_API_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 tokens JWT. Asegúrate de que SECRET_PLATFORM_API_AUTH_SECRET tenga al menos 32 caracteres para mayor 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.

# 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 que se encuentra en el puerto predeterminado (8085). Los datos de transacción JSON almacenados en el archivo proporcionado se utilizarán como cuerpo (las solicitudes deben ser un arreglo).

Solicitud JSON-RPC

El objeto Request debe contener los siguientes atributos:

  • ATRIBUTOTIPO DE DATO

    DESCRIPCIÓN

  • jsonrpccadena

    A String specifying the version of the JSON-RPC protocol. MUST be exactly "2.0"

  • métodocadena

    Una cadena que contiene el nombre del método a invocar. Lista de métodos disponibles que puedes ver en [JSON-RPC Methods][json-rpc-methods]

  • paramsobjeto

    A Structured value that holds the parameter values, corresponding to method call, to be used during the invocation of the method

  • idcadena

    Un identificador establecido por el cliente. The Server will reply with the same value in the Response object

  • consejo

    Es posible proporcionar múltiples actualizaciones en una sola solicitud JSON-RPC (colocando múltiples objetos de solicitud JSON-RPC). Cuando una actualización se realiza de esta manera, todas las actualizaciones se realizarán de forma secuencial.

    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 también se PROCESARÁN y APLICARÁ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 por la que 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 errorSignificado
    -32600El JSON enviado no es un objeto Request válido
    -32601El método no existe / no está disponible
    -32602Invalid method parameter(s)
    -32603Error interno de JSON-RPC
    consejo

    También haremos 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 la Transacción de Depósito vía JSON-RPC

    El diagrama del flujo de depósito SEP-24 define la secuencia/reglas para la transición de estados de la transacción y un conjunto de métodos JSON-RPC que se deben llamar para cambiar ese estado. No puedes definir el estado que quieres asignar a una transacción específica en tus solicitudes. Cada método JSON-RPC define las 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.

    flujo de depósito sep24

    consejo

    Los estados en verde son obligatorios y definen el camino más corto.

    Los estados en amarillo son opcionales y pueden omitirse.

    Los estados en rojo significan que la transacción está en un estado de error o ha expirado.

    Listo para Recibir Fondos

    El primer paso del flujo de depósito después de iniciar el depósito en sí es recopilar KYC. Generalmente se realiza en la aplicación web, pero también puede ser proporcionado opcionalmente por la aplicación billetera, usando SEP-9. Una vez que se recopila el KYC necesario, se debe hacer una solicitud JSON-RPC request_offchain_funds.

    // 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"
    },
    "fee_details": {
    "total": 1,
    "asset": "iso4217:USD"
    },
    "amount_expected": {
    "amount": 10
    }
    }
    }
    ]
    • amount_in es la cantidad que el usuario debe enviar al negocio.
    • amount_out es la cantidad que el usuario recibirá.
    • fee_details es el monto total de tarifas cobradas por el negocio.
    • asset es parte del campo amount_x y está en formato SEP-38. En este ejemplo, está configurado en USD, asumiendo que el usuario realizó una transferencia bancaria al sistema usando USD.

    La información sobre los montos (entrada/salida/tarifa) es requerida si deseas mover la transacción de incomplete a pending_user_transfer_start. Si el estado de la transacción cambia de pending_anchor a pending_user_transfer_start, puedes omitir la definición de los montos.

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh request-offchain-funds.json
    consejo

    Cuando el proceso de KYC es largo (por ejemplo, verificación de identidad), se aconseja primero establecer el estado de la transacción a pending_anchor usando la solicitud JSON-RPC notify_interactive_flow_completed. Esto indicará al usuario que el KYC está en proceso.

    Procesando Información KYC

    consejo

    Este paso es opcional. La mayoría de los negocios no lo usan. Puedes saltarlo e ir al siguiente paso.

    Se recomienda usar este estado cuando la verificación KYC pueda necesitar realizarse de forma asincrónica.

    Debes especificar los campos amount_x.

    // kyc-in-process.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "notify_interactive_flow_completed",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Interactive flow completed.",
    "amount_in": {
    "amount": 10,
    "asset": "iso4217:USD"
    },
    "amount_out": {
    "amount": 9,
    "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
    },
    "fee_details": {
    "total": 1,
    "asset": "iso4217:USD"
    },
    "amount_expected": {
    "amount": 10
    }
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh kyc-in-process.json

    Fondos Recibidos

    Si se recibieron fondos offchain, querrás proporcionar información actualizada de la transacción.

    // 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
    },
    "fee_details": {
    "total": 1
    },
    "amount_expected": {
    "amount": 10
    }
    }
    }
    ]
    • funds_received_at es la fecha y hora de recepción de los 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 tomarán los valores de solicitudes JSON-RPC previas.

    Para ejecutar esto, necesitas correr:

    ./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 tomar 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 aún no los fondos.

    // 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 ejecutar esto, necesitas correr:

    ./call-json-rpc.sh offchain-funds-sent.json

    Enviando Fondos Onchain

    Luego, envía una transacción en la red Stellar para cumplir con la solicitud del usuario. Después de completar la transacción, es necesario enviar la solicitud JSON-RPC notify_onchain_funds_sent para notificar al usuario que los fondos fueron enviados con éxito.

    // 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 ejecutar esto, necesitas correr:

    ./call-json-rpc.sh onchain-funds-sent.json

    Después de esta solicitud JSON-RPC, la transacción cambiará al estado completed.

    Enviando Pago a través del Servicio Custodia

    La Anchor Platform ofrece la posibilidad de enviar pagos mediante servicios de custodia, como Fireblocks. Para hacer un pago a través de un servicio de custodia, es necesario realizar la siguiente solicitud JSON-RPC:

    // do-stellar-payment.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "do_stellar_payment",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Custody payment started"
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh do-stellar-payment.json

    Después del procesamiento exitoso del pago en el servicio de custodia, la Anchor Platform hará automáticamente la solicitud JSON-RPC notify_onchain_funds_sent y el estado de la transacción cambiará a completed.

    advertencia

    Es posible que la cuenta de un usuario no esté lista para recibir fondos. Puedes verificar que la cuenta haya establecido una trustline. De lo contrario, puedes establecer el estado de la transacción como pending_trust para indicar que la anchor 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.

    Pendiente de Trustline

    Este estado debe establecerse si un pago requiere una trustline de activo que el usuario no configuró. Hay dos formas en que la transacción puede cambiar al estado pending_trust. La primera es mediante el procesamiento de un pago a través de un servicio de custodia cuando se detecta que la trustline no está configurada. La segunda es cuando el negocio detecta que falta la trustline y quiere notificar al usuario que debe configurarla. Para mover la transacción al estado pending_trust, es necesario hacer la siguiente solicitud JSON-RPC:

    // request-trust.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "request_trust",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Asset trustine not configured"
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh request-trust.json
    información

    El pago mediante el servicio de custodia revisa periódicamente si la trustline fue configurada. Si lo fue, enviará automáticamente un pago al servicio de custodia y cambiará el estado de la transacción a pending_stellar.

    Trustline Configurada

    Este estado debe establecerse si el negocio ha detectado si la trustline fue o no configurada por el usuario.

    // trust-set.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "notify_trust_set",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Asset trustine set",
    "success": "true"
    }
    }
    ]
    • El flag success define si la trustline fue configurada por el usuario o no

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh trust-set.json
    información

    Dependiendo del flag success, el estado de la transacción cambiará a pending_stellar si la trustline fue configurada, o a pending_anchor si no lo fue.

    Enviando Reembolso vía Servicio de Custodia

    Existe la posibilidad de devolver fondos al usuario (reembolso). Puedes reembolsar la suma completa (reembolso total) o hacer un conjunto de reembolsos parciales. Además, si el usuario envió más dinero de lo esperado, puedes devolver una parte al usuario y enviar el resto como fondos onchain.

    // 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 ejecutar esto, necesitas correr:

    ./call-json-rpc.sh refund-sent.json
    información

    Si la suma de los reembolsos es menor que amount_in, el estado de la transacción se establecerá en pending_anchor. Solo si la suma de los reembolsos es igual a amount_in, el estado de la transacción se establecerá en refunded.

    Reembolso Pendiente

    Es similar a Reembolso enviado, pero maneja el caso cuando un reembolso ha sido enviado a la red externa pero aún no está confirmado. El estado de la transacción se establece en pending_external. Este es el estado que se establecerá cuando se esté esperando que la red externa, como Bitcoin u otra criptomoneda, complete una transacción, o al esperar una transferencia bancaria.

    Error en la 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.

    // transaction-error.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "notify_transaction_error",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Error occurred"
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh transaction-error.json
    consejo

    Si un usuario ha realizado una transferencia, deberías hacer una recuperación de la transacción, y luego puedes reintentar procesar la transacción o iniciar un reembolso.

    Transacción Expirada

    Tu negocio puede querer manejar transacciones abandonadas expirándolas si han estado inactivas por cierto período. Para lograr esto, verifica el estado de la transacción usando el endpoint GET /transactions y ordena los resultados por la marca de tiempo user_action_required_by. Si la marca de tiempo ha pasado, ejecuta manualmente la lógica apropiada, como expirar la transacción o iniciar un auto-reembolso, según el estado actual de la transacción. Por ejemplo, para expirar la transacción el negocio debe cambiar el estado de la transacción a expired:

    // transaction-expired.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "notify_transaction_expired",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Transaction expired"
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh transaction-expired.json
    consejo

    Este método JSON-RPC no puede usarse después de que el usuario haya realizado una transferencia.

    Transacción en Espera

    En casos raros, puedes querer pausar la transacción actual y solicitar más información al usuario (después de recibir la transferencia). Esto podría usarse para casos de cumplimiento normativo.

    // transaction-hold.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "notify_transaction_on_hold",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Transaction is on hold. Please contact customer support to resolve the hold."
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh transaction-hold.json

    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, es necesario hacer la siguiente solicitud JSON-RPC:

    // transaction-recovery.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "notify_transaction_recovery",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Transaction recovered"
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh transaction-recovery.json

    Actualizando la Transacción de Retirada vía JSON-RPC

    Este diagrama define una secuencia/reglas de la transición de estados para el flujo de retirada SEP-24.

    flujo de retirada sep24

    consejo

    Los estados en verde son obligatorios y definen el camino más corto.

    Los estados en amarillo son opcionales y pueden omitirse.

    Los estados en rojo significan que la transacción está en un estado de error o ha expirado.

    Una vez finalizado el flujo de depósito, implementar la retirada es sencillo. Algunas partes del flujo son similares y pueden reutilizarse.

    El punto de partida tanto para retirada como para depósito es el mismo.

    Listo para Recibir Fondos

    Similar al depósito, el siguiente paso es notificar al usuario que la anchor está lista para recibir fondos. Sin embargo, dado que tu servicio recibirá transacciones a través de la red Stellar, la actualización será diferente.

    // 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"
    },
    "fee_details": {
    "total": 1,
    "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
    },
    "amount_expected": {
    "amount": 10
    },
    "destination_account": "GD...G",
    "memo": "12345",
    "memo_type": "id"
    }
    }
    ]
    • Valor memo que se adjuntará a la transacción
    • Tipo de memo que la anchor debe adjuntar a la transacción
    • Cuenta destino

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh request-onchain-funds.json
    consejo

    Establecer memo, memo_type y destination_account es opcional.

    Si la integración con un custodio tercero 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 muestra arriba. Ten en cuenta que el memo debe ser único, eso es lo que ayuda a asociar las transacciones Stellar con las transacciones SEP.

    Si tu negocio gestiona los activos, la Anchor Platform puede generar memos para ti. Cuando el estado cambia a pending_user_transfer_start, la Anchor Platform establece automáticamente el memo y memo_type (solo si no se incluyen en la solicitud).

    nota

    Debe configurarse la cuenta Stellar que se usará para recibir fondos.

    Procesando Información KYC

    Este paso es opcional, y es similar a Procesando Información KYC del flujo de depósito.

    Fondos Recibidos

    Si se recibieron fondos onchain, debes proporcionar los montos y cambiar el estado de la transacción a pending_anchor.

    // 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
    },
    "fee_details": {
    "total": 1
    }
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh onchain-funds-received.json
    consejo

    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 onchain, pero por alguna razón amount_in difiere del especificado en el flujo interactivo (amount_expected), puedes actualizar amount_out y fee_details para que correspondan con el amount_in real. El estado de la transacción en este caso no cambiará y seguirá siendo pending_anchor.

    // amounts-updated.json
    [
    {
    "id": 1,
    "jsonrpc": "2.0",
    "method": "notify_amounts_updated",
    "params": {
    "transaction_id": "<transaction_id>",
    "message": "Amounts updated",
    "amount_out": {
    "amount": 9
    },
    "fee_details": {
    "total": 1
    }
    }
    }
    ]

    Para ejecutar esto, necesitas correr:

    ./call-json-rpc.sh amounts-updated.json
    nota

    Solo amount_out y fee_details pueden actualizarse usando esta solicitud JSON-RPC, y no necesitas especificar los activos de los montos.

    Fondos Offchain Enviados

    Para completar la transacción y cambiar su estado a completed, necesitas hacer la solicitud JSON-RPC notify_offchain_funds_sent.

    // 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 ejecutar esto, necesitas correr:

    ./call-json-rpc.sh offchain-funds-sent.json

    Fondos Offchain Disponibles

    Puedes mover el estado de la transacción a pending_user_transfer_complete si se enviaron fondos offchain y si está listo para que el usuario/beneficiario los recoja.

    // 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 ejecutar esto, necesitas correr:

    ./call-json-rpc.sh offchain-funds-available.json

    Fondos Offchain 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.

    // 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 ejecutar esto, necesitas correr:

    ./call-json-rpc.sh offchain-funds-pending.json

    Reembolso Enviado

    La lógica de reembolso funciona igual que para el flujo de depósito. Para más detalles, consulta Reembolso Enviado del flujo de depósito.

    Enviando Reembolso vía 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.

    // 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 ejecutar esto, necesitas correr:

    ./call-json-rpc.sh do-stellar-refund.json
    nota

    Similar al flujo de depósito, puedes hacer un reembolso completo o varios parciales. La transacción se mantendrá en estado pending_anchor hasta que la suma de los reembolsos sea menor que 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 en la Transacción

    Funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Error en la Transacción del flujo de depósito.

    Transacción Expirada

    Funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Transacción Expirada del flujo de depósito.

    Transacción en Espera

    Funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Transacción en Espera del flujo de depósito.

    Recuperación de Transacción

    Funciona de la misma manera que para el flujo de depósito. Para más detalles, consulta Recuperación de Transacción del flujo de depósito.

    Seguimiento de Transacciones Stellar

    Usar el Payment Observer te permite delegar este paso a la Anchor Platform. Para habilitar el Payment Observer, usa el flag --stellar-observer en la sección de comandos del archivo compose.

    El Payment Observer rastreará todas las transacciones enviadas a la cuenta de distribución. Cuando se detecte la transacción con el memo esperado en la red, el estado cambiará automáticamente a pending_anchor y el evento será emitido (si se usa Kafka).

    Para actualizar los estados de las transacciones, el observer realiza las solicitudes JSON-RPC correspondientes a la plataforma. Debe usar la siguiente URL.

    # dev.env
    PLATFORM_API_BASE_URL=http://platform-server:8085
    advertencia

    El Payment Observer no validará los montos. Es tu responsabilidad verificar que el monto enviado por el usuario sea correcto.

    información

    Si ya tienes un sistema que monitorea 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 ha sido detectada y verificada, notifica al usuario que los fondos han sido recibidos usando la solicitud JSON-RPC notify_onchain_funds_received.

    consejo

    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.