Configuración
Modificar un archivo de información de Stellar
Comencemos modificando 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.
- TOML
# 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 tu implementación en producción que use la frase de pase de la red pública, las URL de servicio de producción, tus cuentas de distribución de mainnet y la clave de firma, así como las cuentas emisoras de mainnet de los activos que utiliza tu servicio.
Habilitar pagos transfronterizos
Ahora estás listo para habilitar pagos transfronterizos con la API SEP-31. Especifica lo siguiente en tu archivo dev.assets.yaml
.
- 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
se mapea estrechamente con la información que se expondrá a la aplicación de billetera usando el endpoint GET /info
de SEP-31. 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 será eliminado en una futura versión, pero puedes ajustar los valores de send.min_amount
y send.max_amount
de acuerdo con los límites de tu servicio.
Los sep31.quotes_supported
y sep31.quotes_required
determinan si las organizaciones emisoras pueden y están obligadas a solicitar una tasa de cambio utilizando el endpoint SEP-38 POST /quote
. Casi todos los emisores prefieren este enfoque para que puedan comunicar la tasa a sus clientes antes de proceder.
Agrega la siguiente variable a tu archivo de entorno.
- bash
# dev.env
SEP31_ENABLED=true
¡Los emisores ahora deberían poder descubrir, autenticar y comenzar transacciones con tu servicio! Ejecuta el siguiente comando para iniciar la Anchor Platform.
- bash
docker compose up
Verifica que tu API esté activa.
- bash
curl http://localhost:8080/sep31/info | jq
Deberías obtener lo siguiente.
- JSON
{
"receive": {
"USDC": {
"enabled": true,
"quotes_supported": true,
"quotes_required": true,
"min_amount": 0,
"max_amount": 10000,
"fields": {
"transaction": {}
}
}
}
}
Habilitar la API de KYC del cliente
Las empresas necesitan recopilar y validar la información de KYC de los clientes para quienes están facilitando transacciones. Los clientes determinan qué información de KYC necesita 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 su lugar, 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 API KYC de Anchor Platform para detalles sobre los endpoints que deben implementarse en el servidor de tu negocio.
Para hacer que esta API esté disponible para los clientes, añadamos la URL del servicio a nuestro archivo de información de Stellar.
- TOML
# dev.stellar.toml
KYC_SERVER = "http://localhost:8080/sep12"
Habilitemos esto en nuestro entorno también.
- bash
# dev.env
SEP12_ENABLED=true
Finalmente, tenemos que definir los tipos de cliente de tu negocio. Cada tipo de cliente requiere un conjunto diferente de información de KYC. Por ejemplo, puedes ofrecer tu servicio de pagos transfronterizos en dos jurisdicciones regulatorias distintas, de modo que los clientes en diferentes jurisdicciones tengan diferentes requisitos de KYC y serían representados usando diferentes tipos.
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 de transacción específica, como uno 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 será eliminada en una futura versión.
En esta guía, solo tendremos dos tipos, un tipo de cliente que envía y un tipo de cliente que recibe. Actualmente, nuestros tipos de clientes están definidos en nuestra configuración de activos, pero esto cambiará en una futura versión.
- YAML
# 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:
- bash
curl http://localhost:8080/sep31/info | jq
Deberías obtener lo siguiente:
- JSON
{
"receive": {
"USDC": {
"enabled": true,
"quotes_supported": true,
"quotes_required": true,
"min_amount": 0,
"max_amount": 10000,
"fields": {
"transaction": {}
}
}
}
}
Habilitar la API RFQ
Las empresas necesitan proporcionar a sus contrapartes del lado de envío una API de Tarifas para verificar las tasas de cambio que están ofreciendo entre el activo en cadena que se utiliza para la liquidación y el activo fiduciario que se usa para pagar al destinatario. Si la tasa es competitiva, los emisores también deben poder solicitar un compromiso con la tasa que se está ofreciendo actualmente por el negocio durante un corto periodo de tiempo.
La Anchor Platform proporciona la API RFQ SEP-38 a los emisores para este propósito.
Para hacer que esta API esté disponible para los clientes, añadamos la URL del servicio a nuestro archivo de información de Stellar.
- TOML
# 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"
Habilitemos esto en nuestro entorno también.
- bash
# dev.env
SEP38_ENABLED=true
También necesitamos habilitar el uso de USDC en esta API, así como agregar un activo fuera de la cadena con el que se pueda intercambiar.
- 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
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! Después de docker compose up
:
- bash
curl http://localhost:8080/sep38/info | jq
Deberías obtener lo siguiente:
- JSON
{
"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 de la API de Callback
Así como tu negocio necesitará hacer solicitudes a la Anchor Platform, la Anchor Platform necesitará hacer solicitudes a tu negocio. Añadamos autenticación a estas solicitudes también.
- bash
# 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 de negocio desde dentro de la red local creada por docker compose. Al configurar tu servicio en un entorno de prueba o producción, asegúrate de actualizar tus URLs de servicio.
Definiremos el servidor que implementa los endpoints definidos en la API de Callback en la siguiente sección.