¿Pierde conversiones por no ofrecer pagos inmediatos? Una fundadora de 38 años con tienda online en España y conocimientos técnicos medios ve clientes que abandonan la compra cuando Bizum y Redsys no están disponibles. La urgencia es real: necesita una solución rápida y segura hoy.
Se necesita integrar Bizum y Redsys rápido y sin riesgos: integración de pasarelas de pago españolas (Bizum, Redsys) con pasos mínimos, mínima programación, tiempos estimados (2–7 días), costes típicos, checklist de PSD2 y matriz DIY vs contratar. Al final habrá un plan concreto, snippets para los stacks habituales y pruebas obligatorias para no perder más ventas. Continúe con la primera sección para decidir rápido su siguiente paso.
Integración de pasarelas de pago españolas: factores que deciden
La decisión real se basa en tres variables: contrato TPV con el banco, capacidad técnica y volumen de ventas. Si falta el contrato, todo lo demás se puede detener durante días.
La segunda variable es PSD2/SCA. La autenticación reforzada puede cambiar el flujo de checkout. Hay que confirmar con la entidad cómo gestionan exenciones o 3-D Secure.
La tercera variable es la plataforma de la tienda. Plug-ins estándar aceleran la entrega. Integraciones a medida piden más tiempo y pruebas.
Acción inmediata: confirmar con el banco si el TPV admite Bizum y pedir tiempos de alta. Eso suele ser el cuello de botella y tarda entre 3 y 15 días hábiles.
Perfil: fundadora con TPV pendiente y urgencia alta
Situación: la fundadora no tiene TPV activo y pierde ventas por no ofrecer Bizum. Prioridad máxima: conseguir el TPV y poner Bizum en la opción de pago.
Paso 1: contactar al banco y pedir alta de TPV para comercio electrónico. Datos a facilitar: CIF, web, titular, cuenta bancaria y contrato firmado. El plazo varía según la entidad y la complejidad del alta; habitualmente tarda entre 3 y 15 días hábiles (la mayoría de comercios reciben el alta en 3–10 días, pero algunos bancos pueden tardar hasta 15 días cuando hay verificación adicional de documentación o condiciones especiales).
Paso 2: solicitar activación de Bizum para empresas o su integración vía Redsys. Preguntar plazos y coste de alta. Algunos bancos añaden una cuota de activación de 0–200 €.
Paso 3: mientras el banco tramita, preparar la tienda en sandbox. Instalar plugin de Redsys o dejar listo el endpoint de webhooks.
Advertencia: intentar activar Bizum sin TPV firmado provoca fracasos administrativos. No empezar la integración técnica hasta tener confirmación escrita del banco.
Perfil: tienda con TPV activo, quiere Bizum ya y mínimo código
Situación: TPV activo con Redsys pero sin Bizum. Ideal para integración rápida usando plugins.
Si la tienda usa WooCommerce o PrestaShop, instalar el módulo oficial de Redsys tarda entre 1 y 4 horas. Verificar que el plugin soporte Bizum. Muchas veces hay una casilla dentro del módulo para activar Bizum.
Si la tienda es Shopify, la integración puede limitarse por la plataforma. En ese caso valorar un PSP que actúe como intermediario.
Coste típico para esta ruta: 0–100 € por plugin más 0–200 € si el banco aplica tarifa de activación. Desarrollo adicional solo si el checkout es personalizado.
Errores y advertencias al integrar Bizum y Redsys
Error típico 1: usar credenciales de producción en sandbox o viceversa. Esto provoca firmas inválidas y pagos rechazados. Verificar siempre que la clave secreta corresponda al entorno.
Error típico 2: no probar notificaciones (webhooks) en sandbox. Resultado frecuente: pedidos marcados como pendientes aunque el pago esté en el banco. Probar webhooks con reintentos y respuesta 200.
Error típico 3: dar por hecho que todos los bancos soportan Bizum. Algunos bancos requieren un contrato adicional. Confirmar antes de tocar el código.
Trampa frecuente: copiar y pegar snippets sin enmascarar claves. Mantener claves en variables de entorno y nunca en el repositorio.
Guía práctica paso a paso para integrar Bizum y Redsys
Primera idea: dividir el trabajo en administrativo, técnico y pruebas. La parte administrativa con el banco suele tardar más que la técnica.
Paso 0, requisitos previos
- Tener dominio con certificado SSL válido. Sin HTTPS la pasarela rechazará las notificaciones.
- Contar con contrato TPV firmado y código de comercio suministrado por el banco.
- Acceso al panel de Redsys (entorno de pruebas y producción).
- Roles identificados: responsable de e-commerce, desarrollador o proveedor técnico y contacto en el banco.
Paso 1, alta y configuración del TPV en Redsys
- Acceder al panel de Redsys en entorno de pruebas.
- Anotar: código comercio, terminal, clave secreta y modo (PRUEBAS/PRODUCCIÓN).
- Configurar las URLs de notificación y retorno. https://midominio.com/api/redsys/notify.
- Marcar el método de integración (redirección o formulario embebido).
Tiempo estimado: 30–90 minutos si ya hay acceso. Error típico: introducir una URL local (http://localhost) que no es accesible desde Redsys.
Paso 2, activar Bizum (vía Redsys o contrato separado)
- Confirmar con el banco si Bizum se activa desde el TPV de Redsys o requiere contrato con Bizum Empresas.
- Proveer documentación fiscal y contrato de la tienda. Plazos: 2–10 días hábiles según entidad.
- En el panel de Redsys, activar la opción Bizum cuando el banco lo permita.
Consejo práctico: pedir al banco por escrito el tiempo estimado de activación. Eso evita llamadas y esperas innecesarias.
Paso 3, entorno sandbox y pruebas obligatorias
- Pedir credenciales de sandbox a Redsys y, si aplica, a Bizum empresas.
- Probar estos casos: pago autorizado, pago denegado, firma inválida, notificación tardía, reembolso.
- Probar webhooks con herramientas como ngrok para exponer el endpoint local y ver payloads.
Lista de pruebas críticas (cada una debe pasar):
- Autorizada y notificación recibida, pedido marcado como pagado.
- Denegada y pedido marcado como rechazado.
- Firma incorrecta causa rechazo y logging del evento.
- Reembolso exitoso refleja en el panel del comercio.
Paso 4, pasar a producción
- Cambiar claves a producción y verificar que las URLs de retorno y notificación estén en HTTPS.
- Coordinar la fecha y hora del cambio con el banco. Hacer despliegue fuera de horas pico.
- Monitorizar las primeras 48 horas para detectar reintentos o fallos de notificación.
Tiempo total típico: 2–7 días si el TPV ya está activo; si no, sumar 3–15 días para el TPV.
1. Contrato TPV
Alta con el banco (3–15 días).
2. Credenciales
Recoger código comercio y clave.
3. Sandbox
Probar pagos y webhooks.
4. Producción
Cambiar claves y monitorizar 48h.
Para quien ejecuta la integración, añadir capturas paso a paso acelera muchísimo el alta: capture la pantalla del panel de Redsys donde aparece el “Código Comercio” y la “Clave Secreta” (nombres exactos: Ds_MerchantCode/Ds_Merchant_Secret), otra del formulario donde se configura la URL de notificación (Ds_Merchant_UrlOK / Ds_Merchant_UrlKO) y una tercera del switch u opción que activa Bizum dentro del TPV. Incluya leyendas con el nombre del campo y un recuadro rojo alrededor del valor a copiar; por captura_01_redsys_codigo_comercio.png, captura_02_redsys_clave_secreta.png y captura_03_redsys_activar_bizum.png. Para Bizum Empresas, añada también la captura del panel de alta con los documentos requeridos para que el equipo administrativo no tenga que pedir aclaraciones al banco.
Estas imágenes reducen errores administrativos y guían a desarrolladores y responsables de e-commerce a localizar exactamente dónde pegar las credenciales y qué validar antes de pasar a producción.
Implementaciones y snippets: ejemplos para PHP, .NET, node y frontend
Todos los ejemplos usan valores ficticios de sandbox. Mantener claves en variables de entorno.
PHP — verificación de firma (ejemplo sencillo)
- php // Ejemplo básico de verificación HMAC SHA256
- $secret = getenv('REDSYS_SECRET')
- $datos = $_POST['Ds_MerchantParameters']
- $firma = $_POST['Ds_Signature']
- $calc = base64_encode(hash_hmac('sha256', $datos, base64_decode($secret), true))
- if ($calc !== $firma) { http_response_code(400)
- exit('Firma inválida')
- } // Actualizar pedido en la base de datos
error común en PHP: usar la clave codificada extra o sin base64. Probar con una transacción real en sandbox.
.NET — verificación y endpoint (resumen)
- Configurar appsettings.json con Redsys: CommerceCode, Terminal, Secret.
- Validar firma en el controller que recibe POST.
- Responder con texto "OK" o código HTTP 200 para confirmar recepción.
Node.js / Express, webhook idempotente
- js app.post('/webhook/redsys', async (req,res)=>{ const {Ds_Signature, Ds_MerchantParameters} = req.body
- if(!verifySignature(Ds_MerchantParameters, Ds_Signature)) return res.status(400).send('Firma inválida')
- const tx = parseParams(Ds_MerchantParameters)
- if(await pedidoYaProcesado(tx.order)) return res.status(200).send('OK')
- await actualizarPedido(tx)
- res.status(200).send('OK')
- })
Frontend, botón Bizum para checkout móvil
- Mostrar botón prominente en móvil: "Pagar con Bizum".
- Evitar pedir datos extra que no aporte la pasarela.
- Fallback: si la app Bizum no responde, ofrecer tarjeta como segunda opción.
Plugins y SDKs
- Usar el SDK oficial de Redsys si existe para la plataforma.
- En WooCommerce, preferir módulos con soporte activo y actualizaciones recientes.
- Tiempo estimado de integración con plugin: 1–4 horas.
Un bloque práctico sobre webhooks debe incluir un ejemplo real de payload y los pasos exactos de verificación. Por Redsys envía Ds_MerchantParameters (base64 JSON) y Ds_Signature (HMAC SHA256 sobre los parámetros). Flujo recomendado:
- Recepción: registrar raw-body y cabeceras
- Verificación: base64_decode(Ds_MerchantParameters) → parse JSON → calcular firma con clave (hash_hmac('sha256', Ds_MerchantParameters, base64_decode(secret), true) y base64_encode) y comparar con Ds_Signature
- Idempotencia: bloquear procesamiento si el order_id ya fue procesado usando un índice único (order + tx_id)
- Ack: devolver HTTP 200 con body corto y log. Añada ejemplos de reintentos (si el endpoint devuelve 5xx, Redsys suele reintentar; implemente backoff exponencial y marque en logs cada intento) y cómo manejar notificaciones tardías (p. ej. transacción autorizada enviada varias horas después): actualizar estado si la firma y el order_id coinciden y dejar un registro de conciliación con timestamp para auditoría
Webhooks, devoluciones y conciliación contable
Los webhooks son la única forma fiable de marcar pedidos como pagados cuando se usa redirección. Hay que diseñarlos desde el principio.
Diseño de notificaciones
- Redsys envía notificación al endpoint configurado.
- El endpoint debe verificar firma y actualizar estado del pedido.
- Implementar idempotencia para evitar duplicados.
Payloads y respuestas
- Simular payloads de autorizada y denegada. Registrar el cuerpo completo en logs cifrados.
- Para notificación aceptada devolver HTTP 200 y texto breve.
Reembolsos y cancelaciones
- Reembolso directo: usar panel de Redsys o la API si se dispone.
- Registrar reembolso en contabilidad con referencia de transacción.
- Chargebacks: notificar al departamento contable y preparar documentación.
Conciliación
- Mapear extracto bancario con referencia de Redsys: importe, fecha y número de terminal.
- Automatizar conciliación con herramientas que lean referencia de la pasarela.
- Rol recomendado: responsable de e-commerce y director financiero revisan diferencias semanalmente.
Checklist operativo (resumen)
- Verificar webhooks entregados diariamente.
- Revisar reintentos y errores de notificación.
- Auditar conciliación semanalmente.
En devoluciones y conciliación es útil un flujo operativo y ejemplos contables claros:
- supongamos una venta de 100 € con comisión bancaria del 1% y IVA 21%. Asiento de venta (al generar la factura): Debe Clientes 100 €, Haber Ventas 82,64 €, Haber IVA repercutido 17,36 €. Cuando el banco abona el neto tras comisión: Debe Banco 99 €, Haber Clientes 99 € (si se concilia a nivel de cobro). Si se hace un reembolso total desde Redsys (panel o API), el flujo inverso debe registrar: Debe Ventas devueltas 82,64 €, Debe IVA soportado 17,36 €, Haber Clientes 100 €, y, si la comisión no se devuelve, registrar Gastos bancarios 1 € (o ajustar cuenta de comisiones). Para chargebacks, cree un expediente con ID de transacción, copia de comunicación y fecha
- registre provisionalmente la devolución y reserve la posible comisión. Finalmente, automatice la conciliación con scripts que casen importe + referencia Ds_Order con el extracto bancario y marquen diferencias para revisión semanal
- incluya ejemplos de campos a usar: Ds_Order, Ds_Response, Ds_AuthorisationCode y fecha UTC de notificación
Seguridad y cumplimiento: PSD2/SCA, PCI, RGPD y checklist obligatorio
Reglas vigentes afectan la experiencia y la responsabilidad. En España conviene revisar las guías del Banco de España y de la AEB.
SCA / 3-D Secure
- 3-D Secure v2 es el estándar común para SCA. Redsys soporta 3DSv2.
- Preguntar al banco si aplica exenciones por bajo importe o transacción recurrente.
- UX: mostrar paso adicional solo si es necesario para reducir abandono.
PCI DSS y manejo de datos
- Para reducir alcance PCI, usar la página de pago alojada por Redsys.
- No almacenar datos de tarjeta en la tienda. Usar tokenización si se necesita cobranza recurrente.
RGPD / LOPDGDD
- Incluir los avisos de privacidad y finalidad en el checkout.
- Retención: conservar datos solo el tiempo necesario para conciliación y contabilidad.
Checklist de seguridad
- TLS 1.2+ en todo el dominio.
- Headers de seguridad y CSP básicos.
- Pruebas de vulnerabilidad antes de pasar a producción.
Plan de respuesta ante incidentes
- Información que pedir al banco y a Redsys: ID de transacción, logs de notificación y hora UTC.
- Notificar AEPD si hay fuga de datos personales.
Comparativa de bancos, comisiones y troubleshooting avanzado
| Banco / PSP |
Compatibilidad Bizum |
Tiempo alta TPV |
Coste alta (orient.) |
Comisión estimada (%) |
Observaciones |
| Banco Santander |
Alta común |
5–10 días |
0–150 € |
0.5%–1.0% |
Soporte técnico activo |
| BBVA |
Alta común |
3–8 días |
0–120 € |
0.5%–1.1% |
Buen portal de gestión |
| CaixaBank |
Alta común |
5–12 días |
50–200 € |
0.6%–1.2% |
Condiciones negociables |
| Stripe (PSP) |
Bizum no nativo |
Inmediato |
0 € |
1.4%–2.9% + fijo |
Alternativa donde Bizum no disponible |
Notas sobre datos: cifras orientativas en 2026. Las comisiones varían según volumen y negociación.
Errores frecuentes y diagnóstico rápido
- Firma inválida: comprobar clave secreta y entorno. Tiempo de verificación: 10–30 minutos.
- Notificaciones no recibidas: comprobar que la URL es pública y que no hay firewall bloqueando. Tiempo típico de arreglo: 30–120 minutos.
- Bizum no visible: verificar contrato con el banco. Esto suele tardar varios días.
Herramientas de troubleshooting
- ngrok para exponer endpoints locales.
- Logs con correlación por número de pedido y número de transacción.
- Capturas de Redsys con el ID de operación para escalar a soporte.
Preguntas frecuentes
¿Cómo puedo activar Bizum en Redsys?
Se activa tras confirmar el TPV con el banco.
Pasos: pedir al banco la activación Bizum para el comercio, esperar confirmación escrita y luego activar Bizum en el panel de Redsys. Plazos habituales: 2–10 días hábiles. Verificar que el módulo de la tienda tenga la opción Bizum y probar en sandbox antes de producción.
¿Qué es el método de pago Redsys?
Redsys es la plataforma de TPV que gestionan muchos bancos.
Actúa como pasarela que procesa tarjetas, devuelve notificaciones y permite integrar métodos locales. Redsys no es un PSP internacional; es la infraestructura que usan bancos españoles. Permite 3-D Secure y webhooks para conciliación.
¿Cómo vincular Bizum?
Vincular requiere el TPV activo y la autorización del banco.
El banco debe habilitar Bizum para la cuenta comercial. Tras esa autorización, se activa la opción en Redsys o se contrata Bizum Empresas. Luego, en la tienda, configurar el módulo para mostrar el botón Bizum y probar en sandbox.
¿Qué bancos son compatibles con Bizum?
La mayoría de bancos españoles principales son compatibles.
Entidades como Banco Santander, BBVA, CaixaBank, Sabadell y Bankinter soportan Bizum. Para confirmarlo conviene preguntar al gestor. En algunos bancos pequeños la activación puede requerir trámites adicionales.
¿Puedo ofrecer Bizum sin Redsys?
Sí, pero depende de la solución elegida.
Bizum ofrece soluciones para empresas directas y algunos PSPs soportan Bizum mediante integración propia. Si la tienda necesita mínima programación, lo habitual es pasar por Redsys o un PSP que gestione Bizum.
¿Cuánto tarda en llegar el dinero a mi cuenta?
La liquidación depende del contrato con la entidad.
Muchos bancos liquidan en 24–48 horas, pero hay contratos con liquidación semanal o mensual. Confirmar el periodo de liquidación y las comisiones con el departamento comercial del banco.
¿Qué hago si mis pagos son rechazados tras pasar a producción?
Revisar claves y notificaciones primero.
Comprobar que las claves de producción están correctas, que la URL de notificación responde con 200, y revisar logs de Redsys. Si todo parece correcto, escalar a soporte del banco con ID de transacción y capturas.
Recomendación final para la integración de pasarelas de pago españolas
Si la fundadora tiene capacidad técnica intermedia y TPV activo, seguir la ruta DIY con plugin y pruebas en sandbox. Tiempo total: 1–3 días.
Si falta el TPV o hay personal limitado, contratar a un desarrollador freelance por 200–1.200 € o una agencia para un paquete completo. Esto reduce riesgo y acelera la salida a producción.
Acciones concretas ahora mismo:
- Pedir al banco confirmación escrita de compatibilidad Bizum y tiempo de alta (3–15 días).
- Activar sandbox en Redsys y dejar el endpoint de notificación listo (30–90 minutos).
- Instalar el plugin correspondiente en la tienda y ejecutar las pruebas del checklist.
Para recursos oficiales y documentación del banco se puede consultar las páginas de Redsys y Banco de España: Redsys, Banco de España.
Plan mínimo de 72 horas: confirmar TPV, preparar sandbox, instalar plugin y hacer 8 pruebas críticas. Si algo falla, parar y revisar webhooks antes de producir.
