Saltar al contenido principal

Configuración

Modificar un archivo Stellar Info​

Comencemos modificando nuestro archivo stellar.toml creado anteriormente. Las billeteras deben saber que tu negocio soporta la funcionalidad SEP-31, y también necesitan conocer todas las monedas que admites.

# dev.stellar.toml
ACCOUNTS = ["add your public keys for your distribution accounts here"]
SIGNING_KEY = "add your signing key here"
NETWORK_PASSPHRASE = "Test SDF Network ; September 2015"

DIRECT_PAYMENT_SERVER = "http://localhost:8080/sep31"
WEB_AUTH_ENDPOINT = "http://localhost:8080/auth"

[[CURRENCIES]]
code = "USDC"
issuer = "GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
status = "test"
is_asset_anchored = false
desc = "USD Coin issued by Circle"

[DOCUMENTATION]
ORG_NAME = "Your organization"
ORG_URL = "Your website"
ORG_DESCRIPTION = "A description of your organization"

Ten en cuenta que deberás crear otro archivo para el despliegue en producción que utilice la frase de paso de la red pública, las URLs de servicio de producción, tus cuentas de distribución mainnet y la clave de firma, así como las cuentas emisoras mainnet de los activos que utiliza tu servicio.

Habilitar Pagos Transfronterizos​

Ahora estás listo para habilitar los pagos transfronterizos en la API SEP-31. Especifica lo siguiente en tu archivo dev.assets.yaml.

# dev.assets.yaml
items:
  - id: stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5
    distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7
    significant_decimals: 2
    sep31:
      enabled: true
      quotes_supported: true
      quotes_required: true
      receive:
        min_amount: 0
        max_amount: 10000
        methods:
          - ACH

La información proporcionada en los objetos sep31 y send corresponde estrechamente a la información que se expondrá a la aplicación de billetera mediante el endpoint SEP-31 GET /info. La plataforma Anchor también usa esta información para validar las solicitudes hechas a tu servicio. sep31.fields.transaction debe dejarse vacío y será eliminado en una futura versión, pero puedes ajustar los valores send.min_amount y send.max_amount según los límites de tu servicio.

Las propiedades sep31.quotes_supported y sep31.quotes_required determinan si las organizaciones que envían pueden y están obligadas a solicitar una tasa de cambio mediante el endpoint SEP-38 POST /quote. Casi todos los remitentes prefieren este enfoque para poder comunicar la tasa a sus clientes antes de proceder.

Agrega la siguiente variable a tu archivo de entorno.

# dev.env
SEP31_ENABLED=true

¡Los remitentes ahora deberían poder descubrir, autenticarse e iniciar transacciones con tu servicio! Ejecuta el siguiente comando para iniciar la plataforma Anchor.

docker compose up

Verifica que tu API esté activa.

curl http://localhost:8080/sep31/info | jq

Deberías obtener lo siguiente.

{
  "receive": {
    "USDC": {
      "enabled": true,
      "quotes_supported": true,
      "quotes_required": true,
      "min_amount": 0,
      "max_amount": 10000,
      "fields": {
        "transaction": {}
      }
    }
  }
}

Habilitar la API KYC para Clientes​

Los negocios necesitan recopilar y validar información KYC de los clientes para quienes están facilitando transacciones. Los clientes determinan qué información KYC debe recopilarse y envían esa información a través de una API SEP-12 KYC alojada por la plataforma Anchor, pero la plataforma Anchor nunca almacena información personal identificable (PII). En cambio, la plataforma reenvía las solicitudes de los clientes al servidor del negocio y devuelve las respuestas del negocio al cliente, actuando como un servidor proxy.

Consulta la especificación de la API KYC de la plataforma Anchor para obtener detalles sobre los endpoints que deben implementarse en el servidor de tu negocio.

Para poner esta API a disposición de los clientes, añadamos la URL del servicio a nuestro archivo Stellar Info.

# dev.stellar.toml
KYC_SERVER = "http://localhost:8080/sep12"

Habilitémosla también en nuestro entorno.

# dev.env
SEP12_ENABLED=true

Finalmente, debemos definir los tipos de clientes de tu negocio. Cada tipo de cliente requiere un conjunto diferente de información KYC. Por ejemplo, puedes ofrecer tu servicio de pagos transfronterizos en dos jurisdicciones regulatorias distintas, por lo que los clientes en diferentes jurisdicciones tienen diferentes requisitos KYC y serían representados usando diferentes tipos.

información

Actualmente, los tipos de clientes deben ser mutuamente exclusivos, es decir, un cliente no puede ser más de un tipo.

Esta limitación existe porque la plataforma Anchor no puede validar si un cliente está aprobado para un tipo específico de transacción, como enviar una cantidad grande. Solo puede validar que un cliente está aprobado para uno de los tipos de clientes definidos. Esta limitación será eliminada en una futura versión.

En esta guía, solo tendremos dos tipos: un tipo de cliente remitente y un tipo de cliente receptor. Actualmente, nuestros tipos de clientes están definidos en nuestra configuración de activos, pero esto cambiará en una futura versión.

# dev.assets.yaml
sep31:
  sep12:
    sender:
      types:
        sep31-sender:
          description: customers sending to recipients
    receiver:
      types:
        sep31-receiver:
          description: customers receiving from senders

Volvamos a hacer ping al endpoint info para verificar. Después de docker compose up, ejecuta el siguiente comando:

curl http://localhost:8080/sep31/info | jq

Deberías obtener lo siguiente:

{
  "receive": {
    "USDC": {
      "enabled": true,
      "quotes_supported": true,
      "quotes_required": true,
      "min_amount": 0,
      "max_amount": 10000,
      "fields": {
        "transaction": {}
      }
    }
  }
}

Habilitar la API RFQ​

Los negocios necesitan proporcionar a sus contrapartes del lado del envío una API Rate para comprobar las tasas de cambio que están ofreciendo entre el activo on-chain utilizado para la liquidación y el activo fiat utilizado para pagar al destinatario. Si la tasa es competitiva, los remitentes también deben poder solicitar un compromiso con la tasa actualmente ofrecida por el negocio por un corto período de tiempo.

La plataforma Anchor provee la API SEP-38 RFQ para los remitentes con este propósito.

Para poner esta API a disposición de los clientes, añadamos la URL del servicio a nuestro archivo Stellar Info.

# dev.stellar.toml
DIRECT_PAYMENT_SERVER = "http://localhost:8080/sep31"
WEB_AUTH_ENDPOINT = "http://localhost:8080/auth"
KYC_SERVER = "http://localhost:8080/sep12"
QUOTE_SERVER = "http://localhost:8080/sep38"

Habilitémosla también en nuestro entorno.

# dev.env
SEP38_ENABLED=true

También necesitamos habilitar USDC para usarla en esta API, así como agregar un activo off-chain con el que pueda intercambiarse.

# dev.assets.yaml
items:
  - id: stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5
    distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7
    significant_decimals: 2
    sep31:
      enabled: true
      quotes_supported: true
      quotes_required: true
      receive:
        min_amount: 0
        max_amount: 10000
        methods:
          - ACH
    sep38:
      enabled: true
      exchangeable_assets:
        - iso4217:BRL
      country_codes:
        - BR
  - id: iso421:BRL
    sep38:
      enabled: true
      exchangeable_assets:
        - stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5
      country_codes:
        - BR
      significant_decimals: 2
      buy_delivery_methods:
        - name: PIX
          description: Have BRL sent directly to your bank account.

¡Probemos que tu API RFQ esté activa! Tras docker compose up:

curl http://localhost:8080/sep38/info | jq

Deberías obtener lo siguiente:

{
  "assets": [
    {
      "asset": "stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5"
    },
    {
      "asset": "iso4217:BRL",
      "country_codes": ["BR"],
      "buy_delivery_methods": [
        {
          "name": "PIX",
          "description": "Have BRL sent directly to your bank account."
        }
      ]
    }
  ]
}

Configurar la Autenticación para la API de Callback​

Así como tu negocio necesitará hacer solicitudes a la plataforma Anchor, la plataforma Anchor necesitará hacer solicitudes a tu negocio. Agreguemos autenticación a estas solicitudes también.

# dev.env
CALLBACK_API_BASE_URL=http://server:8081
CALLBACK_API_AUTH_TYPE=jwt
CALLBACK_API_AUTH_JWT_EXPIRATION_MILLISECONDS=30000
SECRET_CALLBACK_API_AUTH_SECRET=<your jwt encryption key>

CALLBACK_API_BASE_URL utiliza server en lugar de localhost como host porque la plataforma Anchor realizará solicitudes a tu servidor de negocio desde dentro de la red local creada por docker compose. Al configurar tu servicio en un entorno de staging o producción, asegúrate de actualizar las URLs de tu servicio.

Definiremos el servidor que implementa los endpoints definidos en la API de Callback en la sección siguiente.