Cobrar online: enlace de pago o checkout integrado, cómo decidir
Un enlace de pago suele ser la forma más rápida de cobrar cuando importe y concepto ya están acordados. Un checkout integrado compensa cuando la web debe calcular el pedido, conservar contexto y activar procesos sin intervención manual. La decisión incluye catálogo, reservas, conciliación y responsabilidades de seguridad; «integrado» no significa necesariamente capturar tarjetas en servidores propios.
Lo esencial, antes de empezar
- Elige por contexto y operación posterior, no por evitar una redirección.
- Un checkout creado por la app puede seguir alojado por el proveedor y conservar una referencia de pedido.
- La página de retorno no confirma el pago; usa el estado del proveedor y procesa eventos de forma idempotente.
- Alojado, iframe y captura directa reparten el alcance PCI y los controles de forma distinta; confirma la validación con proveedor y adquirente.
Distingue cuatro modalidades antes de comparar
| Modalidad | Quién crea el contexto | Dónde se capturan datos de pago | Uso habitual |
|---|---|---|---|
| Enlace compartible | Panel o API del proveedor | Página alojada por el proveedor | Concepto acordado, señal o inscripción |
| Checkout alojado | La aplicación crea una sesión | Página alojada por el proveedor | Pedido, carrito o reserva con referencia |
| Checkout embebido | La aplicación crea una sesión | Iframe o componentes del proveedor | Recorrido continuo con mayor integración |
| Captura directa propia | La aplicación y su servidor | Superficie bajo mayor control del comercio | Casos especializados con capacidad de seguridad y cumplimiento |
Stripe presenta sus Payment Links como páginas compartibles sin programación y su Checkout como formulario alojado o embebido. Son ejemplos de modalidades; funciones, métodos y disponibilidad dependen del proveedor, la cuenta, el país y la versión vigente.
Usa un enlace cuando el cobro ya está definido
- Hay pocos conceptos estables o el equipo acuerda antes el importe.
- Se cobra una señal, sesión, inscripción o factura concreta.
- No es necesario reservar stock o capacidad en tiempo real.
- La referencia disponible permite conciliar el pago con el caso interno.
- El volumen permite crear, revisar y desactivar enlaces sin perder control.
El esfuerzo inicial bajo no elimina el gobierno. Define caducidad, reutilización, importe fijo o editable, moneda, devoluciones, referencia, permisos para crear enlaces y respuesta ante un enlace enviado al destinatario equivocado. Evita publicar un enlace genérico cuando necesitas asociar cada pago a una deuda o persona concreta.
Integra el checkout cuando la web debe conservar reglas y estado
- El precio depende de cantidad, variante, impuestos, envío o descuento.
- Una reserva debe retener plaza o recurso mientras se paga.
- El cliente inicia sesión o el pago debe asociarse a una cuenta.
- El resultado crea pedido, acceso, factura o tarea automáticamente.
- Se necesitan conciliación por pedido, estados y embudo completo.
Más integración añade estados incompletos, reintentos, cambios de importe, cancelaciones, devoluciones y evolución de APIs. Una personalización total también aumenta pruebas de accesibilidad, móvil y mantenimiento. La guía de NAS sobre reservas con capacidad ayuda a separar retención, confirmación y liberación.
Reparte las responsabilidades de seguridad de forma explícita
Externalizar la captura reduce superficie, pero no elimina obligaciones del comercio: elegir y supervisar al proveedor, proteger cuentas administrativas y claves, mantener la web, controlar importes y referencias, revisar eventos y aplicar el método de validación PCI que corresponda. Este artículo no determina qué cuestionario o requisitos aplican a una empresa concreta; esa confirmación corresponde al adquirente y al proveedor de pagos.
| Modalidad | Responsabilidad principal del proveedor | Responsabilidad que conserva el comercio |
|---|---|---|
| Redirección a página alojada | Captura y procesamiento en su dominio | Seguridad de la web y cuenta, enlace correcto, pedido, conciliación y proveedor |
| Formulario completo en iframe | Todos los elementos de captura dentro del iframe | Página contenedora, scripts propios, integración, cuenta y controles exigibles al embebido |
| Componentes o campos separados | Tokenización y elementos proporcionados | Composición de la página, scripts, integración y alcance que resulte aplicable |
| Captura directa | Procesamiento contratado | Captura, transmisión, aplicación, infraestructura y alcance mucho mayor |
PCI SSC aclara que, para optar a SAQ A con un iframe, todos los elementos asociados a la captura de datos de tarjeta deben originarse directa y exclusivamente en proveedores validados, además de cumplirse el resto de criterios. El propio PCI SSC señala controles específicos para la página contenedora de formularios embebidos. Por eso «no tocamos la tarjeta» no basta como análisis de alcance.
La página de gracias no confirma el pago
El navegador puede cerrarse, perder conexión o volver a una URL manipulada. No marques un pedido como pagado solo por una redirección. Confirma con el proveedor y procesa el evento de forma idempotente: si llega dos veces, no debe duplicar pedido, plaza ni factura.
- 01
Crea referencia
Asocia pedido interno, importe y moneda esperados antes de enviar al pago.
- 02
Espera estado verificable
Distingue pendiente, requiere acción, pagado, fallido, cancelado y reembolsado según el proveedor.
- 03
Procesa una vez
Usa una clave estable para que reintentos y eventos duplicados produzcan un solo efecto.
- 04
Reconcilia
Compara pagos del proveedor con pedidos internos y revisa discrepancias.
La guía sobre webhooks y consultas programadas explica por qué un evento rápido puede necesitar una consulta posterior. Guarda referencias y estados, no datos de tarjeta innecesarios.
Prueba el flujo completo, incluido el fallo
- Verifica importe, moneda, impuestos y descripción visibles.
- Prueba pago correcto, cancelación, fallo, cierre del navegador y doble clic.
- Envía eventos duplicados y fuera de orden sin duplicar consecuencias.
- Comprueba caducidad de enlace o sesión y cambios de precio.
- Ensaya devolución, soporte y comunicación al cliente.
- Revisa permisos del panel, secretos, logs y rotación.
- Valida accesibilidad y móvil con los métodos realmente habilitados.
- Concilia una muestra de pedidos internos y pagos del proveedor.
Ejemplo hipotético: una academia puede empezar enviando enlaces individuales para un taller. Si después muestra veinte plazas en tiempo real, la aplicación debería crear una retención, confirmar con el proveedor y liberarla al caducar. El pago no puede ser el único registro del aforo.
NAS Solutions puede diseñar un cobro simple dentro de una web de conversión y delimitar cuándo el proceso ya necesita una app. La opción apropiada es la que conserva contexto y control con el menor alcance operativo suficiente.
Fuentes y referencias
Documentación oficial y referencias de mercado consultadas para verificar los puntos que cambian con el tiempo.
