Buenas prácticas
Recomendaciones de producción para operar integraciones de Bre-B Participant.
Esta página reúne las prácticas operativas que diferencian una integración de Bre-B que funciona en sandbox de una que sobrevive en producción. Bre-B es 24/7 y en tiempo real — no hay una ventana batch nocturna donde los errores pasen desapercibidos. Las recomendaciones siguientes son cómo te mantienes fuera de problemas.
Si vas a desplegar Bre-B Participant a producción, trata esta página como checklist de lanzamiento y como referencia durante incidentes.
Esta página es un esqueleto de buenas prácticas. La versión completa incluirá ejemplos concretos, antipatrones y runbooks para los modos de falla más comunes en producción.
Siempre confirma con el pagador el nombre resuelto
Una llave de pago Bre-B es un alias. La resolución devuelve el nombre y banco del titular — muéstraselos al pagador y exige confirmación explícita antes de despachar. Esto es tanto un requisito de prevención de fraude como una expectativa regulatoria.
Idempotencia en cada despacho
Cada request de transferencia saliente debe incluir una clave de idempotencia. Un reintento de red sin ella es una transferencia duplicada.
Verifica las firmas de webhook
Cada webhook de Bre-B está firmado con HMAC-SHA256. Verifica la firma antes de confiar en el payload — ver Firmas de webhook.
Trata las respuestas síncronas como "aceptado", no "settled"
Un 200 de un despacho de transferencia saliente significa que Mono aceptó el request. El estado terminal llega por webhook. No acredites ni debites nada en tus libros hasta recibir el evento de settlement.
Maneja la máquina de estados completa
Las transferencias salientes de Bre-B atraviesan múltiples estados — pending, sent, accepted, settled, rejected. Mapea cada estado en tu aplicación. Surface los rechazos al usuario usando el catálogo de errores.
Concilia todos los días
Corre una conciliación diaria contra Mono. La naturaleza 24/7 de Bre-B hace que los problemas operativos se acumulen rápido sin ella.
Rota el client secret
Los tokens OAuth expiran automáticamente. Rota el client secret usado para emitirlos al menos cada 90 días e inmediatamente tras cualquier sospecha de exposición.
Antipatrones a evitar
- Saltarse la confirmación de nombre del target resuelto.
- Despachar sin clave de idempotencia.
- Confiar en un payload de webhook sin firmar.
- Tratar la aceptación del despacho como settlement.
- Hardcodear URLs de webhook sin un camino de rotación.