El problema que resuelve
Agregar un botón de pago es relativamente sencillo. Lo difícil es que el cobro quede bien conectado con la operación: que un pedido pagado no quede como pendiente, que un pago rechazado no despache productos, que un cliente que actualiza la página no pague dos veces y que, al final del día, lo cobrado coincida con lo que liquida la pasarela.
Cuando la integración se limita al flujo feliz, los problemas aparecen en los casos límite: conexiones que se cortan después del cobro, notificaciones duplicadas, reembolsos que no se registran o diferencias que hay que conciliar a mano.
Situaciones en las que resulta útil
- Tiendas online o plataformas de reservas que necesitan cobrar con tarjeta u otros medios digitales.
- Aplicaciones móviles con pagos dentro del flujo de pedido.
- Cobros mediante enlaces o códigos QR asociados a pedidos u órdenes.
- Plataformas que ya cobran, pero registran manualmente los pagos en su sistema de gestión.
- Cambio de pasarela o incorporación de un segundo medio de pago.
Servicio de integración y producto Paybridge: la diferencia
Esta página describe una capacidad de servicio: un proyecto en el que integramos la pasarela o las pasarelas que elija el cliente en su plataforma, adaptando el flujo a sus reglas de negocio. Paybridge, en cambio, es un producto de INTEDI: una capa propia y reutilizable pensada para concentrar la conexión con pasarelas de pago y evitar reconstruir esa lógica en cada proyecto.
| Aspecto | Servicio de integración | Producto Paybridge |
|---|---|---|
| Qué es | Un proyecto a medida. | Un componente de software propio de INTEDI. |
| Punto de partida | La plataforma y la pasarela que ya tiene o elige el cliente. | Una capa común que se conecta a la plataforma. |
| Cuándo encaja | Necesidades particulares o integración puntual. | Cuando conviene un punto único para gestionar cobros de una o varias plataformas. |
Cómo lo abordamos
- Flujo de negocioQué se cobra, cuándo y qué pasa después del pago.
- Modalidad de integraciónCheckout de la pasarela, formulario embebido o API.
- Estados del pagoPendiente, autorizado, pagado, rechazado, reembolsado.
- Confirmación por servidorWebhooks o consulta verificada, nunca solo la redirección.
- Pruebas en sandboxCasos exitosos, rechazos, duplicados y cortes de conexión.
- Producción y conciliaciónSalida controlada y cruce con los reportes de la pasarela.
Modalidades de integración
| Modalidad | Cómo funciona | Consideraciones |
|---|---|---|
| Checkout alojado por la pasarela | El cliente ingresa sus datos de pago en una página de la pasarela y regresa al comercio. | Implementación más simple; en general reduce la exposición del comercio a datos de tarjeta. |
| Formulario embebido o tokenización | Los campos de pago los provee la pasarela dentro del sitio y se obtiene un token. | Mejor experiencia sin que los datos de tarjeta pasen por los servidores del comercio. |
| Integración directa por API | El sistema del comercio envía los datos de pago a la API. | Mayor control, pero implica obligaciones de seguridad mucho más exigentes. |
Las condiciones concretas (medios disponibles, requisitos de seguridad, documentación, entornos de prueba) dependen de cada pasarela y de la afiliación comercial del cliente, por lo que se revisan al inicio de cada proyecto.
Consideraciones técnicas
- La redirección no confirma el pago. El navegador del cliente puede cerrarse o manipularse; la confirmación debe llegar al servidor por una vía verificable. Lo explicamos en webhooks de pago: confirmación, idempotencia y conciliación.
- Idempotencia: procesar dos veces la misma notificación no debe duplicar un pedido ni un registro contable.
- Montos y monedas: trabajar en la unidad mínima de la moneda (por ejemplo, céntimos) evita errores de redondeo.
- Tiempos de espera: si la pasarela no responde, el estado queda pendiente y se verifica después; nunca se asume rechazo ni éxito.
- Anulaciones, reembolsos y contracargos: deben tener su propio flujo y reflejarse en el sistema de gestión.
- Conciliación: un proceso periódico compara lo registrado con los reportes de la pasarela y señala diferencias.
Seguridad
El principio rector es no almacenar datos de tarjeta en los sistemas del comercio si no es estrictamente necesario: las modalidades con checkout alojado o tokenización están pensadas para eso. Además, las credenciales de la pasarela se guardan fuera del código, las notificaciones entrantes se validan con la firma o el mecanismo que provea la pasarela, y los registros nunca incluyen datos completos de tarjetas ni secretos. Las obligaciones de seguridad específicas aplicables al comercio deben confirmarse con la pasarela y con el adquirente.
Escalabilidad
En momentos de alta demanda, procesar las notificaciones de pago en segundo plano —responder rápido a la pasarela y luego actualizar pedidos e inventario— evita tiempos de espera y reintentos innecesarios. Las consultas a la pasarela deben respetar sus límites de uso.
Operación y mantenimiento
Una integración de pagos requiere vigilancia: alertas cuando aumentan los rechazos o dejan de llegar notificaciones, revisión de pagos que permanecen pendientes demasiado tiempo, conciliación periódica y seguimiento de los cambios de versión que anuncie la pasarela.
Preguntas frecuentes
¿Con qué pasarelas de pago trabajan?
La viabilidad se evalúa según la pasarela que el cliente tenga o elija, su documentación técnica y su entorno de pruebas. Preferimos confirmar cada caso antes que publicar una lista que pueda no corresponder a tu situación.
¿Mi plataforma guardará datos de tarjetas?
El diseño busca evitarlo usando el checkout de la pasarela o tokenización. Si un caso requiriera manejar datos de tarjeta directamente, implicaría obligaciones de seguridad adicionales que deben evaluarse antes.
¿Cuánto tarda en estar operativa una pasarela?
La parte técnica depende del alcance, pero la activación también depende de la afiliación comercial con la pasarela, un proceso que gestiona el comercio y que está fuera del control de INTEDI.
¿Qué pasa si el cliente paga y se corta la conexión?
Por eso la confirmación no depende del navegador: el servidor recibe la notificación de la pasarela o consulta el estado del pago, y el pedido se actualiza aunque el cliente no regrese al sitio.