¿Hay plugins de pago cripto open source para plataformas de e-commerce?

El plugin de pagos es el código en el que más confías

Todos los plugins de una tienda online corren con permisos parecidos, pero solo uno decide sobre el dinero. El plugin de pagos guarda tu API key, recibe el aviso de "este pedido está pagado" y cambia el estado que dispara el envío, la licencia de software, la matrícula del curso o la cuenta de hosting. Si se equivoca en esa decisión, entregas mercadería sin cobrarla.

Además es código de terceros, y es por ahí por donde empiezan cada vez más incidentes. El Data Breach Investigations Report 2025 de Verizon (abril de 2025) encontró que la proporción de brechas con un tercero involucrado se duplicó en un año, del 15% al 30%. El informe OSSRA 2026 de Black Duck (febrero de 2026) auditó 947 bases de código comerciales: el 87% tenía al menos una vulnerabilidad y el 65% de las organizaciones sufrió un ataque a su cadena de suministro de software en el año previo.

En una tienda, la cadena de suministro son los plugins. Solo WordPress mueve el 40,2% de todos los sitios web (W3Techs, 29 de septiembre de 2026), y una tienda WooCommerce agrega una pasarela de pago igual que un formulario de contacto: subir, activar, confiar.

Con un plugin de pagos cerrado, "confiar" es todo el modelo de seguridad. Lo mismo pasa con uno ofuscado o que solo trae la mitad de la lógica. No puedes ver si verifica alguna firma, si marca pedidos como pagados cuando el navegador del comprador vuelve a tu sitio, ni adónde va realmente el dinero.

Lo que no ves en un plugin cerrado te puede costar caro

Pedidos marcados como pagados con una petición falsa. Un plugin que confía en la URL de retorno del comprador, o que acepta un webhook sin verificar su firma, puede recibir "status: paid" de cualquiera que conozca la dirección del callback. El pedido sale; el dinero nunca llegó.

El mismo pedido despachado dos veces. Los procesadores reenvían los webhooks cuando la tienda tarda en responder. Un handler que no deduplica manda dos correos de confirmación, descuenta stock dos veces y entrega la descarga dos veces.

Fondos que van adonde tú no elegiste. Muchos plugins de pasarelas cripto existen para llevar el dinero del comprador al saldo de la pasarela. El calendario de pagos, la reserva y la política de congelamiento los descubres después, y nada en el plugin te dice por dónde pasa la plata.

Un plugin abandonado en pleno checkout. Un plugin cerrado que deja de mantenerse se rompe con la siguiente versión mayor de la plataforma, y no lo puedes parchear, forkear ni pagarle a otro para que lo arregle. Tu checkout queda esperando la hoja de ruta de otra empresa.

Una revisión de seguridad que no puedes aprobar. Los clientes corporativos, los inversionistas y tu propio equipo de seguridad preguntan cada vez más qué código de terceros toca los pagos. "Es un plugin del proveedor, no sabemos" no cierra ninguna revisión.

Por qué casi todos los plugins de pago cripto son cerrados, custodiales o ambas cosas

No es mala fe. Es consecuencia de cómo están construidos los procesadores que hay detrás.

Con una pasarela custodial, el plugin es un embudo. La lógica que importa (direcciones de depósito, confirmaciones, el saldo) vive en los servidores de la pasarela, junto a tu dinero. Aunque el código del plugin se pueda leer, no te muestra lo que te interesa, porque los fondos nunca pasan por él: caen en la wallet de la pasarela y vuelven a ti como un payout.

Un procesador open source autoalojado es el trade-off opuesto. Todo es auditable, pero tú corres el procesador, su base de datos y muchas veces un nodo, y respondes por el uptime. Encaja bien en equipos con capacidad de operaciones. Es mucho para una tienda con un desarrollador a medio tiempo.

Los plugins de pasarelas de tarjeta suelen ser open source, pero el riel no. Puedes leer el plugin de WooCommerce de un procesador de tarjetas, pero el adquirente igual retiene los fondos varios días y puede revertir un pago hasta unos 120 días después de la venta.

Lo que la mayoría de los comercios quiere es la combinación que nadie ofrecía: el plugin es abierto, el procesador no tiene custodia y no hay servidor que mantener.

Los 29 plugins de pago cripto open source de Payzum, por plataforma

Payzum es un procesador de pagos cripto sin custodia y enfocado en stablecoins: los pagos se liquidan directo en wallets que controla el comercio. Cada integración vive en su propio repositorio dentro de github.com/payzum-dev, con el nombre <plataforma>-payzum. Siete siguen la convención de su ecosistema: medusa-payment-payzum, saleor-app-payment-payzum, vendure-plugin-payzum, sylius-payzum-plugin, django-payments-payzum, omnipay-payzum y frappe-payzum. Verificamos cada fila contra la organización en vivo, sus licencias, sus releases y los registros de paquetes el 29 de septiembre de 2026.

Carritos de e-commerce (10)

Comercio headless (4)

Hosting y facturación (4)

Donaciones, membresías y descargas digitales (3)

Formularios, cursos, ERP, contabilidad, ticketing y .NET (6)

Librerías de pagos (2)

En la misma organización están los SDKs oficiales (Node.js/TypeScript, PHP, Python y Rust) y payzum-openapi. Ese repositorio contiene el contrato OpenAPI de la API y un corpus compartido de vectores de prueba de firmas de webhook, contra el que se valida cada SDK. El plugin de WooCommerce, por ejemplo, incluye el SDK oficial de PHP y delega en su verificador el chequeo de firmas en vez de implementarlo a mano. Si tu plataforma no está en las tablas, no necesitas un plugin: la integración en tres pasos funciona con cualquier sistema que pueda llamar a una API.

Lo que el código te deja comprobar: adónde va el dinero

Revisamos los 29 repositorios el 29 de septiembre de 2026: ninguno contiene una dirección de wallet. Un plugin de Payzum nunca decide adónde va el dinero. Crea el pago desde tu servidor con el total del pedido, la moneda, una referencia y tus URLs de callback, y manda al comprador al checkout alojado. La wallet que recibe es la que tú configuras en tu propio panel de Payzum.

El comprador paga desde su wallet directo a la tuya. Eso se confirma en unos 0,4 segundos en Solana y en torno a dos segundos en Base o Polygon, y Payzum nunca retiene los fondos. Si pones tus precios en dólares, la autoconversión opcional a USDC o USDT está disponible en la mayoría de las redes soportadas. El modelo completo está en qué es un procesador de pagos cripto sin custodia.

Lo que el código te deja comprobar: cómo se verifica el webhook

Abre la clase del gateway del plugin de WooCommerce y la decisión completa entra en menos de cien líneas que puedes leer:

• Lee el cuerpo crudo de la petición antes de parsear nada.
• Verifica una firma HMAC-SHA-512 sobre esos bytes crudos, tomada de un header fijo, con una comparación en tiempo constante. El header es x-nowpayments-sig, porque el IPN de pagos usa un formato compatible con NOWPayments.
• Rechaza eventos fuera de una ventana anti-replay de 10 minutos sobre el timestamp firmado.
• Ignora duplicados por ID de evento, bajo un lock por pedido para que dos entregas simultáneas no puedan marcar pagado el mismo pedido.
• Responde 401 a cualquier petición sin firma válida y deja el pedido intacto.

Recién entonces mapea el estado del pago al del pedido: finished pasa a procesando o completado, partially paid queda en espera, expired se cancela y failed falla. Nada se deduce del navegador del comprador.

Cómo auditar un plugin de pagos cripto open source en 15 minutos (y después instalarlo)

Sirve para cualquier plugin de pagos, no solo el nuestro. El ejemplo es el de WooCommerce; cambia las rutas según tu plataforma.

1. Encuentra el repositorio oficial. Usa las tablas de arriba y confirma que el repositorio está bajo github.com/payzum-dev, no en un fork ni en una cuenta que se le parezca.
2. Lee la licencia y el último release. MIT, GPL y OSL te permiten leer, modificar y forkear el código. Descarga el zip empaquetado desde Releases, no con el botón "Download ZIP" de GitHub: ese se descomprime en una carpeta <repo>-main/ que la plataforma no reconoce.
3. Abre el handler del webhook y haz los cinco chequeos de abajo. En WooCommerce está en includes/class-wc-gateway-payzum.php, método handle_ipn(); en WHMCS es el archivo callback/ del gateway.
4. Revisa adónde va el dinero. Busca en el código direcciones de wallet y lo que el plugin envía hacia afuera. No deberías encontrar ninguna dirección, y lo que sale debería ser el total, la moneda, la referencia del pedido y las URLs de callback, sin datos personales del cliente.
5. Instala en staging. Sube el zip del release o instala desde el registro, pega una API key y un secreto de webhook de staging, y copia la URL del IPN que muestra la configuración en los ajustes de webhook de tu panel de Payzum.
6. Prueba primero el camino de error. Envía una petición sin firma a tu URL de IPN (abajo) y espera un 401. Después haz un pedido real en staging, págalo en el checkout alojado y verifica que pase a procesando solo cuando llegue el webhook firmado. Paga de menos una vez y confirma que queda en espera.
7. Sal a producción. Cambia a la key de producción, activa el método y publica las condiciones de reembolso que el comprador acepta en el checkout. Los pagos on-chain son finales, así que un reembolso es un pago que envías tú según tu propia política.

# Debe rechazarse: no trae header de firma, así que el pedido no se toca
curl -i -X POST https://tu-tienda.example/wc-api/wc_gateway_payzum \
  -H 'Content-Type: application/json' \
  -d '{"order_id":"123","payment_status":"finished"}'
# Esperado: HTTP 401 (bad signature)

Cinco cosas que revisar en el handler de webhooks de cualquier plugin de pagos

1. Lee el cuerpo crudo y verifica la firma antes de confiar en un solo campo.
2. Usa una firma HMAC de un header fijo con comparación en tiempo constante, no una igualdad de strings común.
3. Tiene ventana anti-replay y deduplica por ID de evento.
4. Nunca marca un pedido como pagado por la URL de retorno del comprador.
5. Guarda la API key y el secreto del webhook en el servidor, sin nada secreto en el JavaScript de la página de checkout.

La ingeniería detrás de cada chequeo, con código en Node.js, PHP y Python, está en webhooks firmados para pagos cripto. Lo que hace el plugin en el checkout, paso a paso, está en la guía principal: plugin de pagos cripto: un checkout drop-in para tu tienda.

Casos de uso: quién instala plugins de pago cripto open source, y por qué

La licencia importa sobre todo a quien tiene que responder por el checkout.

• La agencia de Ciudad de México con 40 tiendas de clientes en tres carritos. Maneja WooCommerce, PrestaShop y Shopware para clientes en México, Colombia y Chile. Audita el plugin una vez por plataforma, fija la versión del release en sus scripts de despliegue y lo va instalando tienda por tienda. Cada cliente conecta su propia wallet en su propio panel, así que la agencia nunca toca fondos ajenos, y cada actualización es un diff que puede leer antes de publicarla.
• El proveedor de hosting en Buenos Aires con WHMCS. Su revisión de seguridad pregunta qué código puede marcar una factura como pagada. El desarrollador lee el módulo del gateway y su callback, manda la petición de prueba sin firma, recibe un 401 y cierra la revisión en una tarde. El caso de negocio de las stablecoins para hosting está en aceptar pagos cripto como proveedor de hosting.
• La fundación en Bogotá con GiveWP y un desarrollador voluntario. Los donantes preguntan adónde va su aporte, y ahora la respuesta se puede comprobar: no hay ninguna dirección en el plugin, y cada donación llega a la wallet propia de la organización, confirmada on-chain y con referencia. El voluntario revisa un plugin con licencia GPL, la misma que usa WordPress.
• El equipo headless en Madrid con Medusa o Saleor. Su flujo B2B necesita un paso de aprobación antes del pago, algo que ningún plugin estándar trae. Con la licencia MIT, el equipo forkea el provider, agrega el paso y sigue integrando los releases de upstream, en vez de reescribir una integración de pagos desde cero.
• El área de finanzas con ERPNext o Akaunting. Las facturas a clientes del exterior se cobran en USDC y el callback firmado las marca como pagadas en el libro contable. La conciliación sale de una referencia de pedido y una transacción on-chain, no de un concepto de transferencia que alguien tipeó a mano.

Plugins de pago cripto open source vs cerrados: comparativa

Objeciones frecuentes, resueltas

"No está en el marketplace de WordPress ni en el de Shopify. ¿Es seguro instalar desde GitHub?"

La revisión de un marketplace mira una foto del código, una vez, con criterios que tú no ves. El código abierto te deja revisar cada línea de la versión que realmente instalas, y cada diff posterior. Fija un release con tag, lee el handler del webhook, corre la prueba de la petición sin firma, y sabrás más de este plugin que de la mayoría de los listados. Los paquetes de Packagist, npm y PyPI se publican desde los mismos repositorios públicos.

"Si el código es público, ¿no lo leen también los atacantes?"

Lo pueden leer, y no les sirve de nada. La verificación de firmas está pensada para ser pública: su seguridad depende de tu secreto de webhook, no de esconder el algoritmo. Un atacante que lee el código aprende el nombre del header. Sin tu secreto no puede generar una firma que el plugin acepte, y sin firma el pedido no se mueve.

"Mi plataforma no está en la lista."

Entonces usa la API directamente. Una llamada desde el servidor crea el pago, la respuesta te da la URL del checkout alojado y el webhook firmado te avisa cuando está pagado. Los SDKs oficiales cubren Node.js, PHP, Python y Rust. El recorrido para desarrolladores está en pasarela de pagos cripto con API REST.

"No tenemos un desarrollador que audite nada."

El checklist le toma a un desarrollador unos quince minutos, y un freelancer lo puede correr por ti. Si prefieres verlo hecho, agenda una llamada y recorremos en pantalla el plugin de tu plataforma.