Pagos
Pagos con QR y stablecoins
Qué contiene un QR y cómo solicitar, escanear, revisar y enviar activos compatibles con Lex.

Un QR contiene información
Un código QR representa información que una cámara puede leer. En un pago puede ser un enlace web, una dirección de billetera o una solicitud estructurada con activo, red, destinatario y monto. La imagen no mueve dinero por sí misma. La aplicación interpreta su contenido y te pide autorizar una operación.
Una solicitud estructurada evita copiar direcciones largas y escribir manualmente el monto. Estándares como ERC-681 describen cómo codificar esos datos para transacciones compatibles con Ethereum. Que funcione todavía depende de la aplicación receptora: reconocer la imagen y entender el pago son capacidades distintas.
En el uso cotidiano, lo importante es lo que te pide enviar la pantalla de revisión. Lee token, cantidad, red y destino después de escanear. Un logotipo bien diseñado o una imagen QR familiar no confirman la identidad de quien recibe ni la compatibilidad del pago.
Un QR Pix no es un QR de stablecoins
Los códigos bancarios y las solicitudes blockchain pertenecen a sistemas distintos. Un QR Pix brasileño puede contener datos bancarios, mientras que una solicitud compatible de billetera Lex describe una transferencia de activos en Base. No asumas que tu saldo de stablecoins puede pagar cualquier QR de una tienda solo porque el teléfono logra escanearlo.
Lo mismo ocurre con códigos bancarios de otros países. Un comercio puede querer moneda local en su cuenta y no tener cómo recibir tu token. Pregunta qué método acepta. Si hace falta una ruta bancaria compatible, utiliza esa ruta con sus propias instrucciones; no la sustituyas por un envío de billetera no relacionado.
Una dirección de billetera sola también aporta menos información que una solicitud completa. Quizá no indique la red o el token deseados. Confirma esos datos con el destinatario por un canal conocido. Los formatos parecidos entre redes pueden confundir, y enviar exitosamente por la red equivocada puede no generar saldo utilizable en su aplicación.
Crear una solicitud en Lex
En Transferencias, elige Recibir, selecciona el activo compatible e introduce el monto. Continúa con Solicitar y selecciona transferencia de billetera. Lex muestra un QR y controles para compartir. Revisa cantidad y activo antes de enviarlo; si introdujiste un valor mediante una estimación de moneda, comprueba la cantidad real de tokens que se pedirá pagar.
En activos distintos del dólar, el valor aproximado en dólares puede variar con el mercado mientras la cantidad solicitada permanece fija. Esa diferencia ayuda si quieres recibir una cantidad concreta. Si buscas cobrar un valor fijo en otra moneda, acuerda cotización y momento con quien paga, en vez de asumir que la solicitud se ajusta continuamente.
Compartir una solicitud no demuestra que alguien pagó. Enviarla a varias personas tampoco divide automáticamente la cuenta ni evita duplicados. Aclara a cada persona cuánto le corresponde. Después, confirma la transacción entrante en tu billetera y conserva el registro si necesitas conciliar un gasto compartido.
Escanear y revisar un pago
Dentro del envío, usa el escáner o abre un enlace de pago compatible. Lex puede aplicar los datos admitidos a la transferencia. Comprueba destino, activo y monto después de aplicarlos, especialmente si antes de escanear ya habías escrito otra cantidad o seleccionado otro activo.
Una solicitud es algo que debes revisar, no un motivo para aprobar a ciegas. Confirma que conoces al destinatario y esperabas hacer ese pago. Si aparece una red o activo no compatible, o una solicitud inválida, pide otra compatible. No adivines un token parecido ni elimines campos desconocidos manualmente solo para que avance.
Revisa cualquier costo de transacción mostrado y verifica que tienes saldo suficiente. La transferencia puede liquidarse rápido, pero la aplicación receptora todavía puede tardar en mostrarla. Después de autorizar, consulta el estado antes de repetir. Si se pierde la conexión, la primera instrucción podría haberse enviado ya.
Dividir un gasto entre amigos con USDC
Supón que tres amigos acuerdan dividir un gasto de US$75 usando USDC, con una aportación de 25 USDC cada uno para este ejemplo. Quien pagó crea la solicitud en Lex y la comparte con los otros dos. Cada uno comprueba que indique 25 USDC en Base y que el destino sea la billetera de su amigo.
El ejemplo es un acuerdo entre amigos, no una garantía de que siempre se puedan comprar o rescatar 25 USDC por exactamente US$25 sin costos. Fondeo, acceso al rescate, precio de mercado y comisiones son cuestiones separadas. Si alguien parte de euros o pesos, primero revisa cuánto cuesta obtener y enviar la cantidad requerida.
Quien recibe confirma dos entradas antes de dar el gasto por liquidado. Si alguien envía dos veces por error, verifican los registros antes de acordar una devolución separada. El QR ayudó a comunicar datos; no funciona como un sistema de contracargos de tarjeta ni administra automáticamente las cuentas del grupo.
Qué pasa cuando llega el token
Recibir una stablecoin te entrega el activo en su red compatible. No se convierte automáticamente en un abono bancario ni garantiza que lo acepte una tienda. Si necesitas dinero para gastos locales, consulta la conversión y el retiro bancario disponibles antes de aceptar recibir el token.
Para un familiar en México, Brasil o Argentina, un retiro bancario compatible puede resultar más sencillo que recibir en una billetera. Si prefiere billetera, confirma activo y red exactos y considera el costo de retirar después. Compara el resultado utilizable final, no únicamente la cantidad codificada en el QR.
Distingue solicitud y comprobante. La primera dice qué pidió alguien; el segundo registra lo que sucedió. El proceso de Lex puede reducir la captura de datos y mostrar claramente el activo, mientras la revisión final permite detectar errores de destinatario, cantidad o red. Hazla cada vez, incluso con contactos conocidos.
Si vas a usar la solicitud en otro dispositivo o compartirla fuera de Lex, verifica que la aplicación del pagador reconozca todos los datos. No basta con que abra una pantalla de envío: debe mostrar la operación que ambos acordaron. Ante una diferencia, vuelve a generar o confirmar la solicitud antes de pagar.