¿Qué es una pasarela de pagos? Cómo funcionan los pagos en línea, explicado
Una pasarela de pagos es el servicio que recoge de forma segura los datos de pago del cliente en el checkout, los pasa a los bancos y a las redes de tarjetas para su aprobación, y devuelve «aprobado» o «denegado», normalmente en unos pocos segundos. Es el puente entre tu app y el sistema financiero. Stripe, PayPal, Adyen, Square y Braintree son ejemplos conocidos.
Hoy en día, la mayoría de estas empresas agrupan la pasarela con todo lo demás que necesitas para cobrar, así que «pasarela de pagos», «procesador de pagos» y «proveedor de pagos» se usan a menudo para referirse a lo mismo.
Por qué importan las pasarelas de pagos cuando creas con IA
«Añade pagos» es una de las peticiones más comunes que la gente hace a los creadores con IA, y una de las más fáciles de hacer mal sin darse cuenta. El código en sí suele ser corto. Lo importante son las decisiones que lo rodean:
- Qué proveedor encaja con tu negocio, tu país y lo que vendes.
- Dónde se ejecuta el código. Las claves secretas de pago deben quedarse en el servidor, nunca en el navegador.
- Cómo sabe tu app que un pago se ha completado. La forma fiable es un webhook del proveedor, no que el cliente llegue a una página de «gracias».
- Tus responsabilidades legales y fiscales, que dependen de quién es el merchant of record.
Entender lo que hace una pasarela te ayuda a dar instrucciones claras y a comprobar que el resultado es seguro.
Una analogía cotidiana
Piensa en pagar con tarjeta en una tienda.
El datáfono del mostrador es la pasarela: lee tu tarjeta de forma segura y envía la petición. No decide nada: transmite la pregunta «¿puede esta persona pagar 40 €?» por una cadena hasta tu banco y recibe la respuesta. El banco de la tienda (adquirente) y tu banco (emisor) son los que deciden, a través de la red de tarjetas (Visa, Mastercard) que los conecta.
Una pasarela de pagos en línea es ese datáfono, rehecho para la web, con la seguridad necesaria para manejar datos de tarjeta que llegan por internet.
Cómo funciona un pago con tarjeta en línea
Esto es lo que ocurre en los pocos segundos posteriores a que el cliente pulse «Pagar»:
| Paso | Qué ocurre | Quién lo hace |
|---|---|---|
| 1. Checkout | El cliente introduce los datos de la tarjeta en un formulario de pago seguro | El formulario o la página de pago del proveedor |
| 2. Cifrado | Los datos se cifran y se envían a la pasarela | Pasarela |
| 3. Solicitud de autorización | La petición viaja a la red de tarjetas y al banco del cliente | Procesador, red de tarjetas |
| 4. Comprobaciones | El banco revisa los fondos y las señales de fraude, y puede pedir una verificación adicional como 3D Secure | Banco emisor |
| 5. Respuesta | La respuesta de aprobado o denegado vuelve a tu app | Pasarela |
| 6. Captura y liquidación | El dinero se cobra y, según el calendario de pagos del proveedor, se ingresa en tu cuenta bancaria menos las comisiones | Procesador, adquirente |
Hay dos puntos que conviene conocer:
- La autorización no equivale a estar cobrado. Primero se reserva el dinero, después se captura y finalmente se liquida en tu cuenta, a menudo días después.
- Tu app no debería ver nunca el número de la tarjeta. Los proveedores modernos ofrecen una página de pago alojada o campos integrados que ellos controlan, y tu app solo recibe una referencia al pago.
Las piezas principales y quién se ocupa de cada una
| Pieza | Qué es |
|---|---|
| Pasarela de pagos | Recoge de forma segura los datos de pago y los transmite. |
| Procesador de pagos | Mueve los datos de la transacción entre los bancos. |
| Cuenta de comerciante | La cuenta que recibe los pagos con tarjeta en tu nombre. La agrupan proveedores como Stripe. |
| Adquirente | El banco del lado del comerciante. |
| Emisor | El banco del cliente, que aprueba o deniega. |
| Red de tarjetas | Visa, Mastercard y otras, que conectan adquirentes y emisores. |
| Merchant of record | El negocio que vende legalmente al cliente y responde de impuestos, devoluciones y disputas. |
Algunos proveedores (Paddle, Lemon Squeezy) actúan ellos mismos como merchant of record, y se encargan del IVA y los impuestos de venta a cambio de comisiones más altas. Otros (Stripe, PayPal) te dejan a ti como merchant of record, con herramientas fiscales opcionales. Para una comparación equilibrada de las opciones, consulta Stripe frente a Paddle frente a Lemon Squeezy y Stripe frente a PayPal.
Un ejemplo práctico: vender un curso
Vendes un curso en línea por 99 € y pides a tu creador con IA que añada un botón «Comprar».
- El cliente pulsa Comprar. Tu servidor usa su clave secreta para pedir al proveedor que cree una sesión de pago de 99 € y recibe un enlace de vuelta.
- El cliente es enviado a la página de pago alojada del proveedor, introduce su tarjeta y completa la comprobación 3D Secure con su banco si se la piden.
- El pago se aprueba y el cliente es redirigido a tu página de «éxito».
- Por separado, el proveedor envía un webhook a tu servidor: «el pago de la sesión X se ha completado». Tu servidor comprueba la firma del webhook, localiza el pedido, lo marca como pagado y desbloquea el curso.
- Días después, el dinero menos las comisiones llega a tu cuenta bancaria.
El paso 4 es el más importante. Si desbloqueas el curso en la página de éxito, cualquiera que encuentre esa URL podría conseguirlo gratis, y los clientes cuyo navegador se cerró antes de tiempo pagarían y no recibirían nada.
Términos clave
| Término | Significado |
|---|---|
| Sesión de pago (checkout session) | Una página o flujo de pago de un solo uso que crea tu servidor para una compra concreta. |
| Modo de pruebas | Un entorno de prueba con claves de prueba y números de tarjeta de prueba; no se mueve dinero real. |
| Clave publicable / clave secreta | La clave publicable puede aparecer en el código del navegador; la clave secreta debe quedarse en el servidor. |
| 3D Secure | Un paso adicional en el que el cliente confirma el pago con su banco, habitual en Europa por las normas de autenticación reforzada (SCA). |
| PCI DSS | El estándar de seguridad del sector de tarjetas para quien maneja datos de tarjeta. |
| Contracargo | Cuando un cliente impugna un pago ante su banco y el dinero se le devuelve. |
| Devolución (reembolso) | Dinero que devuelves tú voluntariamente. |
| Liquidación (payout) | La transferencia que hace el proveedor de tu dinero cobrado a tu cuenta bancaria. |
Ideas erróneas habituales
- «Tengo que guardar los números de tarjeta para volver a cobrar a los clientes». No. Los proveedores guardan la tarjeta y te dan un token de referencia para los cobros repetidos y las suscripciones. Nunca deberías guardar tú los números de tarjeta.
- «La página de éxito significa que el pago funcionó». Confirma los pagos con webhooks en el servidor. Las redirecciones pueden saltarse, falsificarse o no producirse nunca.
- «Todos los proveedores de pago cuestan más o menos lo mismo». Las comisiones varían según el proveedor, el país, el tipo de tarjeta y si incluyen la gestión de impuestos. Revisa la página de precios actual de cada proveedor para tu país.
- «Usar Stripe me hace cumplir PCI». Simplifica mucho el cumplimiento, porque los datos de la tarjeta se quedan en el proveedor, pero aun así tienes una autoevaluación (normalmente breve) que completar.
- «El modo de pruebas y el modo real se comportan igual». Se parecen, pero el modo real necesita una cuenta totalmente verificada, endpoints de webhook configurados para el entorno real y datos bancarios reales.
- «Una pasarela de pagos se encarga de mis impuestos». Solo si actúa como merchant of record o si tú activas y configuras sus herramientas fiscales. Revisa la normativa local o consulta a un asesor.
Qué pedir a tu creador con IA
- «Añade Stripe Checkout para [producto]. Crea la sesión en el servidor usando la clave secreta de una variable de entorno.»
- «Marca los pedidos como pagados solo a partir de un webhook verificado, y comprueba la firma del webhook.»
- «Gestiona el caso de que el webhook llegue dos veces sin crear pedidos duplicados.»
- «Usa las claves del modo de pruebas y explícame cómo probar con las tarjetas de prueba del proveedor, incluida una tarjeta denegada.»
- «¿Qué pasa si el cliente cierra la pestaña después de pagar?»
- «Muéstrame cada lugar donde se usa una clave de pago y confirma que la clave secreta nunca llega al navegador.»
Pasarelas de pago en Mythex
Mythex no incluye pagos integrados de serie para las apps que creas, y no hay un botón de «Conectar Stripe» con un clic. Creas una cuenta con el proveedor que elijas, añades sus claves de prueba como secretos del proyecto y pides al agente que construya el checkout en el lado del servidor. Pruebas en la vista previa con las tarjetas de prueba del proveedor y luego publicas. La documentación lo explica en Aceptar pagos con Stripe, y Webhooks cubre el paso de confirmación.
Para una guía paso a paso, consulta cómo añadir pagos a tu app y, para la facturación recurrente, cómo añadir suscripciones con Stripe.
Preguntas
¿Qué es una pasarela de pagos en términos sencillos?
Una pasarela de pagos es el servicio que recoge de forma segura los datos de pago del cliente en tu checkout, los envía a los bancos y a las redes de tarjetas para su aprobación, y devuelve a tu app una respuesta de aprobado o denegado, normalmente en unos pocos segundos.
¿Cuál es la diferencia entre una pasarela de pagos y un procesador de pagos?
Estrictamente, la pasarela es la puerta segura que recoge y transmite los datos de pago, y el procesador mueve la transacción entre los bancos. En la práctica, los proveedores modernos como Stripe, PayPal o Adyen agrupan ambas cosas, además de la cuenta de comerciante, en un solo servicio, así que los términos se usan a menudo como sinónimos.
¿Necesito cumplir PCI para aceptar pagos con tarjeta?
Cualquier negocio que acepte tarjetas debe cumplir de alguna forma el estándar de seguridad PCI DSS. Usar una página de pago alojada o los campos de pago integrados del proveedor hace que los números de tarjeta nunca toquen tus servidores, lo que reduce mucho tu responsabilidad. Tu proveedor te indicará qué autoevaluación te corresponde.
¿Qué es un merchant of record?
Un merchant of record es el negocio que vende legalmente al cliente y se encarga de cosas como cobrar y pagar el IVA o los impuestos de venta, y de gestionar devoluciones y contracargos. Servicios como Paddle y Lemon Squeezy actúan como merchant of record por ti; con Stripe o PayPal, normalmente lo eres tú.
¿Puedo añadir pagos a una app creada con IA?
Sí. Un creador con IA puede escribir el código que conecta tu app con un proveedor como Stripe: crear sesiones de pago en el servidor, gestionar los webhooks y actualizar los pedidos. Aun así, necesitas tu propia cuenta con el proveedor y debes probarlo todo en su modo de pruebas antes de salir en vivo.