QR payments with stablecoins

A QR is a container for information

A structured request reduces the need to copy a long address and type an amount manually. Standards such as ERC-681 describe how Ethereum-compatible transaction requests can encode those details. Support still depends on the receiving wallet application: recognizing the image and understanding the payment are separate abilities.

For everyday use, the important question is what the review screen asks you to send. Read the token, quantity, network, and destination after scanning. A polished logo or a familiar-looking QR shape does not establish the identity of the recipient or the compatibility of the payment.

A Pix QR is not a stablecoin QR

Bank payment codes and blockchain payment requests belong to different systems. A Brazilian Pix QR can contain bank payment information, while a compatible Lex wallet request describes an asset transfer on a blockchain network. You cannot assume that a stablecoin balance will pay any QR displayed by a shop simply because your phone can scan it.

The same distinction applies to a bank QR in another country. A merchant may want local money in a bank account and have no way to receive your token. Ask which method they accept. If a supported bank route is needed, use that route with its own instructions; do not replace it with an unrelated wallet transfer.

A plain wallet address is also less specific than a complete request. It may not tell you the intended network or token. Confirm those details with the recipient through a trusted channel. Similar address formats across networks can be misleading, and a successful send on the wrong network may not produce usable funds in the recipient’s app.

Creating a request in Lex

In Transfers, choose Receive, select the supported asset, and enter the amount. Continue with Request and choose the wallet-transfer option. Lex displays a QR and sharing controls for the request. Review the quantity and asset before sharing; if you entered a value using a currency estimate, check the actual token quantity that the request will ask the payer to send.

For non-dollar assets, an approximate dollar value can move with prices while the requested token quantity remains fixed. If you intend to receive a specific quantity, that distinction is useful. If you intend to collect a fixed value in another currency, agree with the payer on the quote and timing instead of assuming the request continually reprices itself.

A shared request is not proof that anyone paid, and sharing it with several people does not automatically divide the bill or prevent duplicate payments. Tell each payer what their portion is. Afterward, confirm the incoming transaction in your wallet and retain the record if you need to reconcile a shared expense.

Scanning and reviewing a payment

In the send flow, use the scanner or open a compatible payment link. Lex can apply supported request details to the transfer. Check the displayed destination, asset, and amount after those details are applied, especially if you had already entered a different amount or selected another asset before scanning.

A request is an instruction to review, not a reason to approve blindly. Confirm that you know the recipient and expect to make this payment. If the app reports an unsupported asset, network, or invalid request, ask for a compatible request. Do not guess at a similar-looking token or manually remove unfamiliar fields just to make the payment proceed.

Review any transaction cost shown and make sure you have the required balance. A wallet transfer may settle quickly, but the recipient’s app can still need time to display it. After authorizing, check the transfer status before trying again. If connectivity fails, your first instruction may already have been submitted.

Splitting a USDC expense between friends

Suppose three friends agree to split a US$75 expense using USDC, with each contributing 25 USDC for this illustration. The friend who paid creates the appropriate request in Lex and shares it with the other two. Each payer checks that the request says 25 USDC, checks the network it names, and confirms that the destination is the friend’s wallet.

The example is an agreement between friends, not a guarantee that 25 USDC can always be bought or redeemed for exactly US$25 without costs. Funding, issuer redemption access, market price, and transaction fees are separate questions. If one friend starts with euros or pesos, they first check what it costs to obtain and send the required amount.

The receiving friend confirms two incoming payments before marking the expense settled. If one payer accidentally sends twice, the group verifies the records before arranging a separate return. The QR helped communicate details; it did not function as a card chargeback system or automatically manage the group’s accounting.

What happens after the token arrives?

Receiving a stablecoin gives you the asset on its supported network. With a self-custodial wallet, you authorize its next transfer. It does not automatically turn into a credit at your bank, and it does not guarantee a shop accepts it. If your goal is local spending money, check the available conversion and bank payout route before agreeing to receive the token.

For a family member in Mexico, Brazil, or Argentina, a supported bank payout may be easier than a wallet payment. If they prefer a wallet, confirm the exact asset and network and account for any eventual withdrawal cost. Compare the final usable result, not just the amount encoded in the QR.

Keep payment requests and receipts distinct. The request is what someone asked for; the receipt records what actually happened. Lex’s wallet flow can reduce typing and make the asset explicit, while the final review remains your chance to catch the wrong recipient, quantity, or network. Use that review each time, even for a familiar contact.