Stripe para PrestaShop: guía completa de integración de pagos

Última revisión: junio de 2026, los requisitos del módulo de Stripe (Payment Intents API, eventos de webhook, sincronización de estados de pedido), los números de tarjetas de prueba, el comportamiento de SCA/3DS2 y el paso de verificación de dominio para Apple Pay descritos aquí están actualizados para PrestaShop 1.7, 8.x y 9.x. Las tarjetas de prueba y los nombres de eventos de Stripe proceden de su documentación actual; confirma cualquier dato relacionado con precios en tu propio panel de Stripe.

La mayoría de guías sobre Stripe para PrestaShop se quedan en "pega tus claves API y listo". Esa es la parte que casi nunca falla. Lo que falla, en silencio, días después de pasar a producción y dejar de vigilar, es el webhook que nunca se ejecutó, el pedido bloqueado en tierra de nadie con el dinero ya cobrado, el desafío 3D Secure que devolvió al carrito a un cliente dispuesto a pagar. Hacer que Stripe funcione en PrestaShop lleva diez minutos. Conseguir que concilie cada pago, reembolso y disputa en tu lista de pedidos, con la divisa correcta y resistiendo la próxima actualización del núcleo: de eso trata realmente esta guía de integración.

Este es el recorrido de implementación: elegir un módulo que encaje con la arquitectura de PrestaShop, conectar claves y webhooks correctamente, cumplir las normas europeas de SCA, activar Apple Pay y Google Pay, y detectar los fallos concretos que dejan pedidos de PrestaShop atascados. Si todavía estás decidiendo si Stripe es el procesador adecuado para ti, esa es otra cuestión: lo comparamos cara a cara con PayPal en Stripe vs PayPal, y lo analizamos frente al resto de opciones en los mejores módulos de pago para PrestaShop. Aquí damos por tomada la decisión: quieres Stripe y quieres integrarlo bien.

Elegir un módulo de Stripe que encaje con PrestaShop

Stripe en sí es solo una API. Lo que lo convierte en un botón de pago funcional, sincroniza estados de pedido y guarda datos de clientes en las tablas de PrestaShop es el módulo; y la elección del módulo importa más que cualquier cosa que hagas en el panel de Stripe. Dos requisitos técnicos determinan si merece la pena instalar un módulo:

• Debe usar la Payment Intents API, no la antigua Charges API. Payment Intents es la arquitectura actual exigida por Stripe para módulos preparados para SCA, y es lo que permite que la autenticación reforzada de cliente funcione automáticamente. Los módulos basados en el flujo antiguo de Charges (o Sources) están obsoletos y no encajan bien con SCA: evítalos. Si la descripción de un módulo sigue hablando de "Charges" o "tokens" sin mencionar Payment Intents, descártalo.
• Debe conciliar los pagos con los estados de pedido de PrestaShop. Que un pago se complete en Stripe es solo la mitad del trabajo. El módulo tiene que mapear ese éxito a un estado de pedido de PrestaShop (Pago aceptado), gestionar los reembolsos emitidos desde tu back office y guardar el ID de transacción de Stripe en el pedido. Los módulos que omiten esto te obligan a cruzar dos sistemas a mano cada vez que un cliente pregunta por un cargo.

El módulo oficial gratuito de Stripe cubre lo básico para un catálogo sencillo. Los módulos premium añaden tarjetas guardadas, botones de monederos exprés, validación de cupones en tiempo real y una vista de disputas/reembolsos dentro del propio PrestaShop. Ya desglosamos todo el panorama, gratis frente a premium, y qué aporta realmente cada nivel, en la comparativa de módulos de pago, así que no vamos a repetirlo aquí. La idea clave para esta guía: confirma Payment Intents y la sincronización de estados de pedido antes de instalar nada, porque añadir cualquiera de las dos cosas a posteriori es doloroso.

Paso 1, Configura y verifica tu cuenta de Stripe

Regístrate en stripe.com y completa la verificación de empresa antes de tocar PrestaShop: Stripe revisa tu sitio en producción y la aprobación de la cuenta puede tardar uno o dos días, así que empieza pronto. Necesitarás documentos de registro de la empresa (o identificación personal si eres autónomo), datos bancarios para los pagos y la URL de tu tienda en producción.

Cuando hayas entrado, ve a Developers → API keys. Verás dos conjuntos de claves: modo de prueba y modo en producción. Haz primero toda la configuración en modo de prueba: las claves de prueba procesan pagos ficticios sin mover dinero real, y no quieres descubrir un webhook roto con la tarjeta de un cliente real.

Paso 2, Instala el módulo e introduce tus claves

Sube el módulo desde Modules → Module Manager → Upload a module y abre su configuración. Todos los módulos de Stripe piden las mismas tres credenciales, y conviene entender qué es cada una para detectar cuándo algo está mal:

• Clave publicable (pk_test_… / pk_live_…): se usa en el navegador para renderizar el campo de tarjeta. Está diseñada para ser pública; exponerla no supone un problema de seguridad.
• Clave secreta (sk_test_… / sk_live_…): autentica las llamadas del servidor a Stripe. Esta clave nunca debe aparecer en código del lado del cliente ni en archivos del tema. El módulo la guarda en el servidor; si alguna vez ves una clave sk_ en el código fuente de una página, detente y rótala inmediatamente en el panel de Stripe.
• Secreto de firma del webhook (whsec_…): se configura en el siguiente paso. El módulo lo utiliza para demostrar que las llamadas de webhook entrantes proceden realmente de Stripe y no han sido falsificadas.

El error más habitual aquí es mezclar claves de prueba y de producción: una clave publicable pk_live_ con una clave secreta sk_test_ produce errores confusos de "no such payment intent". Mantén ambas claves en el mismo modo.

Paso 3. Configura los webhooks (aquí es donde fallan las integraciones con PrestaShop)

Los webhooks son la forma en que Stripe informa a tu tienda de cualquier cosa que ocurra fuera de la ventana de pago en tiempo real: un pago diferido que por fin se liquida, la apertura de una disputa, un reembolso procesado desde Stripe, la renovación de una suscripción. Sin un webhook operativo, tu tienda simplemente nunca se entera; por eso el síntoma clásico de una integración de Stripe rota es "el dinero está en Stripe, pero el pedido de PrestaShop sigue pendiente".

En el panel de Stripe, ve a Developers → Webhooks → Add endpoint. Apúntalo al controlador de webhook de tu módulo: en nuestro módulo Stripe Express Checkout, la URL sigue el patrón de front controller de PrestaShop y aparece impresa en la página de configuración del módulo para que puedas copiarla exactamente, sin adivinar. Suscríbete como mínimo a estos eventos:

• payment_intent.succeeded. Confirma que un pago se ha completado; mueve el pedido a Pago aceptado.
• payment_intent.payment_failed. Permite que la tienda reaccione a los rechazos en lugar de dejar un pedido fantasma.
• charge.dispute.created, muestra una devolución de cargo en cuanto se abre, mientras aún tienes tiempo de responder.
• charge.refunded, mantiene sincronizado un reembolso emitido desde Stripe con el pedido de PrestaShop.
• checkout.session.completed, necesario si usas el Checkout alojado de Stripe en lugar de un formulario integrado.

Copia el secreto de firma del endpoint (whsec_…) de vuelta en la configuración del módulo. Un módulo bien construido verifica esa firma en cada llamada (el nuestro rechaza cualquier solicitud cuya firma no valide con un HTTP 400 antes de tocar tu base de datos), de modo que un "pago completado" falsificado no pueda crear un pedido gratis. Después de guardar, envía un evento de prueba desde el panel de Stripe y confirma que el módulo lo registra. Si el webhook nunca llega, los culpables habituales son un cortafuegos o CDN (Cloudflare en particular) que bloquea la solicitud, una regla de .htaccess que tapa la URL del front controller, o un secreto de firma obsoleto: revisa Developers → Webhooks para ver intentos de entrega fallidos y consulta el registro de errores PHP del servidor.

[CAPTURA DE PANTALLA: La pantalla Add endpoint del panel de Stripe con la URL del webhook de PrestaShop introducida y los cinco eventos payment_intent / charge / checkout seleccionados en el selector de eventos]

Paso 4, Prueba todos los escenarios antes de pasar a producción

Stripe ofrece números de tarjetas de prueba que fuerzan cada resultado, para que puedas ejercitar todo el flujo sin dinero real:

Ejecuta cada caso y observa qué hace PrestaShop, no solo qué informa Stripe. El estado del pedido, el correo de confirmación, el ajuste de inventario y el registro de transacción en el back office tienen que quedar correctamente asentados. Este es el paso que la gente se salta, y es exactamente el paso que detecta el problema de webhook anterior antes de que lo haga un cliente.

SCA y 3D Secure 2: resuelto, si elegiste el módulo adecuado

La autenticación reforzada de cliente entró en vigor en todo el Espacio Económico Europeo el 14 de septiembre de 2019, aunque los reguladores concedieron un periodo de migración que escalonó la aplicación real hasta finales de 2020 (y hasta marzo de 2021 en el Reino Unido). Hoy ya está plenamente vigente, lo que en la práctica significa que muchos pagos europeos con tarjeta pueden requerir autenticación de dos factores mediante 3D Secure 2, mientras Stripe y el emisor deciden cuándo se aplican exenciones o flujos sin fricción. La parte tranquilizadora: si tu módulo usa la Payment Intents API (el requisito con el que abrimos), Stripe decide cuándo hace falta un desafío y ejecuta el flujo de autenticación por sí mismo. El trabajo de tu tienda consiste solo en gestionar la respuesta; por eso es tan importante probar la tarjeta 4000 0000 0000 3220 indicada arriba.

Hay tres comportamientos que conviene conocer para que no te sorprendan:

• Exenciones para importes bajos. Las transacciones pequeñas pueden optar a saltarse el desafío; Stripe solicita la exención automáticamente, pero el banco del cliente tiene la última palabra, así que no puedes depender de ello.
• Pagos recurrentes y tarjetas guardadas. El primer pago se autentica de forma interactiva; los cargos posteriores iniciados por el comerciante contra una tarjeta guardada no vuelven a pedir confirmación, algo importante si vendes suscripciones.
• Abandono durante el desafío. Una parte de los clientes abandona cuando aparece la ventana emergente de 3DS2. No puedes eliminarlo, pero una interfaz de autenticación rápida y con sensación nativa lo minimiza; otra razón por la que importa la calidad del frontend del módulo.

Activar Apple Pay y Google Pay

Apple Pay y Google Pay no son integraciones independientes de Stripe: se apoyan en los botones Payment Request / Express Checkout de Stripe. Actívalos y los compradores aptos verán un botón de monedero nativo que completa el pedido con huella o reconocimiento facial, en lugar de teclear una tarjeta. Para los clientes móviles en particular, eso elimina la parte más dolorosa del pago. (Nuestro módulo Stripe Express Checkout está diseñado precisamente para esto: puede colocar el botón de monedero en las páginas de producto, carrito y pago, de modo que un cliente recurrente pague en segundos sin entrar siquiera en el flujo tradicional.)

Apple Pay requiere un paso adicional que Google Pay no necesita: la verificación de dominio:

• Registra tu dominio en Settings → Payments → Payment methods → Apple Pay dentro del panel de Stripe.
• Sube el archivo de verificación de Stripe a yourstore.com/.well-known/apple-developer-merchantid-domain-association (los módulos bien hechos se encargan de esto por ti; confirma que el archivo sea accesible por HTTPS).
• Activa el botón Payment Request / monedero en los ajustes del módulo.

Google Pay no necesita ningún archivo: se activa en cuanto está habilitado el botón de monedero. Los botones de monedero son una de las mejoras de conversión móvil más claras para una tienda PrestaShop, aunque el tamaño de la mejora depende por completo de cuánto tráfico móvil tengas y de lo áspero que sea tu pago actual: mídelo en tu propia tienda en lugar de fiarte de un porcentaje llamativo.

Disputas y devoluciones de cargo

Aceptar tarjetas significa aceptar alguna disputa ocasional; el objetivo es que responder a una lleve cinco minutos, no una búsqueda a contrarreloj entre dos sistemas. Tres hábitos hacen la mayor parte del trabajo:

• Responde dentro del plazo de aportación de pruebas de Stripe. Dispones de un número fijo de días para enviar pruebas: confirmación del pedido, seguimiento del envío, confirmación de entrega y cualquier correspondencia con el cliente. Si se te pasa el plazo, la disputa se pierde por defecto.
• Usa Stripe Radar. Radar puntúa cada transacción por riesgo de fraude y puede bloquear o poner en cola las de mayor riesgo antes de que se conviertan en disputas; la versión básica está incluida, y puedes añadir reglas personalizadas en el nivel superior.
• Mantén las pruebas donde puedas encontrarlas. Un módulo que registra la transacción de Stripe en el pedido de PrestaShop, y muestra reembolsos y estado de disputas en el back office, evita que tengas que entrar en Stripe y cruzar números de pedido contra reloj. (Esto es una de las cosas que nuestro módulo Express Checkout trae al propio administrador de PrestaShop: cargos, reembolsos y datos de pago quedan asociados al pedido, así que las pruebas ya están reunidas.)

Mantener rápido el pago con Stripe

Una integración descuidada de Stripe puede añadir segundos al pago, justo el lugar donde menos puedes permitirte lentitud. Tres reglas lo mantienen ágil:

• Carga Stripe.js de forma asíncrona para que nunca bloquee el renderizado de la página.
• Inicializa el formulario de pago solo cuando haga falta: en el paso de pago, no en el carrito ni en cada página de producto.
• Usa el Payment Element de Stripe, su componente unificado actual, en lugar del antiguo Card Element. Una sola integración muestra entonces los métodos de pago relevantes para el país del comprador, tarjetas, monederos y métodos locales, sin rutas de código separadas.

Este último punto es donde Stripe se gana discretamente su sitio en tiendas transfronterizas: el mismo Payment Element puede presentar métodos locales que los compradores europeos esperan y en los que confían. Si tus clientes están en mercados con hábitos locales fuertes, merece la pena aprovecharlo: consulta cómo son esas expectativas en métodos de pago para el comercio electrónico europeo, el argumento de conversión para ofrecerlos en BLIK, iDEAL y Bancontact, y el ángulo de compra ahora y paga después (Klarna y similares, que Stripe también puede mostrar) en compra ahora, paga después. Para tiendas polacas en particular, si necesitas cobertura nativa completa de P24 o funciones específicas del mercado polaco, conviene comparar el soporte de Przelewy24 en Stripe con un módulo Przelewy24 dedicado, algo que explicamos en Przelewy24 para PrestaShop.

Dónde se encuentra Payment Element con el diseño de tu página de pago

Conectar Stripe correctamente consigue que el pago se liquide; el aspecto del paso de pago decide cuántos clientes llegan hasta él. Si quieres que el campo de tarjeta de Stripe, el botón de monedero Apple Pay / Google Pay y cualquier método local aparezcan dentro de un único paso de pago limpio en una sola página, en lugar de quedar dispersos por el pago predeterminado de varios pasos. Esa es una decisión de la capa del proceso de pago que acompaña a la conexión de Stripe, no una parte interna de ella. Nuestro módulo Checkout Revolution está diseñado exactamente para esa presentación en un solo paso, y nuestro módulo Stripe Express Checkout se encarga de la parte de Stripe por debajo. Usados juntos, el cliente ve un paso de pago simplificado con el botón de monedero arriba y las tarjetas debajo, mientras todo lo que has configurado en esta guía, webhooks, sincronización de estados de pedido, SCA, sigue conciliándose limpiamente en segundo plano.

Solución de fallos específicos de PrestaShop

Dinero en Stripe, pedido aún pendiente

Casi siempre es un problema de webhook: el endpoint no es accesible, está bloqueado o está firmado con el secreto equivocado. Revisa Developers → Webhooks para ver entregas fallidas, confirma que el secreto de firma del módulo coincide con el endpoint y asegúrate de que ningún CDN o cortafuegos esté interceptando la llamada. Este es el ticket de soporte número uno de Stripe en PrestaShop, y es la razón por la que existe el Paso 3.

Pedidos duplicados

Dos rutas crean el mismo pedido, el webhook y la redirección de vuelta desde el pago del cliente, o el cliente hace doble clic en pagar. Un módulo construido correctamente usa claves de idempotencia y comprueba si ya existe un pedido asociado al payment intent antes de crear uno nuevo. Si ves duplicados, el módulo no está deduplicando, y eso es un problema del módulo, no de configuración.

Desajustes de divisa

Stripe cobra en la divisa que le indiques. Si PrestaShop muestra un precio en EUR pero el módulo crea el payment intent en USD, al cliente se le cobra un importe distinto del que vio. El módulo debe leer la divisa activa del carrito y pasar exactamente ese código ISO a Stripe; compruébalo si gestionas una tienda multidivisa.

La lista de comprobación para pasar a producción

Antes de cambiar las claves de prueba por las de producción, confirma cada punto:

• Los cuatro escenarios con tarjetas de prueba funcionan: éxito, rechazo, desafío 3DS2, reembolso.
• Los webhooks están configurados y has visto llegar y procesarse un evento de prueba.
• El mapeo de estados de pedido es correcto (payment_intent.succeeded → Pago aceptado).
• Los correos de confirmación se envían después de un pago correcto.
• Un reembolso emitido desde el back office de PrestaShop llega a Stripe y actualiza el pedido.
• La verificación de dominio de Apple Pay está completa y el botón de monedero se renderiza en móvil.
• Stripe Radar tiene al menos una regla básica (por ejemplo, bloquear países a los que no envías).
• Todo el flujo funciona en un teléfono real, no solo en un navegador de escritorio.

Stripe es una opción predeterminada sólida para PrestaShop porque las partes difíciles, SCA, monederos, decenas de métodos de pago desde una sola integración, las gestiona la plataforma una vez que la conexión está bien hecha. La conexión es el trabajo, y consiste casi por completo en webhooks y sincronización de estados de pedido, que es donde un módulo nativo de PrestaShop se paga solo: nuestro módulo Stripe Express Checkout de mypresta.rocks verifica firmas de webhook, sincroniza cargos y reembolsos directamente con tus pedidos, y coloca el botón Apple Pay / Google Pay en las páginas donde los clientes están listos para comprar; así, la integración que configures hoy seguirá conciliándose correctamente mucho después de que dejes de vigilarla. Y como ofrecer los métodos que tus clientes realmente buscan es, en sí mismo, una palanca de conversión, conviene recordar por qué más opciones de pago significan más ventas cuando decidas cuáles activar.

Preguntas frecuentes

El pago aparece como correcto en Stripe, pero el pedido de PrestaShop sigue pendiente: ¿qué ocurre?

El webhook no está llegando a tu tienda. Stripe confirma cualquier cosa que ocurre fuera de la ventana de pago en tiempo real (una liquidación diferida, un reembolso, una disputa) llamando al endpoint de webhook de tu módulo; si ese endpoint no es accesible, está bloqueado por Cloudflare o por un cortafuegos, queda oculto por una regla de .htaccess, o está firmado con un secreto whsec_ obsoleto, PrestaShop nunca se entera de que el pago se ha liquidado. Abre Developers → Webhooks en Stripe y busca intentos de entrega fallidos, confirma que el secreto de firma del módulo coincide con el endpoint y revisa tu registro de errores PHP. Este es el ticket de soporte número uno de Stripe en PrestaShop.

¿A qué eventos de Stripe debe suscribirse el módulo de PrestaShop?

Como mínimo: payment_intent.succeeded (lleva el pedido a Pago aceptado), payment_intent.payment_failed (gestiona rechazos), charge.dispute.created (muestra devoluciones de cargo pronto) y charge.refunded (mantiene sincronizados los reembolsos del lado de Stripe). Añade checkout.session.completed si usas el Checkout alojado de Stripe en lugar de un formulario integrado. Suscríbete a esos eventos, copia el secreto de firma whsec_ del endpoint en el módulo y envía un evento de prueba desde el panel para confirmar que se procesa.

¿Tengo que hacer algo especial para SCA / 3D Secure 2?

No si tu módulo usa la Payment Intents API. Stripe decide cuándo se requiere un desafío 3D Secure 2 y ejecuta por sí mismo el flujo de autenticación; tu tienda solo gestiona la respuesta. Por eso el requisito de Payment Intents es lo primero que debes confirmar antes de instalar un módulo; un módulo que aún esté basado en la antigua Charges API puede gestionar mal la SCA europea. Pruébalo con la tarjeta 4000 0000 0000 3220, que fuerza un desafío 3DS2, y verifica que el cliente vuelve al pedido en lugar de al carrito después de autenticarse.

¿Por qué algunos clientes reciben errores "no such payment intent"?

Casi siempre por mezclar claves de prueba y de producción. Una clave publicable pk_live_ combinada con una clave secreta sk_test_ (o al revés) hace que Stripe busque un payment intent en el entorno equivocado, y eso se manifiesta como ese error. Ambas claves deben estar en el mismo modo. Vuelve a revisar las claves publicable y secreta en la configuración del módulo y asegúrate de que ambas sean de prueba o ambas de producción, según el modo en el que quieras operar.

¿Necesito una configuración separada para Apple Pay y Google Pay?

Ambos se apoyan en el botón Payment Request / Express Checkout de Stripe, así que activar ese botón activa los dos. El único paso adicional es solo para Apple Pay: la verificación de dominio. Registra tu dominio en Settings → Payments → Payment methods → Apple Pay en Stripe y asegúrate de que el archivo de verificación en yourstore.com/.well-known/apple-developer-merchantid-domain-association sea accesible por HTTPS (los buenos módulos lo colocan por ti). Google Pay no necesita archivo: se activa en cuanto está habilitado el botón de monedero.