Separate your BRL purchase from the crypto transfer

Imagine a Recife user buys USDT with BRL on an exchange, then wants to fund a card account. The exchange purchase and the later blockchain withdrawal are separate operations. A completed BRL payment to the exchange does not prove that the card provider has received any stablecoins or made a spending balance available.

Likewise, a Pix key is not an on-chain receiving address. KAST’s current fee schedule lists Pix deposits and withdrawals, but use only a flow actually enabled in your account. If you choose a crypto deposit instead, follow its asset and network instructions rather than pasting bank-payment information into an exchange withdrawal field.

• Keep the BRL purchase receipt separately.
• Use the receiving app’s current asset and network.
• Wait for spendable balance before checkout.

Check minimums after the exchange fee

Open the destination’s Deposit or Receive screen, choose USDT or USDC and copy its address for the selected supported network. Confirm whether a memo or tag is required. A cheaper withdrawal option is useful only if the receiving app supports that exact asset-network pair; address appearance alone does not validate compatibility.

RedotPay requires its deposit minimum to be met after network fees. Choose a modest test that clears that threshold, rather than an arbitrarily tiny amount. In a hypothetical R$300 funding budget, include the BRL-to-crypto purchase cost and exchange withdrawal cost before deciding how much should reach the card account.

Retain both halves of the funding trail

Save the exchange order receipt and the separate blockchain transaction hash, network, asset and destination address. Compare the actual credited quantity with the sending record. KAST’s support list separates receiving and sending networks, so a successful deposit also does not establish that you can later withdraw over the same network.

If funds are missing, contact the provider responsible for the stalled step with the relevant reference. Do not send another transfer as a repair attempt. An unsupported network can make recovery uncertain, and a card-freeze action does not reverse an already broadcast blockchain payment; keep those support requests distinct.