PIX, Open Finance y tu ERP: checklist técnico de integración en 2026

PIX (sistema de pagos instantáneos de Brasil) se volvió commodity. Open Finance está ramping up. Pero la integración técnica real de estos servicios con tu ERP custom o sistema empresarial todavía es zona gris: documentación fragmentada, bibliotecas variadas en calidad, regulación cambiando.

Esta es una guía técnica para arquitectos, devs y CTOs que van a integrar PIX y/o Open Finance en sistemas empresariales en 2026. Cubre arquitectura, seguridad, antifraude, elecciones de stack y trampas comunes. Sin relleno, con referencias reales.

Estado actual en 2026: qué cambió después de Open Banking → Open Finance

Para entender las decisiones de arquitectura, necesitamos el contexto regulatorio actual. Resumen de lo que está vigente en mayo de 2026:

• PIX: ahora 8 años en el aire, procesó 60 mil millones de transacciones en 2025. Plenamente maduro, con SLA del BC de 99,99%.
• PIX Automático (débito recurrente): lanzado en junio/2025. Permite débito recurrente autorizado por el cliente. Reduce necesidad de factura recurrente.
• PIX Internacional: piloto con 3 países (Argentina, Uruguay, Portugal) en 2026. Aún no producción general.
• Open Finance fase 4: compartición de datos de inversión, cambio, previsión. Fase 5 (seguros) en homologación.
• DREX (real digital): piloto Banco Central corriendo, aún sin producción para terceros.

Para sistemas empresariales, foco práctico está en PIX (cobro y pago) y Open Finance fases 1-3 (datos catastrales y transaccionales). DREX y Open Finance avanzado aún no justifican priorización técnica en 2026 para PYME.

Caminos de integración PIX: directo con BC vs gateway

Tienes dos elecciones arquitecturales para integrar PIX en tu sistema. La decisión tiene implicaciones de costo, complejidad y control.

Integración directa con Banco Central

Tu empresa se vuelve PSP (Proveedor de Servicios de Pago) o IF asociada. Consumes directamente APIs del BC (DICT, SPI). Control total, costo por transacción cerca de cero. Pero:

• Requisito: ser institución autorizada por el BC (raro para PYME)
• Complejidad altísima: certificación digital específica, ambiente regulado, auditoría
• Inversión: R$ 500k+ de desarrollo + R$ 50k+/mes de infra/compliance
• Cuándo vale: marketplaces con volumen gigante (1M+ transacciones/mes), fintechs

Integración vía gateway (recomendado para 99% de los casos)

Usas intermediario (Stark Bank, Gerencianet, Asaas, Iugu, MercadoPago, Pagar.me, o PSPs bancarias) que tiene la relación con BC. Consumes APIs de ellos (REST/HTTP simple).

• Setup: desarrollo de la integración, presupuestado por proyecto
• Costo: R$ 0,30 a R$ 1,50 por transacción (varía mucho)
• Complejidad: baja (REST API + webhooks)
• Plazo de implementación: depende del ERP, del gateway y del alcance; se define en la propuesta

Criterios para elegir gateway: costo por transacción en tu volumen, calidad de la documentación, latencia de las APIs, soporte técnico, conformidad fiscal (si es responsable por la factura electrónica del split), y política de chargeback/disputa (el punto más descuidado).

Seguridad técnica que no puedes ignorar

Integraciones PIX tienen requisitos de seguridad no negociables. Fallas en estos y tienes perjuicio real y proceso regulatorio.

mTLS (mutual TLS): comunicación autenticada

Toda comunicación con APIs PIX usa mutual TLS: además del servidor presentar certificado, tu cliente también presenta. Implementación:

• Generar par de claves y CSR (Certificate Signing Request)
• Enviar CSR al gateway/PSP para firma
• Configurar cliente HTTP con certificado + clave privada (Guzzle/PHP, Axios/Node, requests/Python)
• Rotar certificados cada 1-2 años (configurar alerta antes de expirar)

Webhooks firmados (JWS)

Cuando el gateway te notifica de un pago recibido, la notificación viene firmada digitalmente (JWS - JSON Web Signature). Verificar firma es obligatorio: sin eso, cualquiera puede mandar webhook falso a tu endpoint y marcar pedido como pagado.

• Endpoint webhook debe ser HTTPS, sin autenticación básica (clave compartida no basta)
• Validar JWS con clave pública del gateway antes de procesar
• Implementar idempotencia: webhook puede llegar 2-3x para el mismo evento
• Siempre confirmar status final vía GET después de procesar webhook (defensa en profundidad)

Idempotencia en todas las operaciones

Toda operación de cobro o pago PIX debe tener clave de idempotencia (UUID v4 por ejemplo). Sin eso, retry de cliente lento puede generar pago duplicado. Implementación en PHP: generar UUID en la sesión, persistir antes de llamar API, usar como header X-Idempotency-Key.

Log de auditoría completo

Cada llamada a API PIX debe generar log con: timestamp, payload (sin datos sensibles), respuesta, response time, user_id, IP. Mantén por mínimo 5 años (exigencia fiscal). Usa SIEM o herramienta equivalente.

Antifraude: donde la operación puede romper

PIX es instantáneo e irreversible. Diferente de tarjeta, no tiene chargeback automático. Fraude en PIX es dolor real:

• Smishing/Phishing: cliente cae en estafa, paga PIX a fraudador, después reclama contigo. Mitigación: educación + autenticación multifactor en checkout.
• Clave PIX clonada: fraudador cambia clave del destinatario en QR Code. Mitigación: usar PIX Cobrança (no clave suelta) con BR Code que valida ID.
• Pago duplicado: cliente paga 2x por error. Mitigación: idempotencia + confirmación clara.
• Devolución fraudulenta: cliente pide devolución después de recibir producto. Mitigación: política de devolución clara, registro de entrega.

Mecanismo del BC para eso es el MED (Mecanismo Especial de Devolución): cliente víctima de fraude puede pedir devolución en hasta 80 días. El banco del receptor (tú o tu cliente) puede tener valor revertido incluso sin culpa. Reservar provisión para eso es prudencia.

PIX Automático en el cobro recurrente: qué necesita el sistema

El PIX Automático funciona desde el 16 de junio de 2025. El cliente autoriza una sola vez el cobro recurrente en la app de su banco, y puede definir un valor máximo por pago; desde ahí cada cobro se agenda y se liquida en la fecha prevista, sin que abra la app todos los meses. El reglamento prevé cuatro jornadas de autorización: solicitud enviada por la empresa al banco del cliente, que confirma en la app (jornada 1); lectura de un QR Code solo con los datos de la recurrencia (jornada 2); QR Code que une la autorización y el primer pago inmediato (jornada 3); u oferta de la recurrencia después de pagar o agendar un cobro por QR Code (jornada 4).

La diferencia con el débito automático tradicional es el alcance: el débito automático depende de un convenio con cada banco, mientras que todo participante del PIX que ofrece cuenta transaccional está obligado a poner el PIX Automático a disposición de los clientes pagadores, y está prohibido cobrarle tarifa al pagador. Frente al boleto (título bancario brasileño), el cliente deja de pagar mes a mes: su banco agenda el débito y avisa antes. El control sigue con el pagador, que puede cancelar la autorización cuando quiera y cancelar un pago agendado hasta las 23h59 del día anterior.

Reglas que afectan a tu sistema

• Agendamiento: la instrucción de pago llega al banco del cliente entre 2 y 10 días corridos antes de la fecha de liquidación, para que sea avisado antes del débito.
• Reintento: si falta saldo o límite, el banco del pagador intenta de nuevo el mismo día (ventana de 18h a 21h). Después del vencimiento, la empresa puede reenviar el cobro en hasta 3 fechas dentro de 7 días corridos, siempre que la autorización prevea reintento.
• Cancelación: el pagador cancela un pago hasta las 23h59 del día anterior; la empresa puede cancelar un cobro hasta las 22h del día anterior. Después de eso, la empresa no puede cancelar ni el reintento.
• Valor máximo y límite: si el cobro supera el valor máximo definido por el cliente, no se agenda. El PIX Automático tiene límite diario propio, separado del límite PIX.

Qué necesita el ERP

• Integración con la API PIX del PSP o banco receptor para crear la recurrencia, generar los QR Codes de las jornadas y enviar los cobros recurrentes.
• Vínculo del txid al título: cada cobro lleva un identificador de la transacción (txid). Guardar ese txid en la cuota de cuentas por cobrar es lo que permite la baja automática sin que nadie revise el extracto.
• Calendario de envío: job que manda cada cobro dentro de la ventana de 2 a 10 días y controla los reintentos que permite la autorización.
• Baja y conciliación automáticas: webhook del PSP en cada liquidación, con job de verificación para cuando el webhook falle (el mismo cuidado descrito en la sección de seguridad).
• Estados de la autorización: autorización rechazada, expirada o cancelada por el cliente tiene que reflejarse en el registro y disparar el cobro alternativo (boleto o PIX suelto).

Los ajustes del Banco Central en 2026

En septiembre de 2026 el Banco Central divulgó las versiones 2.10.0 del Manual de Estándares para Iniciación del PIX (MPI) y de la API PIX, con mejoras técnicas en la gestión de recurrencias del PIX Automático y ajustes de texto para mayor claridad, a partir de lo que el BC observó en el primer año del producto. El MPI 2.10.0 fue divulgado por la Instrucción Normativa BCB 769, publicada en el Diario Oficial el 20/08/2026 y ya vigente. En la práctica: pregunta a tu PSP en qué versión de la API PIX está y si cambiaron los endpoints de recurrencia que usa tu sistema.

Open Finance: cuándo vale la pena hoy

Open Finance es Open Banking ampliado: datos de inversión, cambio, previsión, pronto seguros. Para empresa, casos de uso reales hoy:

Caso 1: Validación catastral acelerada

En vez de pedir comprobante de ingreso del cliente (PDF, scan, papel), conecta directo con banco de él vía Open Finance, recibe extractos validados. Reduce fraude documental y acelera onboarding.

Caso 2: Conciliación bancaria automática

Integración con banco de la empresa vía OF trae extractos en tiempo real para conciliación contable. Reduce horas de digitación financiera.

Caso 3: Crédito pre-aprobado para clientes

Caso B2C: cliente autoriza OF, tu empresa evalúa capacidad de pago de él en tiempo real, ofrece cuotas/crédito a medida.

Cuándo NO vale: si no tienes caso de uso claro que genere ROI medible. Open Finance tiene costo de desarrollo y costo de conformidad. Implementar sin propósito es money pit.

Stack: bibliotecas probadas en producción

Listas de bibliotecas que funcionan bien en producción en 2026, separadas por lenguaje.

PHP

• guzzlehttp/guzzle: cliente HTTP estándar, soporta mTLS vía context options
• firebase/php-jwt: verificación de JWT/JWS de webhooks
• gerencianet/gn-api-sdk-php: SDK oficial Gerencianet (sólido para PIX cobro)
• starkbank/sdk-php: SDK Stark Bank (excelente DX si los usas como gateway)
• ramsey/uuid: generación de claves de idempotencia

Node.js

• axios + https.Agent: mTLS vía agent option
• jose: verificación JWS robusta
• starkbank-sdk: Stark Bank Node
• iugu-node: SDK Iugu
• uuid: claves de idempotencia

Python

• requests + cert tuple: mTLS nativo
• PyJWT: JWS validation
• starkbank: SDK Stark Bank Python (referencia de calidad)
• cryptography: manipulación de certificados

"Integración PIX en ERP custom no es la parte difícil: la API es simple. La parte difícil es lo que nadie te cuenta: idempotencia, reconciliación periódica, tratamiento de webhook duplicado, política de provisión para MED, y flujo claro de error para el usuario. 70% de los problemas que veo en integraciones PIX son porque alguien ignoró uno de esos 5 ítems."

Checklist final de implementación

Antes de subir a producción, asegúrate de cada uno de estos ítems:

• ✓ mTLS configurado con certificado válido (y alerta de renovación configurado)
• ✓ Webhooks validando firma JWS antes de procesar
• ✓ Idempotencia implementada en todas las operaciones de pago/cobro
• ✓ Job de reconciliación corriendo cada 1-5min para cobros abiertos
• ✓ Logs de auditoría con retención de 5+ años
• ✓ Tratamiento de error con mensaje amigable al usuario (no exhibir trace técnico)
• ✓ Política de provisión para MED registrada con contabilidad
• ✓ Pruebas en ambiente sandbox de cada gateway antes de homologar producción
• ✓ Documentación técnica interna para que otro dev pueda mantener
• ✓ Plan de fallback si gateway primario cae (multi-gateway recomendado en volúmenes altos)

Conclusión

PIX en 2026 es técnicamente maduro y operacionalmente robusto. Quien aún no integró en su sistema empresarial está, literalmente, dejando dinero escurrir por la cañería de la morosidad y del roce de factura. Open Finance aún es más nicho: vale para casos específicos.

El éxito de la integración depende menos de la elección de gateway y más de la disciplina técnica: idempotencia, seguridad, reconciliación, observabilidad. Quien trata esto como proyecto serio tiene operación sólida. Quien trata como "ah, es solo una API REST" descubre los problemas en producción, con cliente bravo.

Preguntas frecuentes

¿Puedo integrar PIX sin tocar el banco de la empresa?

Sí, vía gateway de tercero (Stark Bank, Asaas, Iugu, MercadoPago, etc.). Recibes los valores en la cuenta de ellos, después transfieres a tu cuenta bancaria. No necesitas abrir cuenta nueva en banco específico. Costo: R$ 0,30 a R$ 1,50 por transacción, dependiendo del volumen.

¿Qué gateway es el mejor?

Depende del caso. Stark Bank tiene mejor DX para devs y API limpia; Gerencianet tiene costo competitivo en Brasil; Asaas es fuerte en recurrencia; MercadoPago para quien ya vende ahí. Para decidir, haz PoC de 1 semana en 2-3 y mide: latencia, calidad de documentación, soporte técnico real.

¿PIX Automático ya está disponible para empresa?

Sí desde junio/2025. Pero implementación todavía es restricta: no todos gateways soportan, y la UX en el app del cliente varía por banco. Recomendamos validar primero con 1-2 bancos donde tu base se concentra, antes de prometer "todo automático" comercialmente.

¿De qué depende el plazo de la integración?

De cuánto permite integrar el ERP actual (¿tiene API, base de datos accesible, código disponible?), del gateway elegido y del alcance: solo crear cobros y recibir webhooks es mucho menos trabajo que conciliación, MED, varios gateways y monitoreo. El plazo sale del análisis de tu sistema y queda por escrito en la propuesta. Desconfía de quien promete un plazo corto sin mirar el ERP: suele saltarse ítems de seguridad.

¿Open Finance es seguro para mis clientes?

Sí, dentro de los estándares del BC. El cliente siempre autoriza explícitamente la compartición, con plazo definido y revocable a cualquier momento. El riesgo es si implementas mal tu parte (no cifrar datos, filtrar tokens). Implementación seria con auditoría de seguridad independiente es mandatoria.

¿Cómo funciona la autorización del PIX Automático y el cliente puede cancelar?

El cliente autoriza una vez en la app de su banco, por solicitud enviada por la empresa o leyendo un QR Code, y puede definir un valor máximo por pago. Cada cobro se agenda de 2 a 10 días antes de la fecha y el banco avisa al cliente. Puede cancelar la autorización cuando quiera y cancelar un pago específico hasta las 23h59 del día anterior, y el banco no puede cobrarle tarifa. Para la empresa, lo esencial es que el sistema trate la cancelación y pase a otra forma de cobro.