Plugin de pagos cripto: un checkout drop-in para tu tienda

Por qué "agregamos cripto en el próximo sprint" nunca sale

Pregúntale a cualquier dueño de tienda que lleva un año queriendo aceptar stablecoins por qué no lo hizo, y la respuesta rara vez es "no creemos en eso". Es el backlog. El checkout es el único lugar de una tienda online donde un bug cuesta dinero de verdad, así que se toca una vez al año, lo hace la persona más senior y con plan de rollback. Cualquier cosa que necesite un cambio ahí espera detrás de todo lo que no lo necesita.

Por eso las plataformas de carrito inventaron el plugin de pasarela. WooCommerce, PrestaShop, Magento, Shopify, Shopware y el resto exponen una API de pasarelas de pago: un contrato que le permite a un tercero registrar un método de pago, llevar al comprador por su propio flujo y reportar el resultado al pedido. Tarjetas, billeteras digitales, "compra ahora y paga después" y transferencias llegan a tu tienda por esa vía. Nadie reescribe el checkout para sumar un medio de pago; lo instala.

Cripto no entró en ese molde, por dos razones. Las pasarelas custodiales que sí ofrecen un plugin lo tratan como un embudo hacia su propio saldo: el comprador paga, la pasarela retiene, y tú recibes un retiro en su calendario, bajo su política de riesgo, a una cuenta bancaria que costó un KYC vincular. Y el camino de hacerlo a mano — generar una dirección, vigilar una cadena, contar confirmaciones, resolver pagos incompletos, rotar direcciones — es un proyecto de blockchain, no un cambio en el checkout, y vuelve a caer sobre el ingeniero senior con el plan de rollback.

Así que la pregunta que una tienda necesita responder es estrecha: ¿existe un plugin de pagos cripto que se comporte como el plugin de tarjetas que ya está instalado — instalar, configurar, activar — y liquide en una wallet que la tienda controla? Este artículo es sobre qué hace ese plugin por dentro, para que puedas juzgar uno, y cómo tenerlo funcionando antes de que termine el día.

Lo que te cuesta un checkout sin opción en stablecoins

El comprador que no puede pagar. Un cliente en un país donde las tarjetas se rechazan en comercios extranjeros, o donde el banco bloquea la operación por "riesgo", llega a tu checkout con intención y con dinero y se va sin gastar ninguno de los dos. Nunca lo ves en tu analítica; aparece como una tasa de conversión más baja justo en los mercados donde tus anuncios son más baratos.

El porcentaje sobre cada ticket. La pila de tarjetas se lleva su parte de cada pedido antes de que hayas pagado la mercadería, el envío o el anuncio que trajo al comprador. En una tienda con 10% de margen neto, un 3% de costo de cobro es un tercio de la ganancia — y nunca baja a medida que creces.

El contracargo que pierdes por defecto. Tarjeta no presente significa que la pérdida es tuya: la mercadería enviada, la disputa presentada seis semanas después, la comisión encima, y un ratio de disputas que se arrastra hacia el umbral del contrato con tu adquirente. La mecánica completa está en cómo reducir contracargos en tu tienda online; la versión corta es que con tarjetas puedes bajarlos, pero nunca eliminarlos.

El carrito abandonado. La investigación de largo plazo del Baymard Institute ubica la tasa promedio documentada de abandono de carrito cerca del 70%, y un checkout demasiado largo, demasiado complicado o sin el medio de pago que el comprador quería aparece de forma consistente entre las razones. Cada método de pago que no puedes ofrecer es una porción de ese número.

El trimestre de ingeniería. El camino a medida — vigilantes de cadena, manejo de direcciones, lógica de confirmaciones, conciliación — son semanas de trabajo que no producen nada que el comprador vea, y después hay que mantenerlo cada vez que cambia una cadena o un token. Es tiempo que no se invierte en las páginas de producto que sí mueven ventas.

Por qué los plugins custodiales y el desarrollo a medida se quedan cortos

Ninguna de las dos opciones es tonta. Cada una resuelve un problema distinto del que tiene una tienda.

Un plugin de pasarela custodial resuelve el problema de la pasarela. El plugin es fácil de instalar porque la parte difícil — retener el dinero — se movió a la pasarela. Los USDC del comprador caen en la wallet de la pasarela, quedan en tu "saldo" y te los retiran más tarde, en sus términos. Eso reproduce cada rasgo del adquirente de tarjetas del que querías salir: un saldo que se puede congelar, un calendario de retiros, una mesa de riesgo, una reserva para rubros de "riesgo elevado" y un segundo KYC. También significa una empresa más que puede cerrarte la cuenta.

El desarrollo a medida resuelve el problema de la blockchain. Generar una dirección de depósito por pedido, vigilar la mempool, decidir cuántas confirmaciones alcanzan, atender al comprador que envía 2% menos que la factura y conciliar todo contra los pedidos es ingeniería de verdad. También es ingeniería que no tiene nada que ver con vender zapatillas. La mayoría de las tiendas que arrancan por este camino se quedan a mitad, con una sola cadena soportada y una planilla para los pagos incompletos.

Lo que la tienda necesita de verdad es la ergonomía de lo primero — instalar, configurar, activar — con el modelo de liquidación de lo segundo: el dinero va a una wallet que la tienda controla, y nadie en el medio. Esa combinación solo existe cuando el procesador detrás del plugin es no-custodial por diseño. Si no, el plugin es una puerta a la bóveda de otro.

Qué hace de verdad un plugin de pagos cripto drop-in

Payzum es un procesador de pagos cripto sin custodia y solo-cripto. Sus plugins son delgados a propósito: no contienen lógica de wallet, ni vigilante de cadena, ni saldo. Hacen cuatro cosas, y las mismas cuatro en todas las plataformas.

1. Registrar un método de pago

El plugin registra "Payzum" como pasarela en el sistema de métodos de pago de la propia plataforma, así aparece en el checkout junto a tarjetas y billeteras, respeta las reglas de monedas y países de la plataforma y se activa o desactiva desde la pantalla de configuración que ya usas. En WooCommerce eso incluye el checkout por bloques y el almacenamiento de pedidos de alto rendimiento (HPOS); en Magento 2 es un módulo de método de pago; en Sylius se engancha al flujo PaymentRequest. Nada en tu tema cambia.

2. Crear el pago del lado del servidor

Cuando un comprador elige Payzum, el plugin — desde tu servidor, nunca desde el navegador — crea un pago con tu API key: el total del pedido, la moneda, una referencia del pedido y las URLs de callback. Es la misma llamada única que hace cualquier integración (la versión en tres pasos está en la página de integración). La API key vive en la configuración de tu plataforma y nunca llega al dispositivo de un cliente.

3. Entregar al comprador al checkout alojado

La respuesta incluye la URL de un checkout alojado. El plugin manda al comprador ahí — una página con un código QR, la dirección de depósito y el estado en vivo — donde elige la moneda y la cadena de la lista que tú permites y paga desde cualquier wallet. Sin campos de tarjeta, sin manejar cripto, nada que se sume a tu alcance PCI. El pago va de la wallet del comprador a una wallet que tú controlas, confirmado en la cadena en unos 0,4 segundos en Solana y alrededor de dos segundos en Base y Polygon.

4. Marcar el pedido como pagado desde el webhook firmado — nunca desde el navegador

Este es el detalle que separa un plugin que vale la pena instalar de uno que no. La confirmación en la cadena es asíncrona, así que un plugin correcto ignora el regreso del comprador a tu sitio como fuente de verdad y espera el webhook servidor-a-servidor de Payzum. El plugin de WooCommerce, por ejemplo, verifica cada webhook con una firma HMAC-SHA-512 sobre los bytes crudos de la petición, usa comparación en tiempo constante y una ventana anti-replay, y deduplica reenvíos — así un pedido nunca queda pagado por una petición falsificada, ni se despacha dos veces. Una pestaña cerrada nunca pierde un pedido pagado.

El webhook después traduce el estado del pago al estado de pedido que tu equipo ya conoce: un pago terminado mueve el pedido a "procesando" o "completado"; un pago parcial — el comprador envió menos que la factura — lo deja en espera con una nota; una factura vencida lo cancela; un pago fallido lo marca como fallido. Tu despacho, tus correos de notificación y tus reportes siguen funcionando, porque desde el punto de vista de la plataforma esto es solo otra pasarela que dijo "pagado".

Qué comparte el plugin, y qué no

A Payzum solo van el total del pedido, la moneda, una referencia del pedido y tus URLs de callback — ni nombre, ni dirección, ni correo del cliente. Hay una lista de monedas permitidas para aceptar todo o restringir las que se ofrecen en el checkout, un selector producción/staging para probar en un sandbox con su propia API key antes de tocar pedidos reales, y un log de depuración que escribe en el visor de logs de tu propia plataforma.

Alcance honesto: lo que el plugin no va a hacer por ti

Los reembolsos son pagos que inicias tú. Los pagos en la cadena son finales. Cuando tu política de devoluciones dice reembolso, ese reembolso es un pago que envías desde tu wallet, según los términos que el comprador aceptó en el checkout — más control del que te da un rail de tarjetas, y la política pasa a ser todo el acuerdo. Escríbela antes de activar el método.

Las listas en los marketplaces siguen en revisión. Ocho integraciones se instalan hoy desde sus registros de paquetes — Sylius vía Composer, Vendure vía npm, pretix y django-payments vía pip, Frappe/ERPNext con bench get-app, más Saleor, Akaunting y Omnipay. Las otras 21, incluidas WooCommerce, PrestaShop, Magento 2, Shopify y WHMCS, están públicas en GitHub y esperan su turno en colas de marketplace que tienen cada una su propio ciclo de revisión. Puedes clonar e instalar cualquiera desde el código fuente ahora mismo, o pedirnos el paquete armado y te acompañamos en la instalación.

Es un rail de pagos, no un contador. Un pago en la cadena con referencia y sello de tiempo es mejor insumo para tus libros que un resumen de tarjeta, pero el tratamiento contable, las reglas de consumo y tu situación fiscal las confirmas con tus propios asesores.

La volatilidad es una configuración

"Fijamos precios en dólares; no podemos tener algo que se mueva." No tienes que hacerlo. Activa la auto-conversión y lo que sea que use el comprador cae en tu wallet como USDC o USDT, así el monto que llega es el monto del pedido. La cadena es el transporte; la stablecoin es la unidad de cuenta. Para una tienda en Argentina, Colombia o México que ya piensa su lista de precios en dólares, eso es exactamente lo que faltaba.

Cómo instalar un plugin de pagos cripto, paso a paso

El plugin de WooCommerce es el ejemplo porque es el carrito más común; la secuencia es la misma en todas las plataformas, cambiando el comando de instalación.

1. Crea la cuenta y conecta tu wallet. Regístrate en Payzum, activa el 2FA y apunta la cuenta a una wallet que ya controlas — con la auto-conversión a USDC o USDT encendida si fijas precios en dólares. Nada queda nunca en Payzum. Genera una API key y un secreto de webhook desde el panel; genera una key de staging aparte si quieres probar primero.
2. Instala el plugin. Sube la carpeta del plugin a /wp-content/plugins/ o instala el zip desde Plugins → Añadir nuevo → Subir, y actívalo. El SDK de PHP viene incluido, así que no hay paso de Composer. Requisitos: WordPress 5.6+, WooCommerce 5.0+, PHP 8.1+. En otras plataformas: composer require payzum/sylius-payzum-plugin, npm i @payzum/vendure-plugin-payzum, pip install pretix-payzum o pip install django-payments-payzum, bench get-app para Frappe/ERPNext, o clona el repositorio para los carritos que siguen en revisión de marketplace.
3. Pega la key y el secreto. Ve a WooCommerce → Ajustes → Pagos → Payzum. Ingresa la API key y el secreto de webhook, elige producción o staging y, si quieres, restringe las monedas aceptadas con el selector múltiple que se carga en vivo desde tu lista permitida. Cada plataforma tiene la pantalla equivalente en su propia configuración de pagos.
4. Registra la URL del webhook. La pantalla de ajustes muestra la URL IPN de tu tienda en solo lectura — en WooCommerce es https://tu-tienda/wc-api/wc_gateway_payzum. Pégala en la configuración de webhooks del panel de Payzum. La cabecera de firma es fija; no hay nada más que configurar.
5. Corre un pedido de staging de punta a punta. Haz un pedido de prueba con la key de staging, págalo en el checkout alojado y mira cómo el pedido pasa a "procesando" cuando llega el webhook — no cuando vuelves a la tienda. Prueba un pago incompleto y confirma que queda en espera. El playground de integración del panel te deja inspeccionar las peticiones y respuestas reales mientras lo haces.
6. Actívalo en producción y escribe tu política. Cambia a la key de producción, activa el método y publica los términos de reembolso y cancelación que el comprador acepta en el checkout. Los pagos en este rail son finales, así que la política hace el trabajo que antes hacía el proceso de disputas.
7. Opcional: deja que un asistente de IA haga las partes a medida. Si tu tienda tiene algo no estándar — un flujo de pedidos propio, un front-end headless — pega merchant.payzum.com/llms.txt en Claude, ChatGPT o Cursor y el asistente recibe la referencia completa legible por máquina de la API, los webhooks y los SDKs.

Tiempo total para una tienda estándar: una tarde, la mayor parte dedicada al pedido de staging y al texto de la política. La versión para desarrolladores — endpoints, payloads y manejo de webhooks sin plugin — está en pasarela de pagos cripto por API REST.

Casos de uso: dónde un plugin de pagos cripto se paga solo

Cinco tiendas, cinco plataformas distintas, un mismo patrón de plugin.

• La marca DTC en WooCommerce que pierde ventas al exterior. Una marca de cuidado de la piel en Colombia vende a todo el continente y ve cómo la conversión se derrumba en tres mercados donde el rechazo de tarjetas extranjeras es rutina. El plugin suma una opción USDC/USDT al checkout en una tarde; los compradores de esos mercados pagan desde el saldo en stablecoins que ya tienen, el pedido pasa a "procesando" en segundos y la plata está en la wallet de la marca antes de que se imprima la etiqueta. Más contexto en aceptar pagos en stablecoins en tu tienda online.
• La tienda de productos digitales en Easy Digital Downloads sangrando por fraude. Licencias de software y plantillas se entregan al instante, lo que las vuelve el blanco favorito del fraude con tarjeta no presente: comprar, descargar, disputar. Con el plugin, la licencia se libera cuando el webhook firmado confirma un pago final; no hay ventana de seis semanas para que la descarga se convierta en pérdida.
• La empresa de hosting en WHMCS con clientes en todo el mundo. Facturas mensuales a clientes en cuarenta países, un porcentaje perdido en tarjetas y transferencias, y una cola de soporte de "me rechazaron la tarjeta". La integración con WHMCS suma una opción en stablecoins a la factura, el cliente paga desde donde esté y la factura se marca pagada desde el webhook — la misma conciliación que la empresa ya hace.
• El mayorista B2B en Magento 2 con pedidos de cinco cifras. Los límites de tarjeta vuelven incómodos los pedidos grandes y las transferencias los vuelven lentos. Un pago en stablecoins en el checkout liquida un pedido de US$20.000 en segundos, final, con la referencia del pedido adjunta — y el comprador, un revendedor en una economía con cepo cambiario, por fin tiene una forma de pagar al precio de lista en dólares.
• El organizador de eventos en pretix. Entradas vendidas con meses de anticipación, señas que vuelven como "servicio no prestado" cuando los planes cambian. Instalado con un solo pip install, el plugin cobra entradas en stablecoins que no se pueden disputar, con reembolsos emitidos bajo la política del organizador y no la de una red de tarjetas.

El plugin de Payzum vs la pasarela de tarjetas y los plugins cripto custodiales

Objeciones frecuentes, respondidas

“Mi carrito no está en la lista.”

Entonces no necesitas un plugin. Cualquier plataforma que pueda llamar a una API y redirigir al comprador puede usar el checkout alojado hoy: una llamada desde el servidor crea el pago, la respuesta te da la URL del checkout, el webhook firmado te avisa cuando está pagado. Los plugins son una comodidad, no un requisito. En las cuatro formas de añadir pagos cripto a tu tienda está la elección entre plugin, checkout alojado, links de pago y API.

“El plugin todavía no está en el marketplace de WordPress ni de Shopify. ¿Es seguro instalarlo desde GitHub?”

Es más seguro que la mayoría de lo que instalas desde un marketplace, porque puedes leerlo. Cada plugin y SDK de Payzum, y la especificación OpenAPI, son públicos en github.com/payzum-dev, así que tu desarrollador puede auditar el código antes de que toque tu tienda — no hay un binario en el que tengas que confiar. Las listas en los marketplaces llegan a medida que cada revisión se aprueba; el código no cambia cuando eso pasa. Si prefieres no clonar, pídenos el paquete armado.

“Ya tenemos Mercado Pago y Stripe. ¿Para qué una segunda pasarela?”

Quédatelas. El plugin agrega un método al lado, y las reglas de la propia plataforma deciden qué compradores lo ven. La pregunta no es qué rail gana el pedido doméstico con tarjeta; es qué rail lleva los pedidos que tu pila actual maneja peor — el comprador en el exterior cuya tarjeta se rechaza, el pedido de cinco cifras que un límite de tarjeta bloquea, la descarga digital que termina en disputa por fraude, el mercado donde tu adquirente directamente no te deja vender. Esos pedidos son exactamente para lo que existe este método.

“¿Qué pasa cuando un comprador paga de menos o la factura vence?”

El webhook le avisa al plugin, y el plugin le avisa al pedido. Un pago incompleto deja el pedido en espera con una nota que muestra cuánto llegó, para que tu equipo pida el saldo o lo reembolse bajo tu política; una factura vencida cancela el pedido y libera el stock; un pago fallido lo marca como fallido. Nada se adivina desde el navegador del comprador.