Integrar código propio sin depender del proveedor

En tu empresa ya existen sistemas críticos que no pueden interrumpirse: ERP, contabilidad, plataformas de pagos y la comunicación con la SUNAT. Cuando decides que el nuevo software sea de tu propiedad, el reto no es solo el código, sino cómo se acopla a todo lo que ya usas. En este artículo verás paso a paso qué conversar con tu proveedor y qué requisitos técnicos cumplir para que la integración sea fluida y sin sorpresas.

Con qué se tiene que hablar

Antes de firmar cualquier contrato, haz un inventario detallado de los sistemas que seguirán operando. No se trata de listar hardware, sino de identificar los puntos de integración:

• ERP o sistemas contables (por ejemplo, SAP Business One, Contasis, o soluciones locales).
• Plataformas de gestión de inventario que ya están sincronizadas con tu almacén.
• Herramientas de CRM que alimentan a tu fuerza de ventas.
• Gateways de pagos y bancos que manejan la conciliación bancaria.
• Conexiones con la SUNAT para facturación electrónica y libros contables.

Para cada uno, anota:

1. Tipo de integración (API REST, SOAP, archivo plano, Webhook).
2. Frecuencia esperada (en tiempo real, cada 5 min, batch nocturno).
3. Volumen de transacciones (p.ej., 2 000 facturas al mes).
4. Requerimientos de seguridad (OAuth2, certificados X.509, IP whitelist).

Este mapa será la base para negociar los entregables y validar que el nuevo desarrollo pueda “hablar” con lo que ya funciona.

SUNAT y facturación electrónica

En Perú, la SUNAT exige que toda factura electrónica se genere, firme y envíe a través de un PSE (Proveedor de Servicios Electrónicos) certificado. Los puntos críticos son:

• Formato UBL 2.1 y código de respuesta obligatorio.
• Firma digital con certificado emitido por la SUNAT o por un tercero reconocido.
• Timbrado dentro de los 5 segundos posteriores a la generación, de lo contrario la factura se rechaza.

Los errores más frecuentes aparecen cuando el software nuevo:

• No incluye la validación de códigos de producto (SUNAT rechaza códigos fuera del catálogo).
• Envía archivos XML sin la firma electrónica correcta, provocando rechazo automático.
• No respeta el ciclo de vida de la factura (cancela, rectifica o anula fuera de los plazos permitidos).

Para evitar estos problemas, exige a tu proveedor que entregue:

1. Módulo de generación de XML certificado por la SUNAT, con pruebas unitarias que cubran al menos el 95 % de los escenarios de negocio.
2. Entorno de pruebas (sandbox) idéntico al de producción, con capacidad de validar contra el web service de la SUNAT.
3. Documentación de errores: códigos de respuesta, ejemplos de mensajes y guía de corrección.

Un proyecto típico de integración con la SUNAT lleva 3 a 4 semanas de pruebas intensivas, más 1 semana de ajustes finales antes del go‑live.

Cobros y bancos

En el ecosistema peruano, los pagos se realizan a través de varios canales: Yape, Plin, Niubiz, Izipay y los tradicionales transferencias interbancarias. Cada uno tiene su propio modelo de API y sus limitaciones.

• Yape y Plin: APIs REST con autenticación OAuth2. Permiten consultas de estado en tiempo real, pero limitan el número de transacciones a 5 000 por día por cuenta.
• Niubiz: Ofrece tanto REST como SOAP. Requiere certificado SSL mutuo y firma digital de cada petición. El tiempo de respuesta suele ser de 300 ms a 1 s.
• Izipay: API basada en webhooks; la confirmación del pago llega de forma asíncrona y debe gestionarse con una cola de mensajes (por ejemplo, RabbitMQ).
• Transferencias bancarias: La mayoría de los bancos peruanos exponen file transfer (CSV) o API de conciliación que se ejecutan en horarios nocturnos (02:00‑04:00 h).

Los errores típicos aparecen cuando:

• No se gestiona la idempotencia: un mismo cobro se envía dos veces y genera duplicados.
• Se ignoran los códigos de respuesta de los bancos y se asume que la transacción fue exitosa.
• Falta de reintentos exponenciales ante fallos temporales, provocando pérdidas de ingresos.

Para una integración robusta, solicita al proveedor:

1. Módulo de abstracción de pagos que encapsule cada API bajo una interfaz única.
2. Manejo de estados (pendiente, aprobado, rechazado, expirado) con persistencia en tu base de datos.
3. Pruebas de carga que simulen al menos 200 transacciones por minuto, para validar que la latencia del gateway no rompa el proceso.

En la práctica, la fase de pruebas de pagos ocupa 2 a 3 semanas, con un ciclo de corrección de 1 semana.

Qué pedirle al proveedor

La clave para evitar una dependencia excesiva está en definir claramente los artefactos de integración que el proveedor debe entregar. No basta con que el código sea tuyo; necesita estar bien documentado, versionado y con mecanismos de mantenimiento.

Especificaciones técnicas que no puedes omitir

• Versionado de API: Cada cambio debe seguir la convención MAJOR.MINOR.PATCH y mantener la retro‑compatibilidad al menos durante 6 meses.
• Contratos de datos: Especifica esquemas JSON Schema para cada payload; así cualquier sustitución de proveedor podrá validar los mismos contratos.
• Mecanismo de fallback: Si la API externa deja de responder, el sistema debe redirigir a una cola de mensajes y procesar cuando el servicio vuelva.
• Política de cambios: Define un SLA de notificación (mínimo 30 días) para cualquier ruptura de contrato o cambio de endpoint.

Qué ocurre cuando la otra parte cambia

Si tu proveedor decide actualizar su API (por ejemplo, Niubiz lanza una nueva versión), debes contar con:

1. Entorno de pruebas actualizado que refleje la nueva versión antes de la producción.
2. Plan de migración con pruebas de regresión que cubran al menos el 90 % de los casos de uso críticos.
3. Ventana de despliegue: reserva una ventana de 4 horas fuera del horario pico (por ejemplo, 02:00‑06:00 h) para aplicar cambios.

Sin estos acuerdos, cualquier cambio externo puede paralizar tus procesos de facturación o cobro, generando pérdidas operativas que pueden superar el 5 % de tu facturación mensual.

Conclusión

Quien ha leído hasta aquí entiende que la propiedad del código solo es útil si el software se comunica sin fricciones con los sistemas ya existentes. Identificar los puntos de integración, cumplir con los requisitos de la SUNAT, manejar correctamente los diferentes canales de pago y exigir entregables técnicos claros son pasos indispensables. Con un mapa de integración bien documentado y contratos de API robustos, tu empresa mantiene la autonomía del código y reduce la dependencia del proveedor a un nivel gestionable.