Cómo resolver llaves en Bre-B
En esta guía aprenderás a resolver una Llave Bre-B usando el Ledger de Kamin para obtener los datos del destinatario (nombre y cuenta) y así poder realizar una dispersión B2P.
Requisitos previos
- Tienes un token Bearer válido para autenticar solicitudes
GET. - Handle del Ledger de tu entorno (x-ledger).
Llave Bre-B provista por el pagador/beneficiario puedes encontrar las llaves de prueba en Llaves de prueba
Todas las solicitudes de lectura al Ledger de Kamin (GET) deben estar
autenticadas con un token Bearer.
Para más información, consulta:
Objetivo
Resolver una llave Bre-B y obtener la cuenta destino y datos del usuario que recibirán el pago, en Kamin la reolución de la llave es mapeada a traves de un Anchor.
Get Anchor
La API de Anchor permite obtener Anchors usando el endpoint GET /v2/anchors/:handle
donde el handle es la llave a resolver.
Existen 5 tipo de llaves en Bre-B, para personas naturales solo 4 estan habilitadas: PHONE, ALPHANUM, NRIC (id) y EMAIL
Solicitud de ejemplo
GET <baseURL>/api/v2/anchors/{anchorHandle}Accept: application/json, text/plain, */*
Authorization: Bearer eyJhbGciOiJFZER....
x-ledger: <ledger-handle>Cuerpo de respuesta:
{
"data": {
"handle": "alphanum.@kaminTestKey",
"wallet": "breb",
"target": "signer:wcDHYmSJP8uJF5dVGXBEKNA3e5hBm1eQEn@breb",
"schema": "breb-key",
"custom": {
"bankId": "901830825",
"status": "ACTIVE",
"firstName": "Alphanum",
"lastName": "Key",
"keyType": "ALPHANUM",
"keyValue": "@kaminTestKey",
"idType": "CC",
"idValue": "1088432333",
"targetSpbviCode": "TFY",
"bankAccountType": "SVGS",
"bankAccountNumber": "000202020"
},
"access": [
{
"action": "any",
"signer": {
"$record": "owner"
}
}
]
},
"hash": "9f770c6e10299cbff78e25ee7a455e1ce5f6da00bd2ee0fdaa6b0c7a4852f720",
"meta": {
"proofs": []
}
}En la respuesta se encuentra la resolución de la llave, esta contiene dentro del objecto data.custom
toda la data del dueño de la llave, finalmente la información de la cuenta destino, la cual
debe ser usada para genere un intent (transferencia) se ecuentra en el campo data.target
Los valores que pueden tener los campos resultos son:
| Nombre | Posibles valores |
|---|---|
| keyType | PHONE, ALPHANUM, NRIC, EMAIL , MERCHANT |
| idType | CC, CE, PA, TI, NUIP, NIT,PPT,PEP |
Tipos de cuenta bancaria
El campo bankAccountType retornado por la API de Anchor puede tomar cualquiera de los siguientes códigos, definidos por la regulación:
| Código(s) | Tipo de cuenta |
|---|---|
SVGS / CAHO | Cuentas de ahorro |
CACC / CCTE | Cuentas corrientes |
DBMO | Depósitos de bajo monto |
DORD | Depósitos ordinarios |
DBMI | Depósitos de bajo monto inclusivos |
Errores comunes
| Razón del error | Mensaje de error |
|---|---|
| bridge.unexpected-error | 121 - DICE error: The key does not exist or is inactive. 123 - DICE error: The key has been canceled and does not meet the minimum number of days to register again. 123 - DICE error: The key is suspended by the customer. |
¿Qué sigue?
Una vez que hayas recuperado un Anchor válido, puedes:
- Usar el valor
data.targeten intents tipo (B2P) SEND para un abono directo al beneficiario. - Construir validaciones previas en tu interfaz para confirmar si un usuario puede enviar o recibir fondos.
Buenas prácticas
- El formato de
data.targetpuede cambiar en el futuro. Usa el valor tal cual como es retornado. - No loguees PII completa: guarda nombre ofuscado y últimos dígitos de la cuenta.
- Aplica límites y controles antifraude antes de ejecutar el pago.
Historial de cambios
- Corregido• Se corrigieron enlaces que llevaban a la versión en español
- Cambiado• Se separaron los tipos de cuenta bancaria en una tabla con definiciones y se agregaron los códigos `CAHO` y `CCTE`.
- Agregado• Se reestructuró la sección de solicitud al formato canónico de endpoint y headers como bloques separados.
- Agregado• Se agregarón los errores comunes al resolver una llave
- Agregado• Se agregaron los valores posibles para keyType, idType, bankAccountType
- Cambiado• Actualización del objeto respuesta de la llave @kaminTestKey
- Agregado• Versión inicial