«Solo tiene que conectarse al sistema de pagos» es la frase que más a menudo precede a un retraso de tres semanas. Rara vez el problema es la programación; lo son la cuenta, la aprobación y las diferencias entre las pruebas y producción.
Por qué una integración no es una tarea pequeña
Conectarse a un servicio externo implica más que llamarlo:
- Creación y verificación de la cuenta con el proveedor, que a menudo exige documentos empresariales.
- Aprobación o revisión antes de que se conceda acceso a producción — especialmente en el caso de los proveedores de pagos.
- Gestión de credenciales, por separado para pruebas y producción.
- Gestión de todos los modos de fallo que puede producir el proveedor: rechazo, tiempo de espera agotado, éxito parcial, envío duplicado.
- Conciliación — comparar lo que el proveedor afirma que ocurrió con lo que registró su aplicación.
- Pruebas contra un entorno sandbox que se comporta de forma diferente a producción.
Los dos últimos puntos son donde se concentra el esfuerzo real, y son invisibles en una lista de funcionalidades.
Plazos de inicio para comenzar cuanto antes
Son tareas de calendario, no de desarrollo, y deberían comenzar al inicio del proyecto:
- Proveedores de pagos. Las solicitudes de cuentas comerciales requieren el registro de la empresa, datos bancarios y, en ocasiones, una revisión del modelo de negocio. Pueden tardar de días a semanas, y el rechazo es posible para algunas categorías empresariales — conviene confirmar la aceptación antes de diseñar en torno a un proveedor.
- Servicios de mensajería. En muchos mercados, los SMS requieren registrar el identificador del remitente y obtener la aprobación previa de las plantillas, un proceso formal con su propia cola.
- Integraciones con plataformas. Conectarse a un ecosistema establecido normalmente requiere una cuenta verificada y puede exigir una revisión del uso que se hará de ella.
- Sistemas empresariales. Conectarse al sistema existente de un cliente implica obtener acceso, documentación y un entorno de pruebas de un tercero cuyo calendario no se controla. Habitualmente, este es el punto que más tiempo requiere.
El sandbox no es producción
Los entornos de prueba están simplificados. Diferencias que suelen aparecer al ponerse en marcha:
- Los límites de solicitudes a menudo están ausentes o son generosos en el sandbox, y son estrictos en producción.
- La latencia es menor en el sandbox, por lo que los tiempos de espera agotados que nunca aparecen en las pruebas sí ocurren en producción.
- La variedad de errores es más limitada — los sandboxes producen un puñado de escenarios, mientras que producción produce muchos.
- La validación de datos a veces es más permisiva en el sandbox, por lo que los datos reales se rechazan por motivos que las pruebas nunca revelaron.
La mitigación práctica es realizar una prueba de humo en producción antes del lanzamiento: un pequeño número de transacciones reales, con credenciales reales, verificadas de extremo a extremo, incluida la conciliación.
Diseñar para los fallos que ocurrirán
En algún momento, una dependencia externa no estará disponible. Lo que debe ocurrir entonces es una decisión de diseño, no un accidente:
- ¿La acción del usuario falla o se pone en cola? Un pago debe fallar de forma clara. Una notificación puede ponerse en cola y reintentarse.
- ¿Qué ve el usuario? Un mensaje específico es mucho mejor que un error genérico y reduce la carga de soporte.
- ¿Es seguro reintentar la operación? Las API de pagos y mensajería suelen admitir una clave de idempotencia para que una solicitud reintentada no cobre dos veces. Usarla no es opcional en nada que implique dinero.
- ¿Cómo se detecta lo ocurrido? Los errores de una integración deben registrarse y generar alertas, no ignorarse silenciosamente.
Versionado y el cambio que no realizó
Los proveedores modifican sus API. Las versiones quedan obsoletas con previo aviso, y el aviso llega por correo electrónico a quien registró la cuenta — otra razón por la que el cliente debería ser el propietario.
Dos hábitos evitan la interrupción resultante: fijar una versión específica de la API en lugar de seguir automáticamente la última, y asegurarse de que la dirección de notificaciones de la cuenta llegue a alguien que actuará al respecto. Que una integración deje de funcionar porque una versión obsoleta se retiró según un calendario publicado es un fallo evitable.
Coste
Los servicios de terceros suelen cobrar por uso, y este suele ser el mayor coste recurrente de una aplicación pequeña. Conviene establecer antes de comprometerse:
- El modelo de precios — por transacción, por mensaje, por llamada a la API o por usuario activo.
- Si existe un nivel gratuito y qué ocurre al alcanzar su límite.
- Cómo aumenta el coste con diez veces el uso actual.
- Si existen mínimos o compromisos mensuales.
Una integración de IA o mensajería que resulta económica con el volumen de un piloto puede convertirse en el principal coste operativo a escala, y descubrirlo de antemano puede cambiar el proveedor elegido.
Servicios relacionados de Manboo
- Desarrollo de aplicaciones Flutter para MVP de iOS y Android.
- Desarrollo de software empresarial para sistemas de CRM, reservas, inventario y flujos de trabajo.
- Desarrollo de paneles de administración para paneles de operaciones y gestión del backend.
- Integración de API de IA cuando su producto esté listo para búsquedas inteligentes, chat o automatización.
- Solicite una revisión del alcance y un presupuesto del proyecto cuando esté listo para planificar la primera versión.