How to protect a virtual card: details, balance, history, and controls

A virtual card is useful precisely because it can be used at a merchant checkout. That also means the card number, CVV, PIN, payment-verification codes, and settings link deserve the same care as any other payment credential.

On uSwap, the card’s protected view is the place to manage that boundary. It keeps the current card details, available balance, transaction history, and controls together on the original card bridge instead of exposing them on a public transaction page.

Open Virtual Cards → View the currently available card routes

Start with the original card bridge

The first completed funding operation on a card bridge can issue a card. Later completed funding operations on that same bridge can reload it. Keep access to that original bridge: it is the route back to the card’s protected view.

That distinction matters because a funding operation and a merchant charge are separate events. The bridge can show both the state of funding and the card information needed to understand an actual purchase. If you are investigating something, start there rather than relying on an old quote, a wallet send amount, or a browser autofill record.

Do not share the original bridge or a card-settings link casually. Someone who can access an authorized settings view or an unlocked browser session may be able to see information that is intentionally hidden from the public bridge page.

Keep sensitive details inside the protected view

Use the card number, expiry, CVV, PIN, or payment-verification details only in the merchant checkout you intend to use. Those details are credentials, not support references.

In practical terms:

• do not paste card numbers, CVVs, PINs, verification codes, or approval links into a support message, social post, or chat;
• do not leave an authorized card view open on a shared computer or browser profile;
• verify the merchant checkout before entering card details; and
• avoid saving credentials in a place other people can access.

The interface can conceal sensitive values by default and when access or browser focus changes. That is a useful exposure reduction, not a substitute for securing the device and browser session where you opened the card.

Check the available balance, not the amount you sent

The crypto amount sent to a card route is not necessarily the card’s spendable balance. A live route can include the intended card value alongside applicable creation, top-up, routing, provider, conversion, or network costs. The card becomes usable only after its funding operation has completed and the card view reflects the current state.

Before a purchase, check the available balance in the protected card view. This is especially important after a recent funding operation: source confirmation, any route conversion, settled credit, and the card operation are different stages. A transaction that appears on-chain is not, by itself, proof that the balance is ready for a merchant checkout.

For the quote side of the flow, read virtual-card funding fees and settlement. For the first funding and reload sequence, read how to create and reload a virtual card.

Use card history to separate two kinds of activity

When something looks unfamiliar, card history is more useful than guessing from a wallet transaction. It can help separate:

What you are checking	Where to start	Why it matters
A recent reload	The original bridge and its funding state	A deposit can still be confirming, converting, or waiting for provider review.
A merchant purchase	The card’s transaction history	It is the record closest to the card payment rather than the crypto funding event.
A balance question	The available balance in the protected card view	The live card balance is more relevant than an older quoted value.
A verification prompt	The protected card view	Complete only a prompt that corresponds to the card and merchant transaction you initiated.

History gives you context, but it does not replace the merchant’s own records. A merchant, card network, provider, or issuer can apply its own rules to a payment, refund, or verification step.

Use freeze and unfreeze deliberately

The protected card view provides freeze and unfreeze controls. If you need to change whether the card can accept transactions, submit the appropriate control request there and wait for its state to finish before taking the next step.

Avoid rapidly toggling a control while a previous request is pending. One pending change can prevent another from being submitted at the same time, and repeated changes make it harder to understand the card’s actual state.

Freezing is not a promise that an already-authorized merchant transaction will be reversed, refunded, or stopped. It is a forward-looking card control. If there is a merchant charge you do not recognize, preserve the non-secret reference, inspect the card history, and follow the applicable merchant, provider, or issuer process rather than assuming a control change settles the issue.

Treat verification prompts as transaction-specific

Some purchases can require an additional payment-verification step. The card view can surface an active prompt when the provider makes one available. Match it to the merchant and transaction you initiated before proceeding.

Never provide a verification code, CVV, PIN, or approval link to an unsolicited message, caller, or form. If the prompt is not shown in the card’s protected view or does not match the checkout you started, stop and verify the situation before sharing anything.

Ask for help without sharing credentials

If the card view does not explain the issue, contact uSwap support with the minimum non-secret bridge, intent, or transaction reference needed to locate it. Explain whether the question concerns funding, the card balance, a merchant payment, or a card-control request. That makes it possible to investigate the right route without turning a support channel into a repository for payment credentials.

The Privacy Policy explains the card-related information that may be processed for a selected route. The Terms explain the roles of the third-party provider, issuer, payment network, and merchant. Those parties can each have rules that uSwap does not control.

If the concern is a declined checkout rather than card security, use the step-by-step virtual-card payment-declined guide before retrying the same transaction.