¿Existe una pasarela de pago cripto para PrestaShop?

Payzum es un procesador de pagos cripto sin custodia y enfocado en stablecoins: los pagos se liquidan directo en wallets que controla el comercio. Su pasarela de pago cripto para PrestaShop es el módulo payzum, open source con licencia MIT en github.com/payzum-dev/prestashop-payzum. Esta guía explica por qué las tiendas PrestaShop suman stablecoins, seis preguntas para comparar cualquier módulo cripto y, después, la versión 1.2.0 paso a paso: instalación, ajustes y qué pasa exactamente en tu back office en cada etapa de un pago en USDT o USDC.

Por qué una tienda PrestaShop busca una pasarela de pago cripto

PrestaShop es el carrito gratuito y open source que miles de pymes alojan y gestionan por su cuenta. W3Techs lo sitúa en el 0,5 % de todos los sitios web y en el 2,8 % de los sitios con un sistema de e-commerce identificado (octubre de 2026). Muchas de esas tiendas venden fuera de su país, y ahí es donde la tarjeta sale más cara.

Toma las tarifas públicas de Stripe para España (consultadas el 2 de octubre de 2026). Una tarjeta europea estándar cuesta 1,5 % + 0,25 €. Una tarjeta europea premium cuesta 2,8 % + 0,25 €, y una tarjeta emitida fuera del EEE, 3,15 % + 0,25 €. La conversión de divisa suma un 2 % y cada disputa cuesta 20 €. Un pedido de 400 € de un comprador mexicano, con precio en dólares y liquidado en euros, paga 20,85 € de comisiones antes de salir del almacén, y el cobro puede revertirse durante meses.

Además, el checkout de PrestaShop es un objetivo comprobado. El 22 de julio de 2022, PrestaShop avisó de que los atacantes que tomaban el control de una tienda inyectaban un formulario de pago falso en la página de checkout para robar datos de tarjeta. En febrero de 2026 volvió a alertar a los comercios. Esta vez, un skimmer escondido en el archivo head.tpl del tema activo cambiaba los botones de pago reales por otros falsos que llevaban al comprador a un formulario de tarjeta falsificado. Un skimmer solo sirve si el comprador teclea su tarjeta en tu web.

Y luego están los compradores que prefieren no usar tarjeta: clientes mayoristas que pagan facturas en USDT, compradores a los que les rechazan la tarjeta desde el extranjero y comunidades cripto. Si vendes a Latinoamérica, muchos clientes ya guardan sus ahorros en dólares digitales. Sin una opción en stablecoins, abandonan el carrito o mandan una transferencia que tarda días.

Lo que cuesta un módulo cripto mal hecho en PrestaShop

Añadir cripto no elimina el riesgo por sí solo. Los módulos de pago fallan de formas muy propias de PrestaShop, y cada fallo cuesta dinero, stock o un fin de semana:

• Pedidos impagados bloqueando stock. Algunos módulos crean el pedido en cuanto el comprador hace clic, en un estado "en espera de pago". PrestaShop descuenta el stock al crear el pedido. Cada pago cripto abandonado deja productos fuera de venta hasta que alguien cancela el pedido a mano.
• Pedidos marcados como pagados por la página de vuelta. Si el módulo se fía de que el comprador vuelva a tu tienda, cualquiera puede simular esa visita. La confirmación cripto es asíncrona, y el navegador no es un testigo fiable.
• Dos pedidos por un pago. Los proveedores reintentan los webhooks. Dos entregas que llegan a la vez pueden leer "todavía no hay pedido" y crear uno cada una. Resultado: dos pedidos, dos emails de confirmación y el stock descontado dos veces.
• Se cobra un carrito y se envía otro. Mientras el comprador está en la página de pago, el carrito de PrestaShop sigue siendo editable. Si añade un producto en otra pestaña, un módulo ingenuo crea el pedido con el carrito más grande, aunque la factura cobró el más pequeño.
• Notificaciones falsificadas. Un webhook que se fía del ID de carrito que viene en la petición permite a cualquiera marcar un carrito como pagado. Hace falta verificar la firma y comprobar la clave segura del propio carrito.
• Un módulo anclado a una versión vieja. Un módulo escrito para un PrestaShop y un PHP antiguos, y nunca actualizado, se rompe en la siguiente actualización, justo cuando menos te conviene.
• Tu dinero en el saldo de otro. Las pasarelas cripto custodiales cobran tus ventas en su propia wallet y te pagan después, con su calendario, sus mínimos y su política de bloqueos.

Por qué los módulos de tarjeta, la transferencia y la cripto custodial se quedan cortos en PrestaShop

Los módulos de tarjeta están maduros, pero las reglas las pone la red de tarjetas. El adquirente retiene el dinero, decide cuándo lo liquida y puede recuperarlo con una disputa. Y un formulario de tarjeta en tu checkout mete esa página en el alcance de PCI DSS. Desde el 31 de marzo de 2025, los requisitos 6.4.3 y 11.6.1 de PCI DSS 4.0.1 obligan a inventariar y autorizar cada script de la página de pago y a revisar si ha sido manipulada al menos cada semana. Una página de checkout manipulada es justo como funcionaron las dos campañas contra PrestaShop.

La transferencia bancaria es gratis de instalar y lenta de gestionar. El módulo de transferencia que trae PrestaShop crea el pedido como "En espera de pago por transferencia bancaria" y te deja cuadrar cada ingreso con su pedido a mano. Una transferencia internacional tarda días y suele llegar con comisiones descontadas.

Los módulos cripto custodiales resuelven el cobro, no la custodia. El comprador paga a una dirección de la pasarela, la pasarela te acredita un saldo y tú retiras cuando te deja. Ese saldo es justo lo que un proveedor puede congelar, o perder si cierra.

La vía casera conserva la custodia y pierde todo lo demás. Una dirección de wallet en el email del pedido no da un importe único por pedido, ni detecta pagos de menos, ni cambia el estado del pedido. Alguien acaba cuadrando transacciones on-chain con referencias de pedido a mano.

Una tienda PrestaShop necesita un módulo que se comporte como cualquier otro método de pago en el back office, con su pedido, su registro de pago y su email de confirmación de siempre. Y que liquide como cripto: final, en segundos, en una wallet que controlas.

Cómo elegir una pasarela de pago cripto para PrestaShop: seis preguntas

Hay varios módulos cripto para PrestaShop. Seis preguntas separan el que puedes usar en producción del que te va a dar problemas. Házselas a cualquier proveedor, también a nosotros:

1. ¿Dónde se liquida el dinero? ¿En tu propia wallet, o en un saldo que guarda el proveedor y te paga después? Solo la primera opción deja el dinero fuera del alcance de un bloqueo.
2. ¿Qué crea el pedido y cuándo? La propia documentación para desarrolladores de PrestaShop dice que ningún módulo de pago debería crear un pedido antes de que el cliente pase por el servicio de pago. Busca un módulo que cree el pedido desde un webhook de servidor a servidor, con la firma verificada sobre los bytes originales de la petición y una ventana anti-repetición. La página de vuelta nunca debería contar.
3. ¿Se compara el importe con el carrito? El carrito sigue siendo editable mientras el comprador paga. El módulo debería comparar el importe y la moneda facturados con el carrito antes de crear el pedido.
4. ¿Qué pasa si el webhook llega dos veces, o dos a la vez? Busca deduplicación por ID de evento y un bloqueo por carrito. Sin las dos cosas, los reintentos se convierten en pedidos duplicados.
5. ¿Encaja con tu versión de PrestaShop y de PHP? Compara el rango de PrestaShop que declara el módulo y su requisito de PHP con tu instalación. PrestaShop 1.7.8 soporta PHP hasta la 7.4, y PrestaShop 8 recomienda PHP 8.1. Un módulo que necesita un PHP que tu PrestaShop no admite no es una opción, diga lo que diga su ficha.
6. ¿Puedes leer el código, y qué datos salen de tu tienda? El código abierto permite que tu desarrollador revise cómo se verifica el webhook y adónde va el dinero. Revisa qué datos de clientes envía el módulo. Y comprueba que la lista de monedas aceptadas la aplica el proveedor, no solo un ajuste en tu back office.

Nuestra guía de plugins de pago cripto open source convierte las preguntas 2, 4 y 6 en una auditoría de 15 minutos que puedes hacer sobre cualquier repositorio.

Cómo gestiona un pago en USDT el módulo de Payzum para PrestaShop

Es un módulo de pago estándar de PrestaShop. Hace dos cosas: convertir un carrito en una factura de Payzum y dejar que un webhook firmado, y nada más, convierta ese carrito en un pedido pagado.

En el checkout: una página alojada donde el comprador elige la moneda

El comprador elige Pay with Crypto / Stablecoins (Payzum), con el aviso "You will be redirected to a secure Payzum checkout", y confirma. Los textos del módulo vienen en inglés; puedes traducirlos con las traducciones de módulos de PrestaShop. El módulo crea una factura de Payzum por el total del carrito y en su moneda. El total viaja como un texto exacto, así que no se redondea por el camino. La referencia combina el ID del carrito con parte de su clave secreta, así que no se puede adivinar. Si el comprador vuelve y pulsa otra vez dentro de la misma hora, con el mismo carrito y el mismo total, recibe la misma factura en lugar de una segunda.

El comprador llega al checkout alojado de Payzum, con un código QR, una dirección de depósito y el estado en vivo. Ahí elige moneda y red y paga desde cualquier wallet, sin crear cuenta. Si Payzum no responde en ese momento, vuelve a tu checkout con un mensaje que le pide reintentar o elegir otro método.

El módulo no elige la moneda por el comprador. Con el ajuste Settlement currency en all (el valor por defecto), el checkout alojado ofrece solo los tokens que aceptas, que configuras en tu panel de Payzum en Merchants → Settings → Accepted tokens. Payzum aplica esa lista en su lado. Para la mayoría de tiendas eso significa USDT y USDC en redes rápidas y baratas: Solana confirma en unos 0,4 segundos, y Base y Polygon en unos dos. Si también aceptas otras criptomonedas, la conversión automática opcional a USDC o USDT está disponible en la mayoría de las redes soportadas.

El módulo registra solo dos hooks de PrestaShop: el de opciones de pago y el de retorno del pago. No carga ningún script ni hoja de estilos en tu tienda, así que no añade nada al inventario de scripts que exige el requisito 6.4.3 de PCI DSS.

Después del pago: el IPN firmado crea el pedido

Payzum avisa a tu tienda de servidor a servidor, a través del controlador IPN del módulo. Antes de leer un solo campo, el módulo verifica una firma HMAC-SHA-512 sobre los bytes originales de la petición con tu secreto de webhook. La comparación se hace en tiempo constante y se rechazan las repeticiones fuera de una ventana de 10 minutos. Una firma inválida recibe un 401 y no se toca nada. Después, el módulo reconstruye la referencia esperada a partir de la clave secreta del carrito. Una notificación que cita un carrito que no le corresponde también se rechaza.

A continuación toma un bloqueo de MySQL para ese carrito. Si otra entrega del mismo carrito sigue en proceso pasados 10 segundos, la segunda recibe un 503 y Payzum simplemente la reintenta más tarde. El nombre del bloqueo incluye el nombre de tu base de datos y el prefijo de tablas, así que una copia de staging en el mismo servidor MySQL nunca bloquea a producción. Cada ID de evento queda registrado en la tabla propia del módulo, payzum_ipn_event, y una entrega ya aplicada se confirma y se ignora.

Con un pago finished, el módulo compara el importe y la moneda facturados con lo que vale el carrito ahora, con medio céntimo de tolerancia por redondeo. Si coinciden, llama a la validación de pedidos estándar de PrestaShop. El pedido se crea como Pago aceptado. El ID de pago de Payzum queda como ID de transacción en la pestaña de pagos del pedido. Un mensaje privado en el pedido registra la moneda, la red, lo pagado y el total facturado. PrestaShop envía su email de confirmación en ese momento, con el pago ya firme. La ingeniería detrás de este patrón está en webhooks firmados para pagos cripto.

El cliente HTTP y la verificación de firma vienen del SDK oficial payzum/payzum-php. Va incluido en la carpeta vendor/ del módulo, así que no hace falta Composer.

Adónde va el dinero

Lejos de Payzum. El pago va de la wallet del comprador directo a la wallet que configuraste en tu panel, y el código del módulo no contiene ninguna dirección de wallet. No hay saldo en Payzum que retirar, congelar o esperar. El modelo está explicado en qué es un procesador de pagos cripto sin custodia.

Cómo configurar la pasarela de pago cripto en PrestaShop, paso a paso

Necesitas PrestaShop 8 con PHP 8.1 (la versión que PrestaShop recomienda para la rama 8) y HTTPS en tu tienda. Casi todo el tiempo se va en la prueba en staging, que es el paso que vale la pena hacer bien.

1. Prepara tu cuenta de comercio en Payzum. Regístrate en merchant.payzum.com. Añade la wallet en la que quieres cobrar y elige tus tokens aceptados, por ejemplo USDT y USDC en Base, Solana y Polygon. Crea una API key (64 caracteres hexadecimales) y apunta tu secreto de webhook (IPN).
2. Instala el módulo. Descarga payzum.zip desde la página Releases del repositorio. En tu back office, abre Módulos → Gestor de módulos → Subir un módulo y elige el archivo. El zip se descomprime en payzum/, que es como PrestaShop reconoce el módulo, así que no le cambies el nombre. Tampoco uses el botón verde "Download ZIP" de GitHub: se descomprime en prestashop-payzum-main/, que PrestaShop no acepta como este módulo. Desde la terminal, puedes clonar el repositorio en modules/payzum y ejecutar php bin/console prestashop:module install payzum.
3. Configúralo. Abre Módulos → Gestor de módulos → Payzum → Configurar. Pega la API key y el secreto de webhook, deja Settlement currency en all y pon Environment en Staging por ahora. Staging tiene sus propias API keys; una key de producción no funciona ahí.
4. Conecta el webhook. La página de configuración muestra la URL IPN de tu tienda. Cópiala en los ajustes de webhook de Payzum, como indica la propia página (el módulo también la envía con cada factura). Debe aceptar peticiones POST desde internet por HTTPS. Una tienda de pruebas detrás de una contraseña, una lista de IPs permitidas o el modo mantenimiento nunca recibirá el aviso.
5. Revisa las restricciones de pago. En Pago → Preferencias, comprueba que Payzum está activado para las monedas de tu tienda y para los países, grupos de clientes y transportistas a los que vendes. Payzum solo aparece en el checkout si la moneda del carrito está activada para él y hay una API key guardada.
6. Prueba en staging. Haz un pedido y llega al checkout alojado. En Pedidos todavía no aparece nada, y es lo esperado. Págalo y el pedido aparece como Pago aceptado, con la moneda y la red en un mensaje privado. Para probar la red de seguridad, abre la factura, añade un producto al carrito en otra pestaña y paga. No se crea pedido, y un error explica el motivo en Parámetros avanzados → Registros.
7. Sal en vivo. Cambia Environment a Production, pega tu API key y tu secreto de producción, y haz un pedido real pequeño.

La pantalla de configuración de un vistazo

A propósito, no hay ningún campo para la cabecera de la firma. La fija el SDK, así que nada en esta pantalla puede quedar desincronizado con tu cuenta.

Qué pasa en PrestaShop en cada estado del pago

Nada de esta tabla lo dispara el navegador del comprador. Una pestaña cerrada nunca pierde un pedido pagado, y una visita de vuelta falsa nunca crea uno sin pagar.

Lo que la versión 1.2.0 no cubre

• PrestaShop 1.7 en la práctica, y PrestaShop 9. El módulo declara compatibilidad con PrestaShop 1.7 a 8, pero necesita PHP 8.1, y PrestaShop 1.7.8 solo soporta PHP hasta la 7.4. En la práctica, eso significa PrestaShop 8. PrestaShop 9 es estable desde el 10 de junio de 2025, pero queda fuera del rango declarado, así que PrestaShop no instalará el módulo ahí.
• No aparece en Métodos de pago. PrestaShop solo lista en Pago → Métodos de pago los módulos referenciados oficialmente. Payzum se configura desde el Gestor de módulos; las restricciones de Pago → Preferencias se siguen aplicando.
• El stock no se reserva durante el pago. Como el pedido solo existe cuando llega el dinero, dos compradores pueden pagar la última unidad a la vez. Si vendes series limitadas, guarda un pequeño margen.
• Los descuadres necesitan a una persona. Si el carrito cambia a mitad del pago, el comprador igualmente pagó la factura. Lo concilias a mano: devuelves la diferencia o creas el pedido manualmente.
• Las devoluciones salen de tu wallet. El módulo no gestiona reembolsos. Devuelves las stablecoins tú mismo y registras la devolución en PrestaShop, por ejemplo con una factura por abono.
• Distribución. A 2 de octubre de 2026, el módulo se distribuye solo como release de GitHub, no en PrestaShop Addons ni en Packagist.

Casos de uso: tiendas PrestaShop que cobran en USDT y USDC

La configuración es la misma para todas. Lo que cambia es qué parte se paga sola.

• Fábrica de muebles que vende a América. Un taller de Valencia muestra precios en dólares a compradores de EE. UU. y México y liquida en euros. En un pedido de 1.200 € pagado con una tarjeta de fuera del EEE, las tarifas de Stripe para España suman 3,15 % + 0,25 € más un 2 % de conversión: 62,05 €. Pagado en USDC en Base, el pedido aparece como Pago aceptado segundos después de la confirmación, y la nota privada muestra la moneda y la red que usó el comprador.
• Tienda de electrónica tras la alerta de febrero de 2026. Una tienda de componentes de Madrid limpió un skimmer de su tema y quiere ofrecer a sus clientes habituales una forma de pagar sin teclear la tarjeta en la web. Payzum aparece como una opción de pago más, y el pago ocurre en la página alojada. Los métodos de tarjeta siguen en el alcance de PCI, pero cada comprador que cambia es una tarjeta menos tecleada en el checkout.
• Mayorista de cerámica de Castellón con clientes fuera de la UE. Un distribuidor de fuera de la UE hace un pedido de 14.000 €. Con una tarjeta de fuera del EEE costaría 441,25 € de comisiones, y una transferencia tardaría días. El distribuidor paga en USDT, pero su tesorería lo envía en dos transferencias. Tras la primera, PrestaShop no muestra ningún pedido. Tras la segunda, el pedido aparece una sola vez, pagado por completo y con el stock descontado una vez.
• Sello discográfico con ediciones limitadas. Un sello de Bilbao vende 300 copias de una reedición en vinilo. Con un módulo "en espera de pago", cada checkout cripto abandonado esconde una copia hasta que alguien cancela el pedido. Con Payzum, no hay pedido hasta que el pago es firme, así que las copias sin vender siguen a la venta. El sello guarda un margen de cinco copias para los compradores que pagan a la vez.

Payzum para PrestaShop frente a un módulo de tarjeta, la transferencia y un módulo cripto custodial

Comparados con criterios neutrales. Las cifras de tarjeta son las tarifas públicas de Stripe para España, consultadas el 2 de octubre de 2026.

Un servidor cripto autoalojado es otra opción razonable si no quieres a ningún tercero y tienes a alguien que lo mantenga. Payzum es para tiendas que quieren la misma custodia sin operar infraestructura de pagos. Y no tienes que quitar nada: la mayoría de tiendas añade Payzum como una opción más, junto a la tarjeta y la transferencia.

Objeciones frecuentes, resueltas

"Mis clientes no tienen cripto."

La mayoría no lo necesita. Payzum es una opción de pago más junto a tus tarjetas, no un reemplazo. Quienes la eligen son justo los que, si no, abandonarían el carrito, te mandarían una transferencia días tarde o pagarían con las tarjetas que más comisión te cuestan.

"¿Y la volatilidad? ¿Y MiCA?"

Tus precios siguen en la moneda de tu tienda. El módulo envía el total del carrito en su moneda, y el comprador paga el equivalente en la moneda que elija. Si aceptas solo USDT y USDC, recibes stablecoins en dólares. Si también aceptas otras criptomonedas, la conversión automática opcional a USDC o USDT está disponible en la mayoría de las redes soportadas. ¿Vendes desde la UE? Lee qué significa MiCA para los comercios y USDT vs USDC para cobrar antes de decidir qué tokens aceptar.

"Después de las alertas de skimming, no instalo módulos a ciegas."

Bien hecho, y no hace falta. La lógica del módulo son unas 640 líneas de PHP en tres archivos principales, más el SDK oficial incluido, todo público con licencia MIT. Registra dos hooks y no carga ningún script en la tienda. Tu API key nunca llega al navegador, y el código no contiene ninguna dirección de wallet. A Payzum solo le envía el total del carrito, la moneda, una referencia del carrito y tus URLs de retorno, sin datos personales del cliente. El controlador IPN rechaza las notificaciones sin firma o falsificadas antes de tocar un carrito.

"¿Cómo hago devoluciones si los pagos son finales?"

Devuelves los USDC desde tu wallet según la política de devoluciones que publiques, y registras la devolución en PrestaShop, por ejemplo con una factura por abono. Tú decides cuándo vuelve el dinero; no lo decide una red de tarjetas por ti.