El cliente paga con Bizum, cierra la pestaña y llama porque su pedido sigue pendiente. Otra persona solicita devolver un artículo de una compra con varios productos. El equipo de atención encuentra el cobro en una pantalla, el envío en otra y una nota manual que nadie sabe si ya se ejecutó.
Una integración Bizum bien contratada conecta el pago con el ciclo comercial del pedido, incluida su devolución. Para una tienda española, la decisión no debería reducirse a qué botón aparece en el checkout. Hay que definir qué evidencia permite preparar el pedido, qué sucede cuando dos sistemas discrepan y quién puede corregir una situación sin cobrar o devolver dos veces.
Antes del desarrollo, confirma el camino comercial
La documentación de Redsys para Bizum describe su integración mediante TPV Virtual y contempla módulos de pago. Antes de construir una conexión propia, comprueba con tu entidad o proveedor qué servicio está habilitado para el comercio y qué capacidades ofrece tu plataforma actual.
Si un módulo mantenido resuelve el cobro, no tiene sentido rehacerlo solo por personalizar una pantalla. El desarrollo adicional puede centrarse en conectar pedidos, almacén, ERP y soporte. Pide al proveedor que identifique con precisión qué parte configura y qué parte va a desarrollar y mantener.
También conviene distinguir el pago comercial de otras formas de utilizar Bizum. El proyecto debe apoyarse en la integración contratada para tu tienda. Una transferencia manual acompañada de una captura no ofrece el mismo recorrido verificable entre autorización, pedido y devolución.
Separa pedido, intento de pago y devolución
Un pedido puede tener más de un intento de pago. Un intento puede quedar pendiente mientras llega la confirmación correspondiente. Y una devolución puede afectar solo a parte de la compra. Si todo se guarda en un campo llamado estado, el equipo acabará usando comentarios libres para explicar lo que la aplicación no representa.
Define tres registros relacionados: pedido comercial, operación de pago e instrucción de devolución. Cada uno necesita una referencia estable y un historial suficiente para saber qué ocurrió. El número que ve el cliente puede ser sencillo; la integración debe conservar además los identificadores que permiten buscar la operación en el proveedor.
No determines que un pedido está pagado únicamente porque el navegador llegó a una página de agradecimiento. La lógica del servidor debe verificar el resultado mediante el mecanismo documentado de la integración elegida. La vuelta del navegador sirve para orientar al usuario; no debe conceder por sí sola permiso para enviar mercancía.
Diseña el caso en que el cliente no vuelve
En la prueba de aceptación, cierra la pestaña después del paso de autorización. Después abre el pedido desde otra sesión. La tienda debe mostrar un estado coherente con la información verificada, aunque no se haya ejecutado la última pantalla del recorrido original.
Prueba también una notificación repetida, una llegada tardía y una interrupción del servidor durante el procesamiento. El mismo evento no debe crear dos envíos ni dos correos de confirmación comercial. La integración necesita recordar qué efectos ya ejecutó y permitir una recuperación controlada cuando el trabajo quedó incompleto.
Un estado incierto merece un mensaje honesto. Explica que se está comprobando el pago y permite consultar el pedido de nuevo. Evita invitar automáticamente a pagar otra vez si todavía puede existir una operación válida pendiente de reconciliar. El soporte debe disponer de una acción de comprobación, con registro de quién la utilizó y qué resultado obtuvo.
La devolución parcial necesita su propio recorrido
La documentación de devoluciones de Redsys diferencia devoluciones y anulaciones y describe operaciones totales o parciales. La disponibilidad concreta debe verificarse para tu configuración y método de pago; no asumas que todas las operaciones de una pasarela se aplican igual a todos sus productos.
En tu aplicación, la aprobación comercial de una devolución debe preceder a su ejecución financiera. Registra qué productos o conceptos la originan, el importe aprobado y la operación original. Antes de confirmar, muestra lo ya devuelto y lo que continúa pendiente. Una doble pulsación o dos personas trabajando sobre el mismo caso no deben superar el importe autorizado por el negocio.
El centro de ayuda de Bizum remite la devolución del producto a las condiciones del comercio. Tu portal tiene que comunicar esas condiciones y el estado real del proceso. Solicitud recibida, devolución aprobada y operación confirmada son mensajes diferentes.
La entrada de mercancía en almacén también es una decisión separada. Un artículo reembolsado puede requerir revisión antes de volver a estar disponible para vender. Evita que una acción financiera modifique automáticamente el stock si no existe una regla operativa que lo justifique.
Concilia las pantallas que utiliza tu equipo
Pide una vista que reúna referencias del pedido, operaciones, importes y pasos pendientes. El objetivo es que atención al cliente pueda explicar la situación sin compartir credenciales del portal bancario ni consultar registros técnicos sensibles.
Define qué sistema es responsable de cada información. El ERP puede dirigir la facturación; la tienda, la experiencia de compra; y el proveedor de pagos, el resultado financiero de una operación. Una conexión debe trasladar esos hechos sin convertir todos los sistemas en editores del mismo dato.
Incluye un informe de diferencias: pagos sin pedido correctamente asociado, pedidos marcados para preparar sin confirmación y devoluciones aprobadas que siguen sin resultado. Asigna una persona o equipo a cada tipo de excepción. Una lista de errores sin responsable solo cambia la ubicación del trabajo manual.
Qué debe demostrar el proveedor antes del lanzamiento
Utiliza el entorno de pruebas y los casos documentados por la pasarela. No uses compras reales como sustituto de una batería de aceptación. Acuerda con el proveedor comercial cómo validar finalmente la configuración de producción sin crear pedidos o comunicaciones accidentales.
- ▸Compra confirmada con cierre anticipado del navegador.
- ▸Operación rechazada con conservación del carrito cuando corresponda.
- ▸Confirmación tardía después de una pantalla de espera.
- ▸Notificación repetida sin efectos comerciales duplicados.
- ▸Devolución parcial y segunda solicitud sobre el mismo pedido.
- ▸Reintento después de una interrupción con resultado todavía incierto.
La entrega debe incluir las pruebas, la separación de credenciales por entorno y el procedimiento de recuperación. Mide las excepciones que requieren intervención y el tiempo que tarda soporte en aclararlas. No necesitas promesas de conversión sin evidencia para justificar una integración que elimina un problema operativo comprobable.
Nuestro artículo sobre portales de clientes multilingües ayuda a definir los mensajes posteriores a la compra. La guía para validar un proyecto tecnológico permite reducir el primer alcance antes de solicitar presupuestos.
TuniCyberLabs desarrolla aplicaciones e integraciones de software a medida. Para estudiar tu integración Bizum y ERP, comparte la plataforma de comercio, el proveedor de pagos y un ejemplo anonimizado de pedido difícil de conciliar. Podemos comenzar por ese recorrido y convertirlo en una prueba de entrega concreta.