Integrar una pasarela de pago en tu web o software
Integrar una pasarela de pago no es poner un botón: hay que elegir entre redirección o pago integrado, cumplir la autenticación reforzada, confirmar cada cobro por el aviso del proveedor, conciliar lo cobrado con pedidos y facturas y gestionar devoluciones y reclamaciones.
Para integrar una pasarela de pago en una web o en tu software hay que resolver cinco cosas: cómo paga el cliente (en la página del proveedor o sin salir de tu web), la autenticación reforzada que exige la normativa europea de pagos (PSD2), cómo se confirma cada cobro, cómo se concilia lo cobrado y cómo se gestionan las devoluciones.
Qué implica integrar una pasarela de pago
Una pasarela de pago (o TPV virtual) es el servicio que cobra la tarjeta u otro medio de pago en tu nombre y te liquida el dinero. Integrarla es conectar tu web o tu programa con ese servicio para que un pedido, una cuota o una factura se cobren y queden registrados sin intervención manual.
La conexión tiene dos caras. La visible es el formulario de pago. La que no se ve decide si el sistema es fiable: cómo se entera tu sistema de que el pago se completó, qué pasa si el aviso llega dos veces o no llega, cómo se registra una devolución y cómo cuadra todo con el banco.
Antes de programar, conviene tener claro qué medios de pago necesitas, si hay cobros recurrentes (cuotas o suscripciones) y si cobras por cuenta de terceros, como en un marketplace. Cada respuesta cambia la integración.
Redirección, formulario integrado o API
Hay tres formas de presentar el pago. La elección afecta a la experiencia del cliente y, sobre todo, a cuánta responsabilidad asumes sobre los datos de la tarjeta.
| Modo | Cómo funciona | Datos de tarjeta | Encaja cuando |
|---|---|---|---|
| Redirección | El cliente pasa a la página segura del proveedor y vuelve a tu web | No pasan por tu servidor | Buscas lo más sencillo y la estética es secundaria |
| Formulario integrado del proveedor | Los campos de tarjeta se cargan desde el proveedor dentro de tu página | Van directos al proveedor | Quieres que el cliente no salga de tu web |
| API con datos de tarjeta | Tu sistema recoge los datos y los envía al proveedor | Pasan por tu sistema | Casos muy concretos, con un equipo preparado para ello |
La diferencia importa por la norma PCI DSS, el estándar de seguridad del sector de las tarjetas. La documentación de Stripe, por ejemplo, explica que si tu empresa trata directamente datos sensibles de tarjeta puedes tener que cumplir más de 300 controles de seguridad de PCI DSS, mientras que las integraciones en las que los datos van directos al proveedor, sin pasar por tus servidores, reducen esas obligaciones. Salvo un motivo muy claro, tu sistema no debería ver nunca el número de tarjeta.
Autenticación reforzada (PSD2): lo que dice la norma
El Real Decreto-ley 19/2018 incorporó al derecho español, de forma parcial, la segunda directiva europea de servicios de pago (PSD2, Directiva (UE) 2015/2366). Su artículo 3 define la autenticación reforzada de cliente como la basada en dos o más elementos independientes de estas categorías: conocimiento (algo que solo conoce el usuario), posesión (algo que solo posee) e inherencia (algo que es).
El artículo 68 obliga a los proveedores de servicios de pago a aplicarla, entre otros casos, cuando el ordenante inicia una operación de pago electrónico, con las excepciones previstas en la norma técnica aprobada por la Comisión Europea (el Reglamento Delegado (UE) 2018/389). En los pagos remotos, la autenticación debe asociar dinámicamente la operación a un importe y a un beneficiario determinados.
Para quien vende hay un detalle que no conviene pasar por alto: según el artículo 46, que regula la responsabilidad en las operaciones de pago no autorizadas, si el beneficiario o su proveedor de servicios de pago no aceptan la autenticación reforzada, deben reembolsar el perjuicio financiero causado al proveedor del ordenante.
En la práctica, la autenticación la resuelven la pasarela y el banco del cliente (con tarjetas, habitualmente mediante 3-D Secure). Tu integración tiene que estar preparada para ese paso intermedio: un pago puede quedar pendiente de que el cliente lo confirme en la aplicación de su banco, y el pedido no se da por pagado hasta entonces. Qué excepciones aplica tu proveedor, y cómo afectan a los cobros recurrentes, lo documenta él: pregúntalo antes de diseñar el cobro.
Confirmar el cobro: los avisos del servidor
Uno de los errores más caros al integrar un pago es fiarse de la página de «pago correcto». El cliente puede cerrar el navegador antes de volver a tu web, o alguien puede llegar a esa página sin haber pagado. La confirmación válida es el aviso que el proveedor envía a tu servidor (lo que se suele llamar webhook o notificación en línea).
La documentación de Stripe lo resume en reglas que conviene aplicar con cualquier proveedor:
- Verifica la firma de cada aviso, para saber que viene del proveedor y que nadie lo ha alterado.
- Responde enseguida con un código de éxito y haz el trabajo pesado después.
- No des por hecho el orden: los avisos pueden llegar desordenados.
- Prepárate para duplicados: el mismo hecho puede notificarse más de una vez, así que procesar un aviso dos veces no debe crear dos pedidos ni dos facturas.
Si tu servidor no responde, el proveedor reintenta; en el caso de Stripe, durante un máximo de tres días en modo real. Los reintentos ayudan, pero no sustituyen a un servidor que responda: conviene actualizarlo sin cortes y revisar los avisos que han fallado.
Conciliación: que lo cobrado cuadre
Conciliar es comprobar que cada cobro de la pasarela corresponde a un pedido, una cuota o una factura de tu sistema, y que lo liquidado en el banco cuadra con lo cobrado menos comisiones y devoluciones.
- Guarda en cada pedido o factura el identificador del pago en la pasarela.
- Registra la comisión de cada operación, no solo el importe bruto.
- Cruza cada liquidación del banco con las operaciones que incluye.
- Revisa a diario los pagos sin pedido y los pedidos sin pago: son el síntoma de un aviso perdido.
Hecho así, el cierre de mes deja de ser una tarde de hojas de cálculo.
Devoluciones y reclamaciones
Una devolución puede ser total o parcial y se hace contra el pago original, normalmente desde el panel del proveedor o por su API. Tu sistema debe reflejarla en el pedido, en el stock si aplica y en la facturación. Si ya había factura, el Reglamento de facturación (Real Decreto 1619/2012, artículo 15) obliga a expedir una factura rectificativa cuando se modifica la base imponible, con las excepciones que el propio artículo recoge; tu asesor te dirá cómo aplica a tu caso.
Distinto es el contracargo: el titular de la tarjeta reclama el pago ante su banco. Según la documentación de Stripe, en ese caso el importe y una comisión por la disputa se descuentan del saldo del comercio, que puede responder aportando pruebas. Además, según el Real Decreto-ley 19/2018, el usuario obtiene de su proveedor la rectificación de una operación no autorizada o ejecutada incorrectamente solo si se la comunica sin demora injustificada y, en todo caso, dentro de los trece meses siguientes al adeudo (artículo 43); si el usuario no es consumidor, las partes pueden pactar otro plazo (artículo 34). Guarda las pruebas de cada venta: confirmación, entrega, comunicaciones y aceptación de condiciones.
WordPress, tienda online o software a medida
Si tu web es un WordPress con tienda online, lo normal es instalar el complemento oficial de tu pasarela. Para lo estándar sirve; lo que hay que vigilar es lo que queda alrededor: pedidos que se quedan en «pendiente» porque el aviso no llegó, cobros que no pasan a la gestión o devoluciones hechas en la pasarela que la tienda no refleja.
Si el cobro tiene que llegar a tu programa de gestión, o cobras cuotas, reservas o servicios, una integración a medida da control sobre cada estado. Si además tienes tienda física, el pedido pagado debe descontar stock: lo contamos en sincronizar stock entre tienda física y online. Para cobros recurrentes, lee plataforma de suscripciones, y si cobras por cuenta de varios vendedores, cómo crear un marketplace.
Lista de comprobación antes de cobrar de verdad
- Contrato con la pasarela firmado y medios de pago decididos.
- Modo de integración elegido sin que los datos de tarjeta pasen por tu servidor.
- Pagos probados en el entorno de pruebas del proveedor: aceptados, rechazados y con autenticación.
- Avisos con firma verificada, registrados y procesables dos veces sin efectos dobles.
- Pedido y factura vinculados al identificador del pago.
- Devoluciones totales y parciales probadas de principio a fin.
- Alertas de pagos sin pedido y de pedidos sin pago.
- Claves de la pasarela fuera del código y cambiadas si alguna vez se exponen.
En nuestros productos, el cobro con tarjeta forma parte del alta y de la suscripción. Más sobre cómo conectamos sistemas en desarrollo de software a medida.
Fuentes consultadas
Comprobadas el 26 de septiembre de 2026. Enlazamos la fuente original para que puedas consultar el texto vigente.
- Regulatory Technical Standards on strong customer authentication and secure communication under PSD2. Autoridad Bancaria Europea (EBA).
- Real Decreto-ley 19/2018, de 23 de noviembre, de servicios de pago y otras medidas urgentes en materia financiera (texto consolidado). BOE.
- Real Decreto 1619/2012, Reglamento por el que se regulan las obligaciones de facturación (texto consolidado, artículo 15). BOE.
- Guía de seguridad de la integración (PCI DSS). Stripe (documentación oficial).
- Recibir eventos en un endpoint de webhook. Stripe (documentación oficial).
- Disputas (contracargos). Stripe (documentación oficial).
- Autenticación mediante 3D Secure. Stripe (documentación oficial).
Preguntas frecuentes
¿Cómo integrar una pasarela de pago en WordPress?
Con el complemento oficial de tu pasarela para la tienda. Después, prueba en el entorno de pruebas los pagos aceptados, rechazados y con autenticación, y comprueba que el pedido cambia de estado con el aviso del servidor y no solo cuando el cliente vuelve a la web.
¿Qué conviene más, redirección o pago integrado?
La redirección es lo más sencillo y deja los datos de tarjeta en el proveedor. El formulario integrado del proveedor mantiene al cliente en tu web con una responsabilidad parecida. Recoger tú los datos de tarjeta multiplica los requisitos de seguridad y rara vez compensa.
¿Qué es la autenticación reforzada de cliente?
Es la verificación con dos o más elementos independientes de tres categorías: algo que solo conoces, algo que solo tienes y algo que eres. La normativa de servicios de pago la exige, entre otros casos, al iniciar un pago electrónico, con las excepciones que fija la norma técnica europea.
¿Qué es un webhook de pago?
Es el aviso que la pasarela envía a tu servidor cuando pasa algo con un pago: cobrado, fallido, devuelto o reclamado. Es la fuente fiable para marcar un pedido como pagado, siempre que verifiques su firma y toleres avisos repetidos o desordenados.
¿Algo de esto encaja con tu negocio? Cuéntanos cómo lo haces hoy.