Aceptar pagos en cripto en tu hosting: sesenta segundos para entregar, cuatro meses para que te lo reversen
Puntos clave
- El hosting tiene la peor relación entrega-disputa del software. El VPS está vivo sesenta segundos después del checkout; el pago con tarjeta sigue siendo reversible durante una ventana que fijan las redes y se mide en meses. El CPU, el tráfico, la IPv4 alquilada y el tránsito que gastaste en el medio no se recuperan.
- Tu mercado es todo internet, pero la red de tarjetas no llega a todo internet. El Global Findex del Banco Mundial cuenta más de mil millones de adultos sin ninguna cuenta financiera, y tener cuenta es apenas el primer escalón: muchísima gente con banco no tiene una tarjeta que funcione para un cobro recurrente, internacional y sin presencia física.
- Una renovación caída en hosting no es una baja común. La tarjeta reemitida mata el cobro en silencio y la consecuencia es una cuenta suspendida, un sitio caído y un plazo de retención de datos corriendo sobre un cliente que nunca se enteró de nada.
- Payzum es un procesador sin custodia y crypto-only: suscripciones recurrentes, checkout alojado y plugin drop-in detrás de tu formulario, facturas con expiración y detección de sobrepago para planes anuales y dedicados, links sin código para migraciones, licencias y adicionales, pagos masivos por CSV para afiliados y revendedores, y una API REST con webhooks firmados que convierten un pago confirmado en una cuenta aprovisionada a las tres de la mañana.
- Alcance honesto, y acá es lo importante: la finalidad elimina los contracargos, pero también elimina la señal antifraude de la red de tarjetas. No hay AVS, no hay BIN, no hay rechazo del emisor. La verificación de tus clientes, el screening de sanciones, la política de uso aceptable y la mesa de abuso pasan a pesar más, no menos. Payzum es un rail de pagos: no es un registrador de dominios, no es una mesa de abuso y no es un programa de cumplimiento.
Por qué un hosting entrega en un minuto y queda expuesto durante meses
Todo negocio de suscripción tiene una brecha entre entregar el producto y tener certeza del dinero. En hosting la brecha es tan extrema que deja de ser un problema de finanzas y pasa a ser un problema de arquitectura.
Mirá lo que pasa realmente en un alta. Un cliente en cualquier parte del mundo completa el formulario de pedido a las 03:40 de su hora, paga, y la automatización hace el resto: se crea el contenedor o la VM, se aprovisiona la cuenta del panel, se asigna la licencia, se escriben los DNS, se le asigna una IPv4 de un bloque que vos alquilás y sale el mail de bienvenida con las credenciales de root. Tiempo total entre el pago y un servidor andando: menos de un minuto. Y todo tu posicionamiento competitivo depende de que ese número siga siendo menos de un minuto.
Ahora mirá el dinero. Si pagó con tarjeta, ese cobro sigue siendo reversible mucho tiempo. Las ventanas de disputa de las redes — documentadas en materiales como las Visa Core Rules — le dan al titular meses para abrir un reclamo. O sea: tu ventana de entrega es de sesenta segundos y tu ventana de exposición es de un tercio de año.
Esa asimetría sería manejable si lo entregado se pudiera recuperar. No se puede. Podés terminar la cuenta, y deberías, pero los recursos ya se consumieron: el CPU y la RAM que reservaste, los terabytes de tránsito que le pagaste a un upstream, la IPv4 que quedó ocupada y ahora está en zona gris de reputación, la licencia de panel o de sistema operativo que te facturó por instancia ese mes. Recuperar un servidor no es recuperar su costo.
Y por eso mismo el hosting es un blanco tan conocido. Un producto digital, de entrega instantánea, controlado en remoto y comprado con la tarjeta de otro no es solo una venta robada: es infraestructura. Esa misma cuenta se usa después para enviar spam, montar phishing, proxear tráfico, escanear internet o minar algo, con lo cual el proveedor absorbe un segundo costo después del contracargo: rangos de IP en listas negras, reclamos del upstream y daño de entregabilidad que termina cayendo sobre clientes legítimos que no hicieron nada.
Y después está el problema inverso, que es del que más se quejan los proveedores hispanohablantes: los clientes que quieren pagar y estructuralmente no pueden.
El hosting es uno de los poquísimos negocios cuyo mercado direccionable es, literalmente, cualquiera con conexión. Las estadísticas TIC de la UIT hablan de una población conectada de miles de millones de personas en todas las economías del planeta. Las redes de tarjetas no tienen esa huella. El Global Findex del Banco Mundial viene documentando hace años que más de mil millones de adultos no tienen ninguna cuenta financiera, y tener cuenta es apenas el primer escalón.
En la región el segundo escalón es todavía más alto. Un desarrollador en Caracas, La Paz, Buenos Aires o Lima puede escribir la aplicación, registrar el dominio con un revendedor local, y chocarse contra la pared justo en el paso que debería ser trivial: la tarjeta que no está habilitada para consumos en el exterior, el cupo mensual agotado, el recargo impositivo que encarece el plan un cuarto, la autorización previa para pagar al exterior, o directamente un banco que rechaza cualquier cobro recurrente internacional sin dar motivo. Los hostings vienen escuchando "¿aceptan cripto?" desde hace más de una década, antes y con más insistencia que casi cualquier otro rubro, y nunca fue una cuestión ideológica. Para una porción enorme de quienes construyen software, es el único rail que llega.
Por último, mirá la renovación, que es donde el modelo recurrente pierde plata en silencio. Un plan de hosting no es una suscripción prescindible que el cliente ve caer. Es la cosa sobre la que corre su negocio. Pero la tarjeta detrás vence, la reemiten después de una filtración en un comercio que no tiene nada que ver, o dispara un 3-D Secure que manda un código a un teléfono que el cliente cambió hace dos países. El cobro falla, los mails de aviso van a una casilla del dominio que está por suspenderse, y la primera noticia que tenés es un ticket que arranca con "se me cayó el sitio".
Lo que te cuesta el rail equivocado, mes a mes
El contracargo que llega cuando los recursos ya se gastaron. Un alta fraudulenta con tarjeta robada consume un mes de tránsito, una licencia, una IP y un asiento de soporte, y después se reversa. Perdés la venta, perdés el costo entregado y encima pagás una comisión por la disputa. Multiplicalo por tu tasa de fraude en altas instantáneas y tenés la línea más descontrolada del P&L de un hosting chico.
El ratio que te cambia de categoría. El adquirente no solo te cobra por cada disputa: mira el ratio. Cuando un comercio se acerca a los umbrales de monitoreo de las redes, la respuesta es suba de tarifa, reserva más alta, techos más bajos o una invitación a buscar otro procesador. Es la misma dinámica que conoce cualquier comercio que pelea contracargos, con el agravante de que acá tu producto puede ser usado como arma por quien está disputando.
La clasificación de alto riesgo que nadie te preguntó si querías. El área de riesgo lee hosting como: bien digital, entrega instantánea, sin prueba de envío para defender una disputa, clientes globales sin presencia física, cobro recurrente, cuentas semianónimas, una capa de revendedores que no controlás directamente y contenido de terceros desconocido corriendo en tus servidores. Ese perfil produce tarifas más altas, liquidación demorada y reservas rotativas. Y una reserva sobre un negocio de infraestructura es especialmente cruel, porque tus costos — housing o nube, compromisos de tránsito, alquiler de hardware, alquiler de IPv4, licencias de panel y sistema operativo, guardias — vencen todos los meses, mire lo que mire tu procesador.
La ola de card testing. Como el formulario de pedido de un hosting es una compra barata, rápida y automatizada, sirve de validador de números de tarjeta robados. Una ráfaga de autorizaciones chicas te cuesta comisiones de gateway, te ensucia las métricas de fraude y a veces te marca la cuenta de comercio por algo de lo que fuiste víctima, no causa.
La baja involuntaria que el cliente vive como falla de servicio. Cuando la renovación muere por una tarjeta reemitida, el cliente no experimenta "un problema de facturación". Experimenta una caída. Después una suspensión. Después un plazo de retención acercándose al borrado. A la mayoría los vas a recuperar, pero los vas a recuperar por la cola de soporte, con una disculpa y muchas veces con una bonificación — y algunos se van a mudar al competidor que tenía una tarjeta viva. Es exactamente el modo de falla que describimos en suscripciones en cripto sin contracargos, y en hosting duele más porque el producto es estructural.
El reloj de la garantía de devolución. Casi todos los hostings publican una, típicamente de treinta días. Con tarjeta, un cliente descontento tiene dos formas de invocarla: tu política, o su banco. Muchos eligen el banco, y eso convierte una devolución de rutina que ibas a dar igual en una disputa en tu historial.
Comisiones cross-border en un negocio sin fronteras. Intercambio, más assessment internacional, más spread de cambio, aplicado a una base global con ticket promedio chico, es un impuesto proporcional a la forma exacta del negocio. Sobre un compartido de 6 dólares el porcentaje es brutal; sobre un dedicado de 400 es un número real.
El lote de afiliados y revendedores. El hosting tiene uno de los ecosistemas de afiliados más grandes de internet y un canal de revendedores repartido en decenas de países. Pagarle a doscientos afiliados con transferencias individuales significa doscientas comisiones, doscientos horarios de corte, algunos pagos que llegan cortos después de las deducciones de los bancos corresponsales, y un bloque de administración mensual que crece en línea con el canal que tardaste años en construir.
Y el fraude de datos de pago sobre ese mismo lote. Vale nombrarlo porque es caro y no depende del rail: el IC3 del FBI viene documentando hace años que el business email compromise — hacerse pasar por un beneficiario para desviar un pago legítimo — está entre las categorías más costosas de delito informático. El afiliado que manda datos nuevos de cobro justo antes del lote mensual es el vector clásico. Verificar los datos del beneficiario por un canal aparte es el control que más importa, en cualquier rail.
Por qué tarjetas, PayPal y transferencias fallan en algún punto del hosting
Ninguno de estos rails está mal hecho. Cada uno se diseñó sobre supuestos que el hosting viola.
La tarjeta supone un bien físico y un consumidor a proteger. Todo el marco de disputas existe para proteger a un titular que pagó y no recibió, y su modelo de prueba es el envío: número de seguimiento, confirmación de entrega, firma. Un hosting no tiene nada de eso. Tenés logs que muestran un login desde una IP, que es exactamente lo que también mostrarían los logs de un defraudador. Sos estructuralmente la parte débil en cada disputa, y lo sos además siendo el que ya pagó el tránsito.
La tarjeta supone una credencial guardada que sigue siendo válida. El modelo recurrente funciona hermoso con un cliente de tarjeta estable en un país estable. Los clientes de hosting son desproporcionadamente desarrolladores, freelancers, agencias y startups: móviles, transfronterizos, usando la tarjeta que tenían cuando se dieron de alta hace tres años. Cada reemisión es una cancelación no anunciada de una suscripción que nadie quería cancelar.
PayPal y las billeteras similares agregan custodia encima. Resuelven parte del problema de alcance y nada del de reversibilidad, e introducen uno nuevo: un saldo que es tuyo pero está en una cuenta que otro puede limitar, revisar o retener. Para un negocio que tiene que pagar un compromiso de tránsito el día 1, "tu plata existe pero está en revisión" no es un tecnicismo.
La transferencia funciona y no la usa nadie. Es final, barata a escala y universalmente entendida — y tarda de uno a cinco días hábiles, solo en horario bancario, con una referencia que el cliente va a escribir mal. Es incompatible con un producto cuyo argumento de venta es que existe sesenta segundos después de que decidiste comprarlo. La transferencia es lo que usa tu cliente de colocation. No es lo que usa un formulario de pedido.
Y debajo de los tres está la custodia. Quien tenga tu dinero entre el pago del cliente y tu cuenta define cuándo lo cobrás y bajo qué condiciones deja de dártelo. Ciclos de liquidación, reservas rotativas y revisiones de cuenta son versiones del mismo hecho estructural. Un hosting con compromisos mensuales de infraestructura es precisamente el tipo de negocio para el que "retenido hasta el jueves, o hasta que terminemos de mirarte" es un riesgo operativo real.
Cómo Payzum te permite aceptar pagos en cripto en tu hosting y pagarle al canal
Payzum es un procesador de pagos cripto sin custodia y crypto-only. Esa primera palabra es la que importa cuando tenés una factura de upstream venciendo el día 1: los fondos van directo a wallets que controlás vos. No hay saldo de Payzum, no hay lote de liquidación esperando un corte, no hay reserva retenida contra un código de rubro. La liquidación es el pago. La confirmación on-chain tarda segundos — unos dos segundos en Base y Polygon, bastante menos de uno en Solana — y una vez confirmada es final. Nadie la reversa cuatro meses después porque el número de tarjeta resultó robado. La mecánica está desarrollada en nuestra guía del procesador de pagos cripto sin custodia.
La auto-conversión opcional a USDC o USDT hace que el monto que cotizaste sea el monto que te queda. El hosting se cotiza en dólares en casi todo el mundo, incluidos los proveedores que banquean en otra moneda, así que liquidar en una stablecoin denominada en dólares elimina un desfase en vez de crearlo.
Los instrumentos, mapeados a cómo factura un hosting de verdad
- Suscripciones recurrentes — instrumento estrella número uno. Planes mensuales, trimestrales, anuales y bianuales cobrados sobre un rail donde no hay tarjeta guardada que venza, ni reemisión que corte la cadena, ni 3-D Secure que mande un código a un teléfono que el cliente ya no tiene. La renovación que fallaba en silencio y dejaba un sitio caído deja de ser una categoría operativa.
- API REST y webhooks firmados — instrumento estrella número dos. En hosting el webhook es el producto. Un webhook firmado se dispara en el instante en que confirma el pago y tu automatización hace lo que ya hace: crear la cuenta, asignar la licencia, escribir los DNS, mandar las credenciales. Firmado, para que tu endpoint de aprovisionamiento pueda verificar que la llamada vino realmente del procesador. Hay un playground de integración para probarlo antes de que toque capacidad real. En pasarela de pagos cripto con API REST está la forma completa.
- Checkout alojado y plugin drop-in. Redirect, modal o inline detrás de tu formulario de pedido actual, o un drop-in sobre la plataforma que ya usás. Tu embudo, tu marca, tus upsells: un método de pago nuevo en el último paso, no un sistema de facturación nuevo.
- Facturas con expiración y detección de sobrepago. Para planes anuales, servidores dedicados con costo de setup, bloques de IPv4, housing y contratos corporativos. La factura lleva tu referencia — ID de cuenta, hostname del servidor, número de contrato — y expira en la fecha que definas, así una cotización no queda viva al precio del trimestre pasado. La detección de sobrepago engancha al cliente que redondea para arriba o paga dos facturas juntas.
- Payment links y botones, sin código. Para todo lo que no es un plan: un servicio de migración, un certificado SSL, una licencia de panel, una IP extra, un adicional de mitigación DDoS, un excedente de tráfico, una hora suelta de sysadmin. Soporte manda un link desde el ticket, se financia en minutos y arranca el trabajo.
- Pagos masivos por CSV. Un archivo liquida todo el canal: afiliados, revendedores, sysadmins freelance y soporte remoto, recompensas de bug bounty, partners de referidos. Los payouts en stablecoins corren sobre Polygon, Arbitrum, Optimism, Base, BNB Chain y Avalanche; los payouts por CSV además cubren BTC, LTC y DOGE. Es el mismo mecanismo de lote que describimos en pagar afiliados en cripto.
- POS con QR por venta y cajeros con PIN. No todo hosting es una cara detrás de un formulario. Muchos ISP y proveedores regionales de la región tienen oficina con atención al público donde los clientes pyme pagan su plan mensual en el mostrador. Cualquier teléfono es una terminal, cada puesto tiene su PIN y la analítica es por cajero y por terminal.
- x402 para la parte medida de tu plataforma. Si además vendés algo con precio por llamada — almacenamiento de objetos, un endpoint de imágenes o transcodificación, inferencia en GPU, una función serverless — Payzum se para como middleware delante de tu API existente. Configurás tu endpoint, tu API key y un precio en un dashboard; Payzum publica una URL x402, devuelve el
402, gestiona el pago a través de un facilitator externo y hace de proxy reenviando la llamada pagada a tu endpoint real con tu key. Sin protocolo que implementar y sin código, y los agentes de IA pagan por request en USDC sobre Base. El contexto está en x402: pago por llamada de API.
El camino de aprovisionamiento, en detalle
Vale ser concreto acá, porque es donde una integración de hosting funciona o no funciona.
Hoy, con tarjeta: el cliente envía el formulario, el gateway autoriza, tu sistema de facturación marca la factura pagada, se dispara el aprovisionamiento, el servidor queda vivo. Dos o tres días después el dinero se liquida en una cuenta del adquirente. Y en algún momento entre hoy y dentro de cuatro meses, una fracción de esos cobros vuelve para atrás.
Con Payzum: el cliente elige la opción cripto en el checkout y paga desde su propia wallet. La transacción confirma on-chain en segundos. Payzum dispara un webhook firmado a tu endpoint. Tu sistema verifica la firma, marca la factura pagada y el aprovisionamiento corre exactamente como corre hoy. El servidor queda vivo en el mismo plazo que tus clientes ya esperan. La diferencia está del otro lado: los fondos ya están en una wallet que controlás y la confirmación es final. No hay demora de liquidación, no hay reserva, y no hay una decisión de un tercero pendiente por los próximos ciento veinte días.
Para la mayoría de los proveedores esto es un cambio en una rama de un flujo de facturación existente, no una migración. Tu panel, tu automatización, tu lógica de avisos, tu base de clientes y tu lista de precios quedan donde están.
Alcance honesto: la finalidad elimina contracargos y también elimina tu señal antifraude
Leé esta sección dos veces, porque es la parte que la mayoría del contenido sobre cripto para hosting directamente omite, y equivocarse acá cuesta más de lo que costaban los contracargos.
Cuando cobrás con tarjeta, la red te regala un set de señales antifraude: verificación de domicilio, BIN y país del emisor, datos de velocidad de toda la red y, sobre todo, el rechazo del propio emisor. Una parte importante de tus altas fraudulentas de hoy se frena antes de que las veas, gracias a un banco al que no le pagás por ese servicio.
Un pago desde wallet no trae nada de eso. Es final, que es justo lo que querías, y es en buena medida no autenticado en cuanto a identidad, que es el intercambio que estás haciendo. La consecuencia práctica para un hosting es directa: tu propio screening en el alta, tu política de uso aceptable y tu respuesta a abuso tienen que ser más fuertes, no más débiles. Verificación de identidad proporcional al plan, screening de sanciones y listas de personas designadas sobre tus clientes, límites de tasa en el aprovisionamiento y una mesa de abuso que efectivamente conteste no son extras opcionales en este rail: son lo que reemplaza al rechazo del emisor.
El producto de Payzum incluye KYC, 2FA, secretos encriptados, webhooks firmados y audit log completo. Eso asegura y documenta tu cuenta de comercio y el registro del pago. No es —ni se ofrece como— un programa de screening de tus clientes ni un sustituto de tu manejo de abuso. Ese trabajo sigue siendo tuyo, como en cualquier rail.
Dicho con justicia, el intercambio le conviene a casi cualquier hosting: cambiás un pasivo ilimitado que resuelve un tercero por un problema de control acotado y propio, para el que ya tenés gente. Pero es un intercambio, no un regalo, y quien te diga lo contrario nunca operó una mesa de abuso.
Qué más no hace este rail
- No es un registrador de dominios ni un revendedor. Los requisitos de ICANN para registradores acreditados — exactitud de los datos de registro, política de transferencias, procedimientos de disputa — viven en tu relación con el registrador y no cambian en nada por cómo cobrás.
- No es un régimen de responsabilidad de intermediarios ni de retirada de contenidos. Las notificaciones y retiradas, los reclamos de propiedad intelectual, los requerimientos de autoridades, la conservación de datos y las obligaciones que cada país impone a un prestador de servicios de alojamiento siguen siendo tuyas. En España, por ejemplo, el marco base sigue siendo la Ley 34/2002 de servicios de la sociedad de la información y de comercio electrónico, y equivalentes existen en toda la región.
- No es un motor fiscal. Vender hosting cruzando fronteras dispara obligaciones de lugar de prestación e IVA sobre servicios digitales en una lista creciente de jurisdicciones. Eso aplica a la venta, no al rail, y no cambia.
- No es escrow. La finalidad corta para los dos lados. Una devolución bajo tu garantía es instantánea, porque ya tenés el dinero — pero no hay nadie que arbitre una disputa por vos. Tu política de reembolsos tiene que estar publicada, ser clara y cumplirse, y tenés que mantener la liquidez para cumplirla.
- No es una empresa de nómina ni un employer of record. Pagarle a sysadmins remotos y a soporte en un lote es un pago; la clasificación laboral, los contratos, las retenciones y las obligaciones de nómina siguen siendo tuyas.
- No hay liquidación en moneda fiat. Payzum es crypto-only: liquida cripto en tu wallet, con auto-conversión opcional a USDC o USDT. Convertir a tu moneda local, si lo necesitás, es un paso aparte con tu propio proveedor.
La volatilidad es una configuración, no un riesgo
La objeción refleja es el movimiento de precio, y para un negocio con compromisos mensuales de infraestructura merece una respuesta derecha. La auto-conversión a USDC o USDT te deja aceptar un pago y quedarte con una stablecoin denominada en dólares, emitida contra reservas sobre las que el emisor reporta — Circle publica composición de reservas y atestaciones de USDC. Si el cliente paga en otra cosa, la conversión la hace el sistema. No estás tomando una posición de mercado: estás eligiendo una moneda de liquidación, y para un hosting esa moneda ya era el dólar, porque en dólares están tu lista de precios, tu compromiso de tránsito y tu hardware.
Cómo funciona, paso a paso
- Abrí la cuenta y conectá tus wallets. Vos das las direcciones donde querés cobrar — tus propias wallets, en las redes que elijas. Payzum nunca retiene los fondos. Activá la auto-conversión a USDC o USDT si querés que todo caiga denominado en dólares.
- Sumá el método al formulario de pedido. Checkout alojado como redirect, modal o inline, o el plugin drop-in sobre la plataforma que ya usás. Es una opción nueva en la última pantalla del embudo que ya tenés.
- Cableá el webhook de aprovisionamiento. Apuntá un webhook firmado al endpoint que tu sistema de facturación ya expone, verificá la firma y dejá que un pago confirmado marque la factura pagada y dispare el aprovisionamiento. Probalo en el playground de integración antes de que toque capacidad real.
- Activá suscripciones para las renovaciones. Pasá los planes mensuales y anuales a cobro recurrente sin tarjeta guardada que venza. Empezá por la cohorte donde más te fallan las renovaciones: clientes antiguos y clientes en el exterior.
- Armá facturas y links para todo lo que no es un plan. Una plantilla de factura con expiración y tu referencia de cuenta o hostname para dedicados, housing y contratos corporativos; unos cuantos presets de link para migraciones, licencias, IP extra y excedentes de tráfico, para que soporte cobre desde adentro del ticket.
- Corré el pago al canal en un solo lote. Armá el CSV de afiliados, revendedores, sysadmins freelance y bug bounties, y liquidá toda la lista en una sola corrida, cada uno en la red que le sirve.
- Si vendés algo medido, publicalo para agentes. Configurás endpoint y precio en el dashboard y tu API de almacenamiento, transcodificación o inferencia empieza a aceptar pagos por llamada en USDC sobre Base el mismo día, sin implementar vos el protocolo.
Casos de uso en un hosting
Situaciones concretas, todas semanas normales de este negocio:
- El alta de VPS a las 03:40 desde un mercado donde la tarjeta no llega. Un desarrollador en un país donde los consumos internacionales sin presencia física se rechazan de rutina paga desde su wallet, se dispara el webhook y la instancia queda viva antes de que termine de leer el mail de bienvenida. Sin revisión manual, sin "comuníquese con facturación", sin cliente perdido.
- La renovación anual que antes moría por una tarjeta reemitida. Un cliente de cuatro años con un plan anual de 180 dólares. Antes la renovación fallaba porque le habían cambiado el plástico tras una filtración ajena, la cuenta se suspendía y el primer contacto era un ticket enojado. Ahora es una suscripción recurrente sin nada que vencer.
- El revendedor en otro país comprando capacidad mayorista. Un partner white-label que paga mensualmente por un bloque de cuentas. Una suscripción recurrente en stablecoin, liquidando en segundos, en lugar de una transferencia internacional que llega tarde, corta y con una referencia que nadie puede conciliar.
- El servidor dedicado con costo de setup. Una factura con expiración fijada en la fecha en que dejás de reservar el hardware, con el hostname como referencia y detección de sobrepago activada. Se financia y el ticket de armado entra al datacenter esa misma tarde.
- El adicional cobrado desde adentro del ticket. El cliente necesita una IP extra, subir la licencia de cPanel, mitigación DDoS por una semana de campaña o una migración de urgencia un domingo. Soporte manda un payment link en el ticket, se financia en minutos, empieza el trabajo.
- El lote mensual de afiliados y revendedores. Doscientos cuarenta beneficiarios en treinta países, cada uno con un monto exacto. Un CSV, una corrida, cada uno cobrando completo en la red que le sirve — en lugar de doscientas cuarenta transferencias, la mayoría internacionales y varias llegando cortas.
- El mostrador del ISP regional. Un proveedor con oficina que cobra planes mensuales a pymes del barrio. QR por venta en un teléfono, un PIN por puesto, y una recaudación por cajero y por hora que es un reporte y no una discusión al cierre.
- El endpoint medido servido a agentes. La misma plataforma vende almacenamiento de objetos y un endpoint de inferencia en GPU. Configurados detrás del middleware x402 de Payzum, ambos empiezan a aceptar pagos por llamada en USDC sobre Base desde agentes autónomos — un segmento de clientes que no tiene tarjeta, ni formulario de alta, ni paciencia — mientras la API por debajo sigue exactamente igual.
Payzum vs adquirentes y billeteras para un proveedor de hosting
| Dimensión | Tarjetas, PayPal y transferencia | Payzum |
|---|---|---|
| Velocidad de liquidación | Tarjeta 1–3 días; saldos de billetera sujetos a retenciones; transferencias 1–5 días hábiles y solo en horario bancario | Confirmación on-chain en segundos — unos 2s en Base y Polygon, menos de 1s en Solana — cualquier día, a cualquier hora |
| Dónde caen los fondos | Retenidos por el adquirente durante su ciclo, o en un saldo de billetera que un tercero puede limitar | Directo a una wallet que controlás vos. No hay saldo de Payzum para retener, agrupar o reservar |
| Reversibilidad sobre un servidor aprovisionado al instante | Reversible durante meses según las ventanas de disputa, y sin prueba de envío con la cual defenderte | Final al confirmar. Sin contracargos y sin comisiones por disputa |
| Señal antifraude | AVS, BIN y rechazo del emisor incluidos — y un contracargo cada vez que se les escapa uno | Sin señal antifraude de red. Tu propio screening en el alta, tu control de sanciones y tu mesa de abuso cargan con eso |
| Renovaciones | Mueren en silencio por vencimiento, reemisión o un 3-D Secure — el cliente se entera cuando se cae el sitio | Suscripciones recurrentes sin tarjeta guardada que venza ni emisor que rechace |
| Alcance geográfico | Lo que cubran las redes de tarjeta, menos todo cliente cuyo banco bloquee cobros recurrentes internacionales | Cualquier lugar con internet y una wallet — la misma huella que tu producto |
| Forma del costo | Intercambio + assessment internacional + spread de cambio, como porcentaje de cada ticket | Comisiones de red medidas en centavos en las redes de stablecoins soportadas, no un porcentaje del ticket |
| Riesgo de cuenta | El hosting se suscribe como alto riesgo: tarifas más altas, techos, reservas rotativas mientras vence tu compromiso de tránsito | Nada queda en una cuenta del procesador, así que no hay saldo para congelar ni reservar |
| Pagar afiliados y revendedores | Transferencias individuales, cada una con comisión, corte y modo de falla; algunas llegan cortas | Un lote CSV sobre Polygon, Arbitrum, Optimism, Base, BNB Chain y Avalanche (más BTC/LTC/DOGE) |
| Vender a agentes de IA por llamada | No existe — un agente no tiene tarjeta ni formulario de alta | Middleware x402 delante de tu API existente: los agentes pagan USDC en Base por request, liquidado vía un facilitator externo |
Objeciones frecuentes, respondidas
"¿No vamos a atraer justo a los abusadores que intentamos sacar de la red?"
Es la pregunta correcta y merece una respuesta real, no una palmada. Eliminar los contracargos elimina el incentivo del defraudador a usar un instrumento robado: no hay nada que reversar ni nada que monetizar disputando. Lo que no hace es decirte quién es el cliente. Así que la posición honesta es que tus controles de abuso tienen que trabajar más: verificación de identidad proporcional al tamaño del plan, límites de tasa en el aprovisionamiento, screening de sanciones y listas de designados, y una mesa de abuso que conteste de verdad. La mayoría de los hostings ya tiene todo eso, porque el fraude con tarjeta tampoco frenaba el abuso: simplemente hacía que te enteraras después, por un banco. Lo que cambia es que ahora te enterás en el alta y no en el contracargo.
"Facturamos con WHMCS / Blesta / algo propio. ¿Esto es reescribir todo?"
No. La superficie de integración es un checkout al que redirigís al cliente (o un modal, o un elemento inline, o el plugin drop-in) y un webhook firmado que consume tu sistema de facturación. Tu automatización de aprovisionamiento no cambia en nada: ya se dispara con "factura pagada", y esto es otra cosa que produce ese evento. La mayoría lo suma como una opción de pago detrás del formulario que ya tiene y deja todos los demás rails exactamente donde están. Hay API REST y playground de integración para las partes que sí quieras cablear más a fondo.
"¿Nuestros clientes realmente van a pagar así?"
El hosting es de los pocos rubros donde no hay que adivinar, porque la demanda llegó antes que la oferta. Los proveedores vienen escuchando "¿aceptan cripto?" hace más de una década, y la demanda más fuerte viene justamente de los segmentos que el rail de tarjetas atiende peor: desarrolladores en mercados con cobertura de tarjeta fina, cupos, recargos o controles de cambio; agencias que facturan cruzando fronteras; compradores que cuidan su privacidad; y clientes antiguos cansados de recargar la tarjeta cada vez que se la reemiten. Empezá ofreciéndolo al lado de tus métodos actuales y mirá quién lo toma. No estás migrando a nadie.
"¿Qué pasa con nuestra garantía de devolución de treinta días?"
Funciona, y funciona más rápido: ya tenés el dinero, así que la devolución es un pago que enviás y no una reversa que esperás. Lo que cambia es que no hay emisor al que apelar, en ninguna de las dos direcciones. Eso convierte a la política escrita en el acuerdo completo: publicala clara, aplicala parejo y mantené la liquidez para cumplirla. En la práctica la mayoría encuentra que los reembolsos se vuelven más simples, porque la discusión sobre si el dinero vuelve deja de involucrar a un tercero que decide con evidencia que ninguno de los dos controla.
"Somos un hosting de cinco personas. ¿Esto es un proyecto de infraestructura?"
El checkout y el webhook son una tarde para quien mantiene tu facturación, y los links, las facturas y las suscripciones son sin código desde un dashboard. El primer paso realista es más chico que un proyecto: sumá el método a una línea de producto — los VPS, por ejemplo — mirá un mes de altas y renovaciones, y compará los números de contracargos y renovaciones caídas contra el mes anterior.
Preguntas frecuentes
¿Cómo acepta pagos en cripto un hosting, en la práctica?
Con cuatro instrumentos, normalmente juntos. Checkout alojado o plugin drop-in detrás del formulario de pedido existente. Un webhook firmado que se dispara apenas confirma el pago, para que tu facturación marque la factura pagada y el aprovisionamiento corra igual que hoy. Suscripciones recurrentes para planes mensuales y anuales, sin tarjeta guardada que venza. Y facturas con expiración más payment links sin código para dedicados, costos de setup, migraciones, licencias y adicionales. Todo liquida on-chain en segundos, directo a una wallet que controla el proveedor, con auto-conversión opcional a USDC o USDT.
¿Aceptar cripto elimina los contracargos de un hosting?
Sí para los pagos cobrados por esta vía: la liquidación on-chain es final al confirmar, así que no hay ventana de disputa, no hay reversa meses después de que los recursos se consumieron y no hay comisión por disputa. Pero hay que ser claros con el intercambio: la finalidad también elimina la señal antifraude de la red de tarjetas. No hay verificación de domicilio, ni BIN del emisor, ni rechazo del emisor jugando a tu favor. Tu propio screening en el alta, el control de sanciones, los límites de tasa en el aprovisionamiento y tu mesa de abuso tienen que cargar con eso.
¿Cómo sigue siendo instantáneo el aprovisionamiento si el cliente paga en cripto?
Con webhooks firmados. La transacción confirma on-chain en segundos — unos dos segundos en Base y Polygon, menos de uno en Solana — y Payzum dispara un webhook firmado a tu endpoint. Tu sistema verifica la firma, marca la factura pagada y dispara la misma automatización de siempre: crear la cuenta, asignar la licencia, escribir los DNS, mandar las credenciales. La experiencia del cliente no cambia; lo que cambia es que el dinero ya es final y ya está en tu wallet.
¿Qué pasa con las renovaciones si no hay tarjeta guardada?
Dejan de fallar por los motivos por los que fallan hoy. Una suscripción recurrente en este rail no tiene tarjeta guardada que venza, ni reemisión tras una filtración ajena que corte la cadena, ni 3-D Secure que mande un código a un teléfono que el cliente cambió. Eso pesa más en hosting que en casi cualquier otro negocio de suscripción, porque una renovación caída acá no significa solo una baja: significa una suspensión, un sitio caído y un plazo de retención de datos corriendo sobre un cliente que nunca se enteró de nada.
¿También podemos pagarles así a nuestros afiliados y revendedores?
Sí, con pagos masivos por CSV. Un archivo liquida todo el canal en un solo lote: afiliados, revendedores white-label, sysadmins freelance y soporte remoto, recompensas de bug bounty y partners de referidos. Los payouts en stablecoins corren sobre Polygon, Arbitrum, Optimism, Base, BNB Chain y Avalanche, y los payouts por CSV además cubren BTC, LTC y DOGE. Cada beneficiario recibe el monto exacto acordado. La clasificación laboral, los contratos y las obligaciones de nómina siguen siendo tuyas: esto es un rail de pagos, no una empresa de nómina.
Vendemos servicios medidos. ¿Pueden pagarnos los agentes de IA por llamada?
Sí, con x402, y sin implementar el protocolo. Payzum actúa como middleware delante de tu API existente: configurás tu endpoint, tu API key y un precio en un dashboard, Payzum publica una URL x402, devuelve el 402, gestiona el pago a través de un facilitator externo y hace de proxy reenviando la llamada pagada a tu endpoint real con tu key. Los agentes pagan en USDC sobre Base, por request, directo a tu wallet. Tu API no cambia y vos no escribís código.
Agendá 20 minutos y lo diseñamos para tu plataforma de hosting
Contanos cómo es tu stack — el formulario de pedido y el sistema de facturación, de dónde salen realmente los contracargos y las renovaciones caídas, cuántos afiliados y revendedores liquidás por mes, en qué mercados te falla el rail de tarjetas y si vendés algo medido por llamada — y mapeamos el lado del cobro (checkout alojado, webhook de aprovisionamiento firmado, suscripciones que no vencen, facturas y links para todo lo demás) y el lado del pago (un solo lote CSV sobre las redes que le sirven a tu canal) para tu caso concreto. Sin custodia, crypto-only, directo a una wallet que controlás vos.
Si el calendario no carga, agendá una reunión acá · [email protected]
Este artículo es información general, no asesoría legal, fiscal ni financiera. La verificación de identidad de tus clientes y el screening de sanciones y personas designadas, la política de uso aceptable y el manejo de abuso, las obligaciones de notificación y retirada y de responsabilidad como prestador de servicios de alojamiento, los requerimientos de autoridades, la protección de datos, la localización y conservación de la información, las obligaciones vinculadas a registradores de dominios e ICANN, las normas de contratos y devoluciones con consumidores, el lugar de prestación e IVA sobre servicios digitales y los impuestos societarios siguen siendo tu responsabilidad como proveedor. Payzum es un rail de pagos: no es un registrador, ni un agente de escrow, ni un servicio de moderación o mesa de abuso, ni un programa de cumplimiento o screening de tus clientes, ni un motor fiscal, ni una empresa de nómina. La liquidación on-chain es final, lo que elimina los contracargos y también elimina las señales antifraude de las redes de tarjetas: planificá tus propios controles en consecuencia. Confirmá las normas aplicables en cada país donde vendés, alojás o pagás con tus propios asesores.