¿Cuál es el mejor plugin de pagos cripto para Magento 2?

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 plugin de pagos cripto para Magento 2 es el módulo Payzum_CryptoPayments (paquete de Composer payzum/module-crypto-payments), open source con licencia OSL-3.0 en github.com/payzum-dev/magento2-payzum. Esta guía te da primero una forma neutral de comparar cualquier módulo cripto para Magento y después recorre la versión 1.2.0, cuyo zip de release se publicó el 28 de septiembre de 2026: instalación, configuración y qué le pasa al pedido en cada paso de un pago en USDT o USDC.

Por qué las tiendas Magento suman USDT y USDC al checkout

Magento no es el carrito más usado por cantidad de sitios. W3Techs ubica a Adobe Commerce (Magento) en el 0,3% de todos los sitios web y en el 1,6% de los sitios con un sistema de e-commerce identificado (1 de octubre de 2026). Pero es el carrito que eligen los comercios que venden de forma compleja: listas de precios B2B, varias vistas de tienda y monedas, catálogos grandes e integraciones con ERP y almacén. Una tienda así, en Ciudad de México, Bogotá o Madrid, vende fuera de su país, y el cobro internacional es justo donde la tarjeta sale más cara.

Como referencia, PayPal Braintree publica para EE. UU. (consultado el 1 de octubre de 2026) 2,89% + 0,29 USD por transacción con tarjeta, 1% adicional si la tarjeta se emitió fuera de EE. UU., otro 1% si la venta es en una moneda distinta del dólar y 15 USD por contracargo. Una venta en euros pagada con tarjeta extranjera cuesta 4,89% + 0,29 USD antes de despachar nada. Las pasarelas locales de LATAM y de España tienen sus propias tarifas, pero la lógica del cobro internacional con tarjeta es la misma, y el dinero sigue siendo reversible durante meses.

Los comercios Magento cargan además con un costo de la tarjeta que casi nunca aparece en la tabla de comisiones: la propia página de checkout es un blanco. En el verano boreal de 2024, atacantes explotaron CosmicSting (CVE-2024-34102), una falla que Adobe parcheó el 11 de junio de 2024. Sansec informó el 1 de octubre de 2024 que siete grupos habían hackeado 4.275 tiendas y que el cinco por ciento de todas las tiendas Adobe Commerce y Magento terminó con un skimmer de pagos en su checkout. Un skimmer solo rinde si los compradores escriben números de tarjeta en tu sitio.

Además están los compradores que directamente no quieren pagar con tarjeta: clientes mayoristas que liquidan facturas grandes en USDT, compradores cuya tarjeta rebota en el exterior, comunidades cripto. Para ellos, un checkout sin opción en stablecoins es un carrito abandonado, o una transferencia que tarda días en llegar.

Lo que le cuesta a una tienda Magento un módulo cripto mal hecho

Sumar cripto no elimina el riesgo por sí solo. Los módulos de pago fallan de formas propias de Magento, y cada falla cuesta dinero o un fin de semana:

• Pedidos que nadie puede pagar. Muchos métodos de pago externos crean la factura en una segunda petición del navegador, después de que Magento registra el pedido. Si en el medio falla el correo de confirmación, se agota el tiempo o el comprador cierra la pestaña, el pedido existe y la factura no. Queda en Pendiente para siempre y nada lo avisa.
• Pedidos marcados como pagados por la página de éxito. Si el módulo confía en que el comprador llegue a checkout/onepage/success, cualquiera puede abrir esa URL sin pagar. La confirmación cripto es asíncrona y el navegador es el testigo equivocado.
• Dos facturas para un solo pago. Los proveedores reintentan los webhooks. Dos entregas que llegan juntas pueden leer el pedido todavía sin facturar y facturarlo las dos. En la contabilidad de Magento, eso equivale a cobrarle dos veces al comprador.
• Pagos incompletos facturados completos. El comprador envía 1.800 USD contra un pedido de 2.000. Un módulo que solo lee "status: finished" crea la factura igual, y el despacho sale detrás.
• Pedidos pagados cancelados tarde. Un aviso de "expirado" puede llegar después de que la factura se pagó. Cancelar un pedido en Magento devuelve los productos al stock, así que un aviso tardío puede deshacer una venta que ya ocurrió.
• Un método configurado que igual no aparece. Un método de pago puede estar activo, disponible y registrado y aun así quedar filtrado del checkout, sin una línea en el log. Otro clásico: un módulo que lee su API key cifrada sin descifrarla recibe un 401 en cada llamada, que se ve idéntico a un ataque.
• Roturas en modo producción. Un módulo que solo funciona en modo desarrollador falla en setup:di:compile, normalmente en pleno deploy, que es el peor momento para enterarse.
• Fondos en el saldo de otro. Los gateways cripto custodiales juntan tus ventas en su wallet y te pagan después, con su calendario, sus mínimos y su política de congelamiento.

Por qué los módulos de tarjeta y los módulos cripto custodiales se quedan cortos en Magento

Los módulos de tarjeta son maduros, pero el riel pone las reglas. El adquirente retiene los fondos, decide cuándo se liquidan y puede retirarlos con una disputa. Y cada campo de tarjeta de tu checkout entra en el alcance de PCI DSS 4.0.1. Desde el 31 de marzo de 2025, los requisitos 6.4.3 y 11.6.1 obligan a inventariar y autorizar cada script que corre en una página de pago y a detectar alteraciones al menos una vez por semana. Adobe sumó Content Security Policy en modo restrictivo y Subresource Integrity en las páginas de pago en Magento 2.4.7 (9 de abril de 2024) justamente para eso.

Los módulos cripto custodiales resuelven la aceptación, no la custodia. El comprador paga a la dirección del gateway, el gateway 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 correo del pedido no te da un monto único por pedido, ni detección de pagos incompletos, ni factura en Magento, ni cambio de estado. Alguien termina cruzando transacciones de la blockchain con números de pedido a mano.

Lo que necesita una tienda Magento es un módulo que en el admin se comporte como cualquier otro método de pago (un grupo de configuración, facturas reales, comentarios en el pedido) pero que liquide como cripto: final, en segundos y en una wallet que tú controlas.

Cómo elegir un plugin de pagos cripto para Magento 2: seis preguntas

"El mejor" depende de lo que necesites, pero seis preguntas separan un módulo que puedes correr en producción de uno del que te vas a arrepentir. Házselas a cualquier proveedor, incluidos nosotros:

1. ¿Dónde se liquidan los fondos? ¿En tu propia wallet, o en un saldo que el proveedor guarda y te paga después? Solo lo primero deja a todos sin la posibilidad de congelarte el dinero.
2. ¿Qué marca el pedido como pagado? Debe ser un webhook servidor a servidor cuya firma se verifique sobre los bytes crudos de la petición, con ventana anti-replay, y cuyo monto y moneda se comparen con el pedido. La URL de retorno nunca debería contar.
3. ¿Qué pasa si el webhook llega dos veces? Busca deduplicación por ID de evento y un bloqueo de base de datos alrededor de la facturación. Sin eso, los reintentos se convierten en facturas duplicadas.
4. ¿Funciona en modo producción? Debe pasar setup:di:compile, usar el adaptador de pasarela de pago de Magento en vez de sobrescribir el core, y declarar qué versiones de Magento y de PHP soporta.
5. ¿Qué monedas y redes, y quién lo decide? USDT y USDC en redes de bajo costo cubren a la mayoría de los compradores. La lista aceptada debería aplicarse del lado del proveedor, no solo en un desplegable de tu admin.
6. ¿Puedes leer el código? Un módulo open source le permite a tu desarrollador revisar cómo se verifica el webhook y adónde va el dinero antes de que toque un pedido real.

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

Cómo procesa un pago en USDT el módulo de Payzum para Magento 2

El módulo es un método de pago estándar de Magento, construido sobre el adaptador de pasarela de pago. Tiene una sola tarea: convertir el pedido en una factura de Payzum y dejar que un webhook firmado, y nada más, decida el resultado.

En el checkout: una página alojada y la moneda que elija el comprador

El comprador elige Payzum (por defecto, "Crypto / Stablecoins (Payzum)") y hace clic en Realizar pedido. El módulo crea la factura de Payzum en la misma petición que registra el pedido, mediante un observer sobre sales_order_place_after. Cuando el navegador se entera de que el pedido existe, la factura ya existe también. El paso de redirección solo reintenta si Payzum no respondía en ese momento, y los dos caminos comparten una clave de idempotencia, así que no pueden crear dos facturas.

Payzum recibe el total del pedido, la moneda, el número de pedido y tus URL de retorno. Ningún dato personal del cliente sale de tu tienda. El comprador llega a un checkout alojado con un código QR y una dirección de depósito, elige moneda y red, y paga desde cualquier wallet sin crear una cuenta.

El módulo nunca elige la moneda. Tus monedas aceptadas viven en el panel de Payzum, en Merchants → Settings → Accepted tokens, y se aplican del lado del servidor. Para la mayoría de las 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. Las diferencias entre las dos stablecoins están en USDT vs USDC para pagos.

El renderer del checkout es un componente Knockout local, servido desde tus propios archivos estáticos. No carga ningún script de terceros en la página de pago, así que con la CSP en modo restrictivo de la 2.4.7 no necesita entrada en la lista blanca y no suma nada a tu inventario del 6.4.3. No hace desaparecer el alcance PCI de tus métodos de tarjeta, pero el comprador que paga así nunca escribe un número de tarjeta en tu tienda.

Después del pago: la IPN firmada es la única fuente de verdad

Payzum llama a https://tu-tienda.com/payzum/ipn/index de servidor a servidor. Antes de leer un solo campo, el módulo verifica una firma HMAC-SHA-512 sobre los bytes crudos de la petición con tu secreto de webhook, la compara en tiempo constante y rechaza las repeticiones fuera de una ventana de 10 minutos. Una firma inválida recibe un 401 y el pedido no se toca.

Después bloquea la fila del pedido (SELECT … FOR UPDATE), lo vuelve a cargar y compara el ID del evento con los que ya aplicó. Ante un pago finished, compara el monto y la moneda pagados con el total del pedido. Solo si coinciden crea una factura en Magento (captura offline, con el ID de transacción de Payzum) y pasa el pedido a Procesando. Si algo falla a mitad de camino, revierte todo y responde 503 para que Payzum reintente la entrega. Nunca un 200 por un pago que no registró. 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 una instalación en app/code no requiere ningún paso de Composer.

Adónde va el dinero

Lejos de Payzum. El pago del comprador va de su wallet 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 ni esperar. El modelo completo está explicado en qué es un procesador de pagos cripto sin custodia.

Cómo configurar el plugin de pagos cripto para Magento 2, paso a paso

Necesitas Magento Open Source o Adobe Commerce de la línea 2.4 y PHP 8.1 o superior. Ayuda tener acceso a la terminal para correr bin/magento. Casi todo el tiempo se va en la prueba en staging, que es el paso que vale la pena hacer bien.

1. Crea tu cuenta de comercio en Payzum. Regístrate en merchant.payzum.com, agrega la wallet donde quieres cobrar y elige tus monedas aceptadas, por ejemplo USDT y USDC en Base, Solana y Polygon. Crea una API key (64 caracteres hexadecimales) y anota tu secreto de webhook (IPN).
2. Instala el módulo. Descarga payzum-magento2-1.2.0.zip desde la página Releases del repositorio y descomprímelo dentro de app/code/. El archivo ya trae la carpeta Payzum/CryptoPayments/, así que el módulo queda en app/code/Payzum/CryptoPayments. No uses el botón verde "Download ZIP" de GitHub: descomprime en magento2-payzum-main/, y Magento no lo carga. Si gestionas la tienda con Composer, corre composer require payzum/module-crypto-payments en su lugar.
3. Actívalo. Corre bin/magento module:enable Payzum_CryptoPayments y después bin/magento setup:upgrade, bin/magento setup:di:compile y bin/magento cache:flush. El modo producción está totalmente soportado.
4. Configúralo. Abre Tiendas → Configuración → Ventas → Métodos de pago → Payzum — Crypto & Stablecoins. Pon Enabled en Sí, pega la API key y el secreto del webhook y deja Environment en Staging por ahora. Staging tiene sus propias API keys; una key de producción no funciona ahí.
5. Comprueba que el webhook te llegue. No hay nada que pegar: el módulo envía su propia URL de IPN con cada factura. Solo asegúrate de que /payzum/ipn/index, en la URL base de tu tienda, acepte peticiones POST desde internet. Un staging protegido con autenticación básica o con lista de IP permitidas nunca recibirá la notificación.
6. Prueba en staging. Haz un pedido. El historial muestra "Payzum invoice created — awaiting payment". Págalo y mira cómo aparece la factura y el pedido pasa a Procesando. Después paga de menos un pedido a propósito y confirma que queda En espera.
7. Sal en vivo. Cambia Environment a Production, pega tu API key y tu secreto de producción, limpia la caché y haz un pedido real pequeño.

La pantalla de configuración de un vistazo

No hay a propósito ni selector de monedas ni campo para la cabecera de la firma. Las monedas aceptadas viven en tu panel de Payzum y la cabecera la fija el SDK, así que nada en esta pantalla puede desincronizarse de tu cuenta.

Qué le pasa al pedido de Magento en cada paso

Nada de esta tabla lo dispara el navegador del comprador. Una pestaña cerrada nunca pierde un pedido pagado, y una visita a la página de éxito nunca marca uno sin pagar.

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

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

• Distribuidora B2B con pedidos mayoristas. Una distribuidora de refacciones industriales en Monterrey tiene su catálogo mayorista en Magento y recibe pedidos de 18.000 USD de compradores en Centroamérica y Colombia. Con tarjeta, a las tarifas de referencia de Braintree en EE. UU. más el recargo internacional, un solo pedido costaría 700,49 USD en comisiones. Una transferencia internacional tarda días y llega con comisiones de bancos intermediarios descontadas. Pagado en USDT en una red de bajo costo, el pedido se factura segundos después de la confirmación. Si la tesorería del comprador lo envía en dos transferencias, el pedido queda En espera hasta que llega la segunda.
• Marca con varias vistas de tienda. Una marca de moda de Madrid tiene vistas de tienda en español, portugués e inglés y vende a Latinoamérica, donde la mayoría de sus ventas con tarjeta pagan el recargo internacional y el de conversión. Configura una sola API key a nivel de sitio web y traduce el título del método de pago en cada vista ("Paga con USDC o USDT", "Pague com USDC ou USDT"). El dinero de todas las vistas llega a la misma wallet.
• Electrónica de ticket alto. Una tienda de Panamá que vende en dólares, con un ticket promedio de 2.400 USD, pagaría 69,65 USD por venta a la tarifa de referencia de 2,89% + 0,29 USD. Un pedido con tarjeta robada puede volver semanas después como contracargo de 15 USD más la mercadería perdida. Un pago en USDC es final una vez confirmado, y la verificación del monto hace que el pedido se facture solo cuando llegaron los 2.400 USD completos.
• Una tienda que ya sufrió un skimmer. Después de limpiar su sitio en la época de CosmicSting, un comercio quiere ofrecer a sus clientes habituales una forma de pagar que no implique ningún número de tarjeta en la web. Payzum aparece como un método más y el pago ocurre en la página alojada. Los métodos de tarjeta siguen en el alcance PCI, pero cada comprador que se cambia es una tarjeta menos escrita en el checkout.

Payzum para Magento 2 vs un módulo de tarjeta, un módulo cripto custodial y un servidor autoalojado

Comparados con criterios neutros. Las cifras de tarjeta son las tarifas publicadas de PayPal Braintree para EE. UU., consultadas el 1 de octubre de 2026.

Un servidor autoalojado es una opción válida si no quieres ningún tercero y tienes a alguien que lo opere. Payzum es para tiendas que quieren la misma custodia sin operar infraestructura de pagos. Y nada te impide conservar tu módulo de tarjeta: la mayoría de las tiendas suman Payzum como un método de pago más, y Sort order decide dónde aparece.

Objeciones frecuentes, respondidas

"Mis clientes no tienen cripto."

La mayoría no lo necesita. Payzum es un método de pago adicional junto a tus tarjetas, no un reemplazo. Los compradores que lo eligen son los que de otro modo abandonarían el carrito, te transferirían con días de demora o pagarían tus recargos de tarjeta más altos.

"¿Y la volatilidad?"

Tus precios siguen en la moneda de tu tienda: el módulo envía el total del pedido en la moneda del pedido 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.

"Después de CosmicSting, no instalo módulos por confianza."

Bien hecho, y no tienes por qué. El código es público con licencia OSL-3.0, la misma de Magento Open Source. El manejador del webhook es Controller/Ipn/Index.php: se salta la verificación de form key de Magento solo porque cada petición tiene que traer, en su lugar, una firma HMAC válida. La API key y el secreto se guardan con el backend cifrado de Magento, no hay ninguna dirección de wallet en el código y lo único que sale es el total, la moneda, el número de pedido y las URL de retorno.

"¿Cómo funcionan los reembolsos si los pagos son finales?"

Con el flujo de notas de crédito del propio Magento. Como la factura se capturó offline, creas una nota de crédito offline en el pedido y después envías los USDT de vuelta desde tu wallet según la política de reembolsos que publiques. Tú decides cuándo vuelve el dinero; no lo decide una red de tarjetas.