Cobra en cripto dentro de Telegram, sin página web

Un proyecto de Paymos puesto en el canal de Telegram cobra dentro del chat. El enlace de pago de su factura entra directo en el bot de Paymos: quien paga lo abre en Telegram, elige activo y red, recibe una dirección de depósito con su código QR y ve el estado sin salir de la conversación.

En esa venta no aparece ninguna web. Quien paga no necesita cuenta en Paymos, y el canal tampoco se elige factura a factura: queda fijado en el proyecto, y todas sus facturas se comportan igual.

Un proyecto de bot de Telegram no tiene página de pago alojada. No hay ninguna detrás del bot ni al lado como recambio, y sus URL de retorno, si están puestas, son enlaces de Telegram: la venta se queda donde ya estaba el cliente.

Eso suena a que falta algo, hasta que uno se pregunta qué pintaba una web en una venta que ocurre hablando. En el canal de Telegram el cobro se presenta donde el cliente ya estaba, así que la página no se cambia por un sustituto: no forma parte del recorrido.

Elegir entre los métodos disponibles cuando sí existe una web es asunto de esta guía. Aquí está la capa de debajo: qué es el canal de Telegram, qué quita y qué deja donde estaba.

¿Qué significa cobrar en cripto dentro de Telegram?

Cobrar en cripto dentro de Telegram significa que el pago ocurre en una conversación con un bot y no en una página web. Telegram describe sus bots como aplicaciones pequeñas que funcionan por completo dentro de la propia aplicación, de modo que no hay nada que instalar ni un segundo producto que aprender.

La forma que toma un cobro de Paymos en ese chat es corta. El comercio manda el enlace de la factura, quien paga lo abre en Telegram y el bot se encarga del resto: primero activo y red, después la dirección de depósito y el código QR, y al final el estado.

Lo único que hace falta por el otro lado es Telegram y una billetera con el activo elegido. Paymos no pide nada más: ni cuenta, ni una web por el camino, ni ningún programa nuevo para completar ese pago.

¿Dónde se decide el canal del proyecto?

El canal de cobro es una propiedad del proyecto de Paymos. Se elige una sola vez, cada factura creada bajo él hereda ese ajuste, y un proyecto está en un canal: no existe estar a medias en uno y a medias en otro.

Por eso una factura de Paymos no lleva canal propio. Crearla no obliga a elegir canal, y ningún campo de la petición ofrece esa elección, porque el proyecto al que pertenece ya había resuelto la pregunta antes de que la factura existiera.

A quien llama a la API de Paymos le conviene saberlo antes de la primera factura y no después. El cuerpo de la petición y la forma de la respuesta son los documentados; lo que apunta a un destino distinto según el proyecto que la emitió es la payment_url de dentro.

Un correo de confirmación que da por hecho una web describe entonces algo que no va a pasar. El texto alrededor del enlace es del comercio, y tiene que corresponder al canal del proyecto.

¿Qué sustituye a la página de pago alojada?

En un proyecto de bot de Telegram, la payment_url de la factura es un enlace directo al bot de Paymos. Se comporta como cualquier otro enlace —se manda, se toca y se reenvía igual—, y lo que se abre al tocarlo es Telegram.

Telegram documenta el formato que hay debajo. Un enlace de bot tiene la forma https://t.me/<bot_username>, admite un parámetro de hasta 64 caracteres, y el bot lo recibe en el momento en que se abre la conversación, sin que el usuario tenga que escribir nada.

Debajo no hay página. Un proyecto de bot de Telegram no tiene ninguna alojada, así que el bot no es una envoltura alrededor de un cobro que además exista en la web: para ese proyecto, la versión web nunca llegó a crearse.

Para el comercio eso significa que no queda nada que mantener aparte. No hay una segunda dirección que dar a quien no use Telegram, ni una página cuyo aspecto se configure por separado del bot.

¿Qué hace en el bot quien paga?

Lo primero que elige quien paga es activo y red. El bot de Paymos responde con una dirección de depósito y un código QR, y esas dos elecciones van delante porque solo juntas describen una ruta de pago: ninguna de las dos está completa por su cuenta.

Un activo por sí solo no identifica un destino, y de ahí que el bot de Paymos pregunte por los dos. USDT en Tron y USDT en Ethereum son transferencias distintas a direcciones distintas, y evitar esa confusión es justo lo que hace la selección en dos pasos.

El código QR aparece porque la billetera suele ser una segunda aplicación en el mismo teléfono. Escanear se lleva por delante el paso de copiar una dirección a mano entre dos aplicaciones y luego revisarla carácter a carácter.

Después llega la transferencia desde la billetera y la factura sigue su camino de estados. Dónde se lee ese estado en un proyecto de bot de Telegram, y cuánto se espera hasta la confirmación, es lo que viene a continuación.

¿Dónde se sigue el estado de la factura?

En un proyecto de bot de Telegram el estado se sigue dentro de Telegram. Es la misma superficie que pidió activo y red y devolvió la dirección de depósito, así que ninguna parte del pago está en otro sitio mientras se confirma.

Pagar obliga a salir de la pantalla de cobro en cualquier canal. Quien paga se va a la billetera, envía y vuelve; en un proyecto de bot de Telegram, volver es abrir otra vez la conversación con el bot de Paymos y leer ahí en qué punto está.

La espera de en medio no la acorta el comercio. Cuántas confirmaciones se exigen sale de la red y del importe, así que lo que tarda una factura de Paymos en confirmarse es cosa de la cadena; el canal solo decide dónde se pasa ese rato.

Una conversación aguanta mejor esa espera que una pestaña. Quien sale del chat no pierde nada: la factura sigue en el hilo, y se vuelve a ella por la lista de chats en lugar de tener que buscar el enlace otra vez.

¿Hace falta una cuenta de Paymos para pagar?

No. Nadie necesita una cuenta de Paymos para pagar una factura por Telegram, y el recorrido tampoco le crea una por detrás. Quien abre el enlace es cliente durante el tiempo que dura un pago.

En el lado del cobro de Paymos ocurre lo mismo: no se pide correo electrónico ni se somete a quien paga a una verificación de identidad para completar la operación. La cuenta de Paymos es del comercio, y quien paga se queda en pagar.

En el canal de Telegram esto pesa más que en una web. Una venta hablada suele ser una decisión corta, y un registro en mitad de ella es una segunda decisión que el cliente no venía a tomar, además con la billetera ya abierta esperando.

Al comercio le queda entonces un cliente sin ficha en Paymos. A quien vuelve se le reconoce por los registros del propio comercio, no por un perfil que hubiera tenido que abrirse para pagar la primera vez.

¿A dónde vuelve quien acaba de pagar?

Las URL de retorno de un proyecto de bot de Telegram son enlaces de Telegram, si es que están puestas. A quien llegó por una conversación se le devuelve a Telegram en lugar de sacarlo de la aplicación donde acaba de pagar.

El tipo de destino está fijado; cuál sea ese destino, no. El enlace concreto se configura en el proyecto, igual que en cualquier otro canal se configuran ahí las direcciones de éxito y de error.

Para un negocio que vende dentro de Telegram, eso cierra el círculo. El cliente vino de un chat, pagó en un chat y volvió a otro, y en ningún momento de la venta se abrió un navegador.

Lo que leen los sistemas del comercio sigue siendo el webhook, y no la llegada de nadie a Telegram. Los eventos de factura de Paymos, firmados con HMAC-SHA256, avisan de un cambio de estado; una URL de retorno solo cuenta que una persona fue a algún sitio.

¿En qué se diferencia de mandar un enlace al chat?

Pegar un enlace de cobro en Telegram es distribución. El canal de Telegram es el sitio donde ocurre el pago, y las dos cosas se confunden porque en ambos casos una factura de Paymos llega como un enlace dentro de un chat.

El enlace a una página alojada viaja por donde sea: correo, SMS, un hilo de soporte, un mensaje de Telegram, un PDF de factura. Cuando el cliente lo toca se abre la página de pago en el navegador, porque a eso apunta la payment_url en cualquier otro canal.

El de un proyecto de bot de Telegram abre el bot. El mensaje que lo lleva puede ser idéntico, del mismo remitente y en la misma ventana, y aun así lo que viene después del toque pertenece a otra parte del producto.

La prueba está en lo que ocurre tras el toque, no en el aspecto del mensaje. Si se abre un navegador, la factura salió de otro canal; si el pago continúa en la conversación, el proyecto está en el canal de Telegram.

¿Qué no cambia en el canal de Telegram?

El canal de Telegram decide dónde se presenta un cobro, no cómo se procesa. Debajo del bot funciona la misma maquinaria que en cualquier otro canal, y conviene nombrarla, porque «sin página alojada» suena a bastante más de lo que quita.

Una factura de Paymos es el mismo objeto en todos los canales. Lleva importe, caducidad y estado; un pago de más se abona entero, y la tolerancia a pagos de menos sigue siendo la que fijó el proyecto. El bot no altera nada de ese recorrido.

El dinero también se comporta igual detrás del bot. El saldo de Paymos se abona en el activo que envió quien paga y se lleva por activo, no por red; el cobro sale por el 1,0 % del precio Estándar que figura en la lista de precios.

Y lo mismo vale para todo lo que toca quien programa. El contrato del webhook es la misma entrega firmada con los mismos nombres de evento, y la profundidad de confirmación se sigue leyendo de la red y del importe, no del canal.

¿Qué canal le conviene a tu proyecto?

La bifurcación está en dónde se encuentra el cliente cuando decide pagar: un proyecto de bot de Telegram encaja con un escaparate que es una conversación, y quien está en una página o delante del mostrador no está en ninguna. La página de pago en Telegram cuenta dónde encaja la versión de chat.

Cuatro preguntas lo resuelven, y ninguna necesita una factura de Paymos.

1. ¿Dónde está el cliente cuando decide pagar: en un chat, en un canal o en tu propia web?
2. ¿Necesita la venta una página con tu logotipo y tus colores? Esa página es la de pago alojada, y un proyecto de bot de Telegram no la tiene.
3. ¿Qué proyecto tuyo lleva ese tráfico? El canal cuelga del proyecto, así que la respuesta es un proyecto, no una campaña.
4. ¿Qué lee el resultado? El mismo endpoint de webhook de siempre.

Contestadas con honestidad, el canal de Telegram deja de parecer una página de pago recortada. Es un ajuste del proyecto que traslada el cobro a la aplicación donde el cliente ya estaba, y el camino que recorre un pago en cripto no cambia por debajo.