Saltar al contenido principal
Versión: 2,10

Configuración

Modificar un archivo de información Stellar​

Comencemos por modificar nuestro archivo stellar.toml creado anteriormente. Las billeteras necesitan saber que la funcionalidad SEP-31 es admitida por tu negocio, 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 necesitarás crear otro archivo para el despliegue en producción que use la frase de contraseña de la red pública, las URL de servicio de producción, tus cuentas de distribución de mainnet y clave de firma, así como las cuentas emisoras de mainnet de los activos que utiliza tu servicio.

Habilitar Pagos Transnacionales​

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

# dev.assets.yaml
assets:
  - schema: stellar
    code: USDC
    issuer: GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5
    distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7
    significant_decimals: 2
    sep31_enabled: true
    sep31:
      quotes_supported: true
      quotes_required: true
      fields:
        transaction: {}
    send:
      min_amount: 0
      max_amount: 10000

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

Los parámetros sep31.quotes_supported y sep31.quotes_required determinan si las organizaciones que envían pueden y deben solicitar una tasa de cambio utilizando el endpoint SEP-38 POST /quote. Casi todos los remitentes prefieren este enfoque para que puedan comunicar la tasa a sus clientes antes de continuar.

Agrega la siguiente variable a tu archivo de entorno.

# dev.env
SEP31_ENABLED=true

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

docker compose up

Verifica que tu API esté en vivo.

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 del Cliente​

Las empresas necesitan recopilar y validar la información KYC sobre los clientes para los que están facilitando transacciones. Los clientes determinan qué información KYC debe ser recopilada y envían esa información a través de una API KYC SEP-12 alojada por la Anchor Platform, pero la Anchor Platform nunca almacena información personal identificable (PII). En cambio, reenvía 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 Anchor Platform para obtener detalles sobre los endpoints que deben implementarse en el servidor de tu negocio.

Para hacer esta API disponible para los clientes, agreguemos la URL del servicio a nuestro archivo de información Stellar.

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

Hagamos que también esté habilitada 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 transnacionales en dos jurisdicciones regulatorias distintas, de modo que los clientes en diferentes jurisdicciones tienen diferentes requisitos KYC y se representarían utilizando diferentes tipos.

información

Actualmente, los tipos de clientes deben ser mutuamente excluyentes, lo que significa que un cliente no puede ser más de un tipo.

Esta limitación está en su lugar porque la Anchor Platform no puede validar si un cliente está aprobado para un tipo específico de transacción, como una que envía una gran cantidad. Solo puede validar que un cliente está aprobado para uno de los tipos de cliente definidos. Esta limitación se eliminará 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

Vamos a hacer ping al endpoint de información nuevamente 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": {}
      },
      "sep12": {
        "sender": {
          "types": {
            "sep31-sender": {
              "description": "customers sending to recipients"
            }
          }
        },
        "receiver": {
          "types": {
            "sep31-receiver": {
              "description": "customers receiving from senders"
            }
          }
        }
      }
    }
  }
}

Habilitar la API RFQ​

Las empresas deben proporcionar a sus contrapartes del lado de envío una API Tasa para verificar las tasas de cambio que están ofreciendo entre el activo on-chain que se está utilizando para liquidación y el activo fiat que se está utilizando para pagar al destinatario. Si la tasa es competitiva, los remitentes también deben poder solicitar un compromiso con la tasa que actualmente se está ofreciendo desde el negocio por un corto periodo de tiempo.

La Anchor Platform proporciona la API RFQ SEP-38 a los remitentes para este propósito.

Para hacer esta API disponible para los clientes, agreguemos la URL del servicio a nuestro archivo de información Stellar.

# 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"

Hagamos que también esté habilitada en nuestro entorno.

# dev.env
SEP38_ENABLED=true

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

# dev.assets.yaml
assets:
  - schema: stellar
    code: USDC
    issuer: GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5
    distribution_account: GBLSAHONJRODSFTLOV225NZR4LHICH63RIFQTQN37L5CRTR2IMQ5UEK7
    significant_decimals: 2
    sep31_enabled: true
    sep38_enabled: true
    send:
      min_amount: 0
      max_amount: 10000
    sep31:
      quotes_supported: true
      quotes_required: true
      fields:
        transaction: {}
      sep12:
        sender:
          types:
            sep31-sender:
              description: customers sending to recipients
        receiver:
          types:
            sep31-receiver:
              description: customers receiving from senders
    sep38:
      exchangeable_assets:
        - iso4217:BRL
      country_codes:
        - BRA
  - schema: iso4217
    code: BRL
    sep38_enabled: true
    sep38:
      exchangeable_assets:
        - stellar:USDC:GBBD47IF6LWK7P7MDEVSCWR7DPUWV3NY3DTQEVFL4NAT4AQH3ZLLFLA5
      country_codes:
        - BRA
      significant_decimals: 2
      buy_delivery_methods:
        - name: PIX
          description: Have BRL sent directly to your bank account.

¡Probemos que tu API RFQ esté en vivo! Siguiendo 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": ["BRA"],
      "buy_delivery_methods": [
        {
          "name": "PIX",
          "description": "Have BRL sent directly to your bank account."
        }
      ]
    }
  ]
}

Configurar la Autenticación de la API de Callback​

Así como tu negocio necesitará hacer solicitudes a la Anchor Platform, la Anchor Platform también 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 el host porque la Anchor Platform realizará solicitudes a tu servidor desde dentro de la red local creada por docker compose. When configuring your service in a staging or production environment, make sure to update your service urls.

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

advertencia

Ten en cuenta que a partir de la versión 2.x, los segmentos de ruta no son admitidos en CALLBACK_API_BASE_URL (como http://server:8081/myPath).