Cómo aceptar criptomonedas en tu web sin programar

Puedes aceptar pagos en cripto en una web sin construir un backend de pagos. Un enlace de cobro da a cada venta una página de pago alojada, mientras que un plugin oficial para CMS conecta el cobro en cripto con una tienda admitida. Las webs a medida pueden añadir la página de pago alojada o el Low-Code SDK cuando necesitan actualizar pedidos de forma automática sin diseñar ellas la pantalla de pago en blockchain.

La frontera importante es operativa. Las herramientas sin código quitan trabajo de integración, pero no convierten una transferencia en blockchain en un proceso de pedido completo. Cada venta sigue necesitando un importe, una referencia de factura, un estado de pago y una regla de entrega clara.

¿Qué necesita una web para aceptar pagos en cripto?

Una vía de pago que funciona tiene cuatro piezas. La web o el comercio crea una factura, el cliente ve una ruta exacta de activo y red, la blockchain registra la transferencia y el pedido cambia de estado tras la confirmación. Quitar código del primer paso no elimina los otros tres.

Paymos ofrece varias superficies sobre el mismo modelo de factura. Los enlaces de cobro cubren el envío directo y los botones sencillos de una web. Los plugins oficiales para CMS unen las facturas a los pedidos nativos de la tienda. La página de pago alojada pone el cobro en una web a medida, mientras que el Low-Code SDK mete ese flujo dentro de una página existente. La API REST encaja con un servidor que necesita control total de la creación de facturas y del estado del pedido.

Elige la vía menos a medida que conserve la regla de negocio. Un sitio escaparate que vende un solo servicio puede necesitar solo un enlace. Una tienda con stock cambiante y entrega automática necesita unión con el pedido.

¿Qué opciones no exigen código?

Dos vías arrancan sin desarrollo. Un enlace de cobro funciona como una URL normal: crea la factura, copia el enlace y ponlo en un correo, un chat, una factura o un botón de la web. Encaja con servicios de precio cerrado, señales y ventas donde ya hay una persona gestionando el pedido.

Un plugin oficial para CMS encaja con una tienda que corre sobre una plataforma admitida. Paymos ofrece plugins para WooCommerce, WHMCS, OpenCart, PrestaShop, Magento 2, Shopware 6, CS-Cart y Easy Digital Downloads. El plugin mantiene el pedido de la tienda y la factura del pago en un mismo flujo, lo que evita el cruce manual que exige un enlace suelto.

La página de pago alojada ya viene hecha, pero una web a medida sigue necesitando una forma de crear la factura y asociarla a un pedido. El Low-Code SDK añade una integración pequeña en el navegador. Ninguna de las dos es trabajo cero: reducen el desarrollo del cobro y conservan la lógica de pedidos que el comercio ya tiene.

¿Cómo funcionan los enlaces de cobro en una web?

Empieza por crear un proyecto en el panel de Paymos. Configura el nombre, el logotipo, los colores de la página de pago y las URL de retorno. Crea después una factura y usa su enlace de cobro como destino de un botón normal de «Pagar con cripto».

Guarda la referencia de negocio junto al enlace. Un negocio de servicios puede anotar el identificador de la factura en su CRM o en la nota del pedido. Un catálogo pequeño puede crear una factura por cada venta real en lugar de reutilizar una sola dirección de destino. Así el importe, el estado del pago y la conversación con el cliente quedan pegados al pedido correcto.

Un enlace de cobro rinde más cuando el precio y el paso de entrega los controla una persona. Si una página recalcula impuestos, existencias, plazas disponibles o un descuento en el momento de pagar, un enlace creado a mano puede quedarse desfasado. Ese es el punto para pasar de un enlace suelto a un plugin o a un cobro conectado.

¿Cuándo debería una tienda usar un plugin para CMS?

Usa un plugin cuando la plataforma de comercio ya sea la dueña del catálogo, del número de pedido, del precio y del estado de entrega. El plugin añade un método de pago en cripto a ese proceso en lugar de crear un segundo libro de pedidos fuera de la tienda.

La ventaja práctica es la alineación de estados. La tienda crea el pedido, Paymos crea la factura del pago y el resultado confirmado vuelve a ese mismo pedido. El personal puede investigar una factura impagada o vencida desde el contexto de negocio que la originó. El comprador no necesita una cuenta aparte de Paymos.

El soporte de plataforma importa. Paymos tiene ocho plugins oficiales para CMS, entre ellos WooCommerce, WHMCS y OpenCart. No instales una extensión de terceros con nombre parecido dando por hecho que sigue el mismo contrato de facturas, credenciales o webhooks. Empieza por la página de producto de Paymos para esa plataforma y prueba el flujo de pedido completo en Sandbox antes de activar Producción.

¿Cuándo encaja mejor la página de pago alojada?

La página de pago alojada encaja con una web a medida que ya crea pedidos. El servidor del comercio crea una factura y recibe un payment_url; el navegador abre esa URL como redirección o dentro de un iframe restringido. Paymos se queda con la interfaz de pago y el comercio conserva el precio, el stock, el acceso del cliente y la entrega.

Este reparto evita rehacer todo lo que mira a la billetera. La página de pago es responsive y admite pago por QR. Desde el teléfono, un toque lleva a Trust Wallet, MetaMask, Tonkeeper o Phantom con el importe y la red ya cargados, y cada billetera aparece solo en las redes que sabe atender. Con OKX el botón deja la dirección copiada y lanza la app. El idioma de la página se ajusta a quien paga, con el inglés como alternativa de reserva, y no hace falta cuenta de Paymos ni correo. El estado del pago se actualiza en la página sin recargarla.

La URL de retorno es navegación, no prueba de pago. Un comprador puede cerrar la página, quedarse sin conexión o volver a una ruta de éxito. La web debería cambiar el pedido solo a partir de un estado de pago verificado. La guía de facturación en cripto explica el ciclo de vida completo de una factura sin convertir este artículo en un segundo manual de API.

¿Cuánto código necesita el Low-Code SDK?

El Low-Code SDK se sitúa entre un enlace de cobro y una integración completa de servidor. Puede abrir el cobro dentro de la página o llevar al comprador a otra, así que una landing a medida, un formulario de donación o una calculadora de servicios conserva su diseño sin rehacer la pantalla de pago.

La frontera está en la entrega. Los eventos del navegador pueden actualizar lo que ve el comprador, pero no deberían liberar por su cuenta una descarga, activar un acceso ni despachar mercancía. De eso debe encargarse un sistema de pedidos de confianza a partir del estado confirmado de la factura.

Mantén las credenciales secretas fuera del código del navegador. Cuando la web necesita pedidos creados en servidor, reintentos seguros o notificaciones de pago firmadas, la vía sin código ha llegado a su límite. Lleva ese trabajo a la guía de la API REST en lugar de convertir el widget del navegador en un segundo backend.

¿Cómo debería la web unir el pago con un pedido?

Mantén una referencia de negocio estable para cada venta. Un plugin para CMS conserva la referencia del pedido de la tienda, mientras que un enlace de cobro gestionado a mano necesita que anotes su identificador de factura junto a la venta. Las integraciones a medida deberían hacer lo mismo en el sistema de pedidos del comercio.

Separa la página de retorno del resultado del pago. Una página de éxito solo demuestra que el comprador volvió a la web. El pedido debería seguir pendiente hasta que la factura alcance su estado confirmado.

La entrega también tiene que tolerar notificaciones repetidas. Registra que un pedido ya liberó su descarga, su acceso o su envío antes de ejecutar la acción. Si vuelve a llegar la misma notificación de pago, ese registro corta la segunda entrega. La guía de la API REST se encarga de los detalles de implementación; este artículo se encarga de la decisión de añadir ese control.

¿Qué debería ver el cliente en la página de pago?

Muestra juntos el activo y la red. «USDT» a secas no dice si el cliente debe enviar por Tron, Ethereum, BSC u otra ruta admitida. La página necesita además el importe exacto, el destino, el estado actual y suficiente contexto de tiempo para que el comprador termine la transferencia.

Paymos acepta cuatro stablecoins más XAUT, respaldado por oro, en 13 redes blockchain en producción. Los activos nativos de gas como ETH, BNB, TRX y SOL pagan las comisiones de red; no son activos de pago de facturas. La billetera de quien paga cubre la comisión de red entrante, y esa comisión varía según la cadena y las condiciones del momento.

Evita publicar una promesa fija del tipo «el pago tarda N segundos». La confirmación depende de la red, del importe del pago y del estado de la blockchain. Muestra en su lugar el estado vivo de la factura. Para el enrutamiento por token, lleva al cliente a las páginas de tokens admitidos en lugar de copiar una matriz larga de activos en cada página de producto.

¿Qué deberías probar antes de salir en real?

Prueba el resultado de negocio completo en Sandbox. Crea un pedido, abre la página de pago, simula el resultado admitido y comprueba que el pedido correcto cambia de estado una sola vez. Repite la notificación y verifica que la entrega no se ejecuta otra vez. Prueba después el vencimiento, la cancelación, el tratamiento del pago insuficiente y el caso del comprador que vuelve sin un pago confirmado.

Mantén separadas las credenciales de Sandbox y de Producción. Las credenciales de cobro y de pago de salida también son distintas, así que una integración de cobro no necesita permiso para retirar los fondos del comercio. Configura una dirección de retiro controlada por el comercio y añadida a la lista blanca antes de mover los activos liquidados.

Por último, deja documentado quién trata las excepciones. El personal necesita un sitio donde encontrar la factura, comparar su estado con el del pedido, revisar la entrega del webhook y reenviar un evento cuando el sistema receptor se recupere. El cobro sin código sale bien cuando las ventas normales piden menos ingeniería y las excepcionales siguen dejando un rastro operativo claro.