Pasarela de pago cripto para WHMCS: ¿cómo acepto pagos cripto en WHMCS?

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 WHMCS es un módulo open source publicado en github.com/payzum-dev/whmcs-payzum. Esta guía es para empresas de hosting, revendedores de dominios y cualquier negocio que facture con WHMCS. Explica por qué los hostings están sumando stablecoins en 2026, seis preguntas para evaluar cualquier módulo cripto y el módulo de Payzum paso a paso. Después, qué cambia en las renovaciones cuando el pago no se puede cobrar solo, y en qué se diferencian los módulos de Blesta, HostBill y ClientExec. Si primero quieres el caso de negocio, lee aceptar pagos cripto como proveedor de hosting. Este artículo se queda dentro del sistema de facturación.

Por qué los hostings buscan una pasarela de pago cripto para WHMCS en 2026

Este año desapareció una opción cripto muy usada. Coinbase cerró el portal de comercios de Coinbase Commerce el 31 de marzo de 2026, y las plataformas de facturación tuvieron que seguirle. La guía de migración a Blesta 6 lo dice sin rodeos: «Coinbase shut down the Coinbase Commerce service, so the gateway no longer functions» (Coinbase cerró el servicio y la pasarela dejó de funcionar). Blesta 6.0 eliminó ese gateway, y las instalaciones de WHMCS que cobraban en cripto con módulos de terceros para Coinbase Commerce se quedaron sin la opción cuando cerró el servicio. Los hostings cuyos clientes pagan en cripto están eligiendo un reemplazo.

La tarjeta sale cara entre países. Un hosting en España factura a menudo a clientes de Latinoamérica. Toma las tarifas publicadas de Stripe para España, consultadas el 3 de octubre de 2026. Una tarjeta emitida fuera del EEE cuesta 3,15 % + 0,25 €, y la conversión de moneda suma un 2 %. Un servidor dedicado de 1.800 € al año facturado a un cliente de México que paga en dólares deja 92,95 € en comisiones. Y cada disputa cuesta 20 € al recibirla y otros 20 € si la peleas, que solo te devuelven si ganas.

El hosting atrae el fraude con tarjeta. Un servidor se entrega en minutos y una tarjeta robada se puede disputar durante meses. La propia documentación de WHMCS lo advierte: en sus ajustes de crédito avisa que dejar que un cliente añada fondos sin un pedido aprobado «may increase the risk of chargebacks and fraud» (puede aumentar el riesgo de contracargos y fraude).

Y hay clientes que prefieren pagar en USDT. Desarrolladores, proyectos cripto, comunidades de servidores de juegos y clientes en países donde las tarjetas extranjeras se rechazan con frecuencia. Si no tienen una opción en stablecoins, se van o pagan tarde, y ninguna de las dos cosas te deja dinero.

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

Sumar cripto no elimina el riesgo por sí solo. Los módulos de facturación fallan de formas propias de WHMCS, y cada fallo cuesta dinero o un fin de semana de soporte:

• Facturas marcadas como pagadas por la página de retorno. Si el módulo se fía de que el cliente vuelva a viewinvoice.php, cualquiera puede simular esa visita. La confirmación en cripto es asíncrona, y el navegador es el testigo equivocado.
• Dos checkouts para una factura. El cliente recarga la página de la factura, recibe una segunda dirección de depósito y paga las dos. Ahora debes una devolución y un ticket.
• Factura acreditada por menos de lo que vale. Un módulo que solo mira el estado, y no el importe, marca la factura como pagada con un pago menor. Puede ser un checkout viejo, creado antes de aplicar un crédito, o uno falsificado por un céntimo.
• El mismo pago acreditado dos veces. Los proveedores reintentan los callbacks. Sin control de duplicados, cada reintento suma otro pago a la factura y el exceso se convierte en crédito del cliente.
• Un callback público que llena tu base de datos. Una URL de callback que registra completa cada petición sin firma deja que cualquiera escriba megas en tu log del gateway, una y otra vez.
• Un módulo que nadie mantiene. Un gateway escrito para WHMCS 7 y nunca actualizado se rompe en la siguiente subida de PHP, y WHMCS 9 la obliga: necesita PHP 8.2 o superior.
• Fondos aparcados en el saldo de otro. Las pasarelas custodiales cobran tus ventas en su propia wallet y te pagan cuando les toca, con sus mínimos y su política de congelamiento.

Por qué las pasarelas de tarjeta, la transferencia y la cripto custodial se quedan cortas en la facturación de hosting

La tarjeta gana en automatización y pierde en finalidad. WHMCS guarda un token de tarjeta y cobra cada renovación sin que el cliente mueva un dedo. Esa comodidad es real. Pero el dinero puede volver mucho después de que entregaste el servidor. El adquirente retiene los fondos primero, y cada disputa cuesta comisiones ganes o pierdas.

La transferencia es final pero manual. El cliente transfiere, tú cuadras la transferencia con la factura a mano, y las transferencias internacionales tardan días y a menudo llegan con menos dinero por las comisiones bancarias. Mientras tanto, el servicio espera o corre sin pagar.

Las pasarelas cripto custodiales resuelven el cobro, no la custodia. El cliente paga a la dirección de la pasarela, la pasarela te acredita un saldo y retiras cuando te deja. Ese saldo es lo que un proveedor puede congelar, o lo que tienes que mover cuando cierra.

Una dirección de wallet suelta se salta todo lo demás. Pegar una dirección en la factura no te da un importe único por factura, ni estado, ni detección de pagos incompletos, ni automatización. Alguien acaba cuadrando transacciones de blockchain con números de factura.

Un hosting necesita una pasarela que se comporte como cualquier otro método de pago de WHMCS: factura pagada, transacción en el historial del cliente, automatización en marcha. Y que liquide como cripto: final, en segundos, en una wallet que tú controlas. Los detalles sobre abuso en hosting con un medio de pago final están en la guía para proveedores de hosting.

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

Hay varios módulos cripto para WHMCS. Seis preguntas separan uno que puedes poner en producción de uno del que te vas a arrepentir. Házselas a cualquier proveedor, también a nosotros:

1. ¿Dónde se liquidan los fondos? ¿En tu propia wallet, o en un saldo que el proveedor retiene y te paga después? Solo la primera opción deja a todos sin poder congelar el dinero.
2. ¿Qué marca la factura como pagada? La documentación para desarrolladores de WHMCS define un gateway de terceros como aquel en el que «a customer leaves the site to pay and returns when the payment process is complete» (el cliente sale del sitio para pagar y vuelve al terminar). Que vuelva no prueba nada. Busca un callback de servidor a servidor cuya firma se verifique sobre los bytes crudos de la petición, con ventana anti-replay.
3. ¿Se comprueba el importe, y en el orden correcto? La función checkCbTransID de WHMCS rechaza cualquier ID de transacción que ya haya visto. Un módulo que registra la transacción antes de comprobar el importe no puede corregir después un abono mal hecho: el reintento corregido se rechaza como duplicado. La comprobación del importe tiene que ir primero.
4. ¿Qué pasa al recargar la página y al reintentar el callback? Una factura recargada debería reutilizar el checkout abierto, y un callback reintentado no debería cambiar nada.
5. ¿Encaja con tus versiones de WHMCS y PHP? Según la documentación de WHMCS al 3 de octubre de 2026, la 9.0 está en disponibilidad general y pide PHP 8.2 u 8.3. La 8.13 es la versión de soporte extendido (LTS), y todas las anteriores están fuera de soporte. Un módulo anterior a PHP 8 no es opción.
6. ¿Puedes leer el código y qué registra? Con código abierto, tu desarrollador comprueba cómo se verifica el callback y adónde va el dinero. Verifica también que no guarde en tus logs el cuerpo de peticiones sin firma.

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 de factura el módulo de Payzum para WHMCS

El módulo es un Third Party Gateway estándar de WHMCS. Hace dos cosas: convertir una factura impaga en un checkout de Payzum, y dejar que un callback firmado, y nada más, aplique el pago.

En la factura: un checkout por factura

El cliente abre la factura y pulsa Pay with Crypto, o el texto de «pagar ahora» que tengas configurado. El módulo crea una factura de Payzum por el importe pendiente, en la moneda de la factura. El importe viaja como texto exacto, así que no se redondea por el camino. El cliente llega al checkout alojado de Payzum, con código QR, dirección de depósito y estado en vivo, y paga desde cualquier wallet sin crear cuenta.

El módulo guarda ese checkout en su propia tabla, mod_payzum_payments, que crea la primera vez que se ejecuta. Si el cliente recarga la factura, recibe el mismo checkout mientras siga abierto por el mismo importe. Si el importe pendiente cambia, por ejemplo porque se aplicó un crédito, el checkout viejo se reemplaza. Si el cliente ya pagó pero el callback todavía no llegó, la página muestra «Crypto payment received — awaiting confirmation» (pago recibido, esperando confirmación) en lugar de ofrecer un segundo checkout. Y si Payzum no responde, la página pide reintentar en un momento. Nunca adivina.

El módulo no elige la moneda. El checkout ofrece solo los tokens que aceptas, que configuras en tu panel de Payzum en Merchants → Settings → Accepted tokens, y Payzum hace cumplir esa lista de su lado. Para la mayoría de los hostings 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 cripto, la conversión automática opcional a USDC o USDT está disponible en la mayoría de las redes soportadas.

Después del pago: el callback firmado lo aplica

Payzum avisa a modules/gateways/callback/payzum.php de servidor a servidor. Antes de leer un solo campo, el callback verifica una firma HMAC-SHA-512 sobre los bytes crudos de la petición con tu secreto de webhook. La comparación es de tiempo constante, y se rechazan los replays fuera de una ventana de 10 minutos. Una firma incorrecta recibe un 401. El log del gateway guarda solo el tamaño y un hash corto de la petición rechazada, nunca su contenido.

Después vienen los controles del propio WHMCS. checkCbInvoiceID confirma que el número de factura es válido. Con un pago finished, el módulo compara el importe y la moneda pagados con lo que pidió cobrar a Payzum, con medio céntimo de tolerancia. Si falta dinero, si la moneda es otra o si el importe no se puede leer, lo registra como «Not credited» (no acreditado) con todo el detalle, y no toca la factura. Solo entonces checkCbTransID rechaza un ID de pago ya aplicado, así que los reintentos no hacen nada. Por último, addInvoicePayment registra el pago con el ID de Payzum como ID de transacción y comisión cero: el dinero ya está en tu wallet y no hay nada que descontar.

Cualquier otro estado se escribe en el log del gateway y no cambia nada. Eso incluye pagos en espera, parciales, vencidos y fallidos, más los avisos de depósito tardío o de token equivocado. 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, que viaja dentro del módulo, así que no hay paso de Composer.

Qué hace WHMCS a continuación

Para WHMCS, una factura pagada es una factura pagada, la pague el gateway que la pague. Los productos configurados para darse de alta al recibir el pago se aprovisionan. Una factura de renovación pagada adelanta el próximo vencimiento del servicio. Y si tienes activado Enable Unsuspension, un servicio suspendido por falta de pago se reactiva solo. Tus módulos de aprovisionamiento, correos y hooks funcionan como hoy.

Adónde va el dinero

A ningún lugar cerca de Payzum. El pago va de la wallet del cliente 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 de Payzum que retirar, congelar o esperar. El modelo se explica en qué es un procesador de pagos cripto sin custodia.

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

Casi todo el tiempo se va en la prueba en staging, que es el paso que vale la pena hacer bien.

1. Revisa tu stack. El módulo necesita PHP 8.1 o superior con ext-curl. WHMCS 9.x ya exige PHP 8.2. En WHMCS 8.13, que funciona con PHP 7.2 a 8.3, comprueba qué PHP usa realmente tu servidor. El callback tiene que ser accesible por HTTPS.
2. Prepara tu cuenta de comercio en Payzum. Regístrate en merchant.payzum.com. Añade la wallet donde quieres cobrar y elige tus tokens aceptados, por ejemplo USDT en Polygon, Solana y BNB Chain, más USDC en Base. Crea una API key en Developers → API keys y anota tu secreto de webhook (IPN).
3. Instala el módulo. Descarga payzum-whmcs-1.0.0.zip desde la página Releases del repositorio y descomprímelo en la raíz de tu WHMCS. El archivo ya reproduce modules/gateways/, con el SDK incluido. No uses el botón verde «Download ZIP» de GitHub: descomprime en la carpeta equivocada.
4. Actívalo. Entra en Configuration → System Settings → Payment Gateways y activa Payzum (Crypto & Stablecoins). Pega la API key y el secreto de webhook, y deja Environment en Staging por ahora. Staging tiene sus propias API keys; una clave de producción no funciona ahí.
5. Nada que pegar para el callback. El módulo envía https://<tu-whmcs>/modules/gateways/callback/payzum.php con cada checkout que crea. Tiene que aceptar peticiones POST desde internet: una instalación detrás de autenticación básica, una lista de IPs permitidas o una página de mantenimiento nunca recibirá el aviso.
6. Prueba en staging. Crea una factura para un cliente de prueba y págala. Antes de pagar, recarga la página de la factura: deberías ver el mismo checkout. Después del pago, la factura pasa a Paid y la transacción muestra el ID de pago de Payzum. Busca la entrada Successful en el log del gateway.
7. Sal en vivo. Cambia Environment a Production, pega tu clave y tu secreto de producción, y paga una factura real pequeña.

Los ajustes del gateway, de un vistazo

No hay, a propósito, ningún campo para la cabecera de la firma. La fija el SDK, así que nada en esta pantalla puede desincronizarse de tu cuenta.

Qué pasa en WHMCS en cada estado del pago

Nada de esta tabla lo dispara el navegador del cliente. Una pestaña cerrada nunca pierde una factura pagada, y una visita de retorno falsa nunca paga una impaga.

Renovaciones en WHMCS cuando el pago es en cripto

Esta es la parte que conviene resolver antes de anunciar la opción, porque las renovaciones en cripto funcionan distinto que con tarjeta.

Por qué WHMCS no puede cobrar cripto de forma automática

Una pasarela de tarjeta puede cobrar un token guardado cuando WHMCS se lo pide. Un pago en cripto lo empuja el cliente desde su propia wallet, y nadie puede tirar de él. Por eso el módulo de Payzum no guarda ningún método de pago. Cada renovación es una factura que el cliente paga, igual que pagó la primera.

El ciclo de renovación, paso a paso

1. WHMCS genera la factura de renovación. Por defecto lo hace 14 días antes del próximo vencimiento del servicio. Se ajusta en Invoice Generation, dentro de los ajustes de automatización de WHMCS, con valores distintos por ciclo de facturación si quieres.
2. El cliente recibe la factura y los recordatorios. Abre la factura y paga en USDT o USDC. El método de pago del servicio puede quedar en Payzum, así que el botón correcto aparece cada vez.
3. El callback la marca como pagada. El próximo vencimiento avanza un ciclo, igual que con cualquier otro gateway.
4. Si el cliente se atrasa, se aplican tus recordatorios de impago y tus Suspend Days de siempre. En cuanto paga, Enable Unsuspension reactiva el servicio solo. No reactiva servicios que suspendiste a mano con un motivo propio, como un caso de abuso.

Crédito prepago: lo más parecido a la renovación automática

WHMCS tiene un sistema de crédito que encaja muy bien con la cripto. Los clientes usan Add Funds en su área de cliente para recargar saldo, y pagan esa recarga con Payzum. Con Automatic Credit Use activado, que es lo predeterminado, WHMCS aplica el saldo a las nuevas facturas de renovación en cuanto las genera. Ten en cuenta dos detalles de la documentación de crédito de WHMCS. Primero, el crédito no se aplica solo a las facturas que ya existían cuando el cliente recargó: esas las aplica el cliente o un administrador. Segundo, un cliente solo puede añadir fondos cuando tiene un pedido activo y aprobado, y WHMCS recomienda mantener ese requisito.

Un cliente que recarga un año de hosting en USDT renueva sin pensarlo, y tú tienes el dinero desde el primer día. Los ciclos anuales reducen el número de pagos de la misma forma.

Blesta, HostBill y ClientExec: el mismo modelo, plataforma por plataforma

Los tres módulos hermanos comparten el checkout alojado, el callback firmado, la comprobación del importe y el SDK incluido. Cambia lo que cada plataforma espera de un gateway.

Blesta

El módulo de Blesta es un gateway no-merchant: el cliente sale a pagar y Blesta registra el resultado a partir del callback firmado. Un solo pago puede cubrir varias facturas abiertas a la vez. Un pago terminado se registra como approved, uno vencido o fallido como declined, y uno en curso como pending. El regreso del cliente desde el checkout solo se registra como pendiente. Un pago terminado que no coincide con el importe se registra como rechazado, para que una persona lo revise antes de tocar las facturas. Pon en el campo IPN URL el callback de tu gateway, https://tu-blesta/callback/gw/{company_id}/payzum/, y la misma URL en los ajustes de webhook de Payzum. Ojo: el módulo solo se ofrece en cinco monedas, USD, EUR, GBP, CAD y AUD. Blesta 6.0 exige PHP 8.2, y el módulo no declara un rango de versiones de Blesta, así que pruébalo en una copia de staging de tu versión exacta.

HostBill

El módulo de HostBill no confía en que la plataforma bloquee transacciones duplicadas. Lleva su propio registro del importe de cada factura y de cada ID de pago que ya acreditó, así que un callback reintentado no acredita nada. Desde su actualización de abril de 2026, HostBill exige PHP 8.1 a 8.3. El README del módulo es honesto en un punto: la API de módulos de HostBill es propietaria, y el módulo sigue su patrón habitual. Valídalo en staging con tu versión de HostBill antes de salir en vivo.

ClientExec

ClientExec 7.0 es la versión estable desde el 2 de marzo de 2026 y exige PHP 8.2 o superior. Antes que nada, rellena el campo Currency del plugin si tu instalación no define su propio código de moneda. No tiene valor por defecto a propósito: el plugin no factura en una moneda adivinada. Si no puede registrar un pago, deja un error en el log y responde con un error de servidor, para que Payzum reintente el aviso en lugar de perderlo. Igual que con HostBill, el README pide validar en staging la redirección y el abono de la factura.

Lo que estos módulos no hacen

• No cobran solos. Las renovaciones las paga el cliente, factura a factura o con crédito prepago. Mantén tu pasarela de tarjeta para quien quiera renovaciones sin intervención.
• Las diferencias necesitan una persona. Un pago corto o en otra moneda se registra y no se acredita. Tú decides si devuelves la diferencia o aplicas el pago a mano. Un pago parcial espera a que el cliente complete el resto.
• Las devoluciones salen de tu wallet. Los módulos no envían devoluciones. Devuelves las stablecoins tú mismo y registras la devolución en tu sistema de facturación.
• Los registros de HostBill y ClientExec viven en la carpeta temporal del servidor. Si esa carpeta se borra entre el checkout y el pago, la comprobación del importe de esa factura pasa a ser una entrada en el log en lugar de un bloqueo.
• Distribución. Al 3 de octubre de 2026, los cuatro módulos se distribuyen como releases de GitHub. Ninguno está listado en el WHMCS Marketplace ni en otra tienda de los fabricantes.

Casos de uso: hostings que cobran en USDT y USDC

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

• Hosting de VPS en Valencia con clientes en México. Un hosting pequeño factura un VPS de 240 € al año a un desarrollador de Guadalajara, que paga con tarjeta en dólares. Con las tarifas de Stripe para España son 3,15 % + 0,25 € más un 2 % de conversión: 12,61 €. Seis semanas después la tarjeta se denuncia como robada, el dinero vuelve y la disputa cuesta otros 20 € solo por recibirla. Si paga en USDC en Base, la factura queda pagada segundos después de la confirmación, el vencimiento avanza un año y el pago no se puede revertir.
• Revendedor de dominios con clientes prepago. Una agencia de Buenos Aires gestiona 300 dominios para clientes de Argentina y Venezuela que prefieren pagar en USDT antes que con tarjeta. Los clientes recargan su crédito de WHMCS en USDT con Add Funds. Cada factura de renovación que genera WHMCS se paga con ese saldo en el momento en que se crea, y ningún dominio caduca por una tarjeta rechazada.
• Hosting en Blesta que dependía de Coinbase Commerce. Un hosting de Santiago de Chile cobraba en cripto con Coinbase Commerce hasta que el servicio cerró el 31 de marzo de 2026, y el gateway ya no existe en Blesta 6. Instala el gateway no-merchant de Payzum, prueba una factura en una copia de staging y vuelve a ofrecer cripto. Sus clientes, facturas y servicios quedan exactamente como estaban.
• Servidores de juegos con clientes jóvenes y cripto-nativos. Un hosting de servidores de Minecraft y Rust en Madrid usa WHMCS con suspensión a los tres días de impago. Un cliente de Bogotá paga una renovación vencida en USDT sobre Solana un sábado por la noche. Con Enable Unsuspension activado, el servidor vuelve antes de que el cliente cierre la pestaña del checkout, y nadie tuvo que contestar un ticket.

Payzum para WHMCS frente a una pasarela de tarjeta, la transferencia y una pasarela cripto custodial

Comparado con criterios neutrales. Las cifras de tarjeta son las tarifas publicadas de Stripe para España, consultadas el 3 de octubre de 2026.

Un servidor cripto autoalojado es otra opción justa si no quieres ningún tercero y tienes quien lo opere. Payzum es para hostings que quieren la misma custodia sin operar infraestructura de pagos. Y no tienes que dejar nada: la mayoría suma Payzum como un gateway más junto a la tarjeta.

Objeciones frecuentes, resueltas

«Mis clientes van a perder la renovación automática.»

Solo los que elijan cripto, y saben que pagan empujando desde una wallet. Mantén tu pasarela de tarjeta para el resto. Para los clientes cripto, el crédito prepago y los ciclos anuales hacen que la renovación no sea un problema. Tus correos de recordatorio y tu periodo de gracia hacen el resto.

«¿La cripto no atrae abusadores?»

Un pago final elimina el fraude por contracargo, y también elimina el rechazo del banco emisor como filtro de fraude. Tu control de altas y tu equipo de abuso importan más con este medio de pago, no menos. Lo explicamos con honestidad en la guía para proveedores de hosting. Los controles del propio WHMCS siguen activos, como la regla de que un cliente solo añade fondos después de un pedido aprobado.

«¿Y la volatilidad?»

Tus precios siguen en tu moneda de facturación. El módulo envía el total de la factura en su moneda, y el cliente paga el equivalente en la cripto que elija. Si aceptas solo USDT y USDC, recibes stablecoins en dólares. Si también aceptas otras cripto, la conversión automática opcional a USDC o USDT está disponible en la mayoría de las redes soportadas. USDT vs USDC para pagos te ayuda a elegir.

«No instalo código de pagos que no puedo leer.»

Bien hecho, y no tienes por qué. El módulo de WHMCS son dos archivos PHP más el SDK oficial incluido, todo público con licencia MIT. No guarda datos de tarjeta ni direcciones de wallet. A Payzum solo le envía el número de factura, el importe, la moneda y tus URLs de callback y de retorno. El callback rechaza las peticiones sin firma antes de leer nada.