How to send USDC on Solana, from mint check to receipt

Confirm which USDC you are sending

USDC exists on several blockchains. Before using a deposit route or wallet, match both the asset and network. A service that accepts USDC on one chain may have separate instructions for Solana.

Circle publishes the mainnet Solana mint as EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v. Compare the complete mint in the wallet or explorer with that publication. A token bearing the same ticker can have a different issuer or bridging arrangement.

The mint is the asset identifier. Your recipient gives you receiving details for their holding, usually a wallet address that compatible software resolves to a token account or a service-specific deposit address. Sending to the mint itself does not deliver a personal payment to the intended person.

Use mainnet for the actual mainnet asset. A devnet token is useful for software exercises but has separate account state. Keep test transfers and production payment records clearly identified by cluster.

Understand where the USDC will arrive

USDC quantity is recorded in a token account referring to the USDC mint. That account also identifies the authority that can manage the holding under the token program's rules.

A wallet often uses an associated token account, or ATA, as the predictable default for a wallet authority, mint and token program. The sending application can find an existing ATA or include its creation when supported. The owner can also have other token accounts.

This explains why a first transfer can need more setup than a later one. The token quantity goes into the holding account, while someone funds the required account balance and processing fee in SOL. Funding account creation does not make the payer the token owner.

Follow a receiving service's exact instructions. Some provide specialised deposit arrangements. Deriving your own destination from a guessed convention can bypass the service's intended crediting path.

Separate the USDC amount from SOL costs

Suppose Alice has 80 USDC and wants Bob to receive 25 USDC. For a standard transfer of this issuance, a successful operation debits 25 USDC from the source holding and credits 25 USDC to the intended destination holding.

A fee payer separately pays the network fee in SOL. If a receiving token account must be created, its required funding is another SOL movement. These costs should not be silently described as USDC sent to Bob.

The wallet may arrange sponsorship or package setup and transfer in one transaction. Read who pays and what the complete transaction requests. If it reports insufficient SOL, determine whether it is missing the network fee, account funding or both.

For builders, token quantities use integer base units. Six decimal places mean 25 whole units is represented by 25,000,000 raw units. Preserve the mint's actual precision when constructing or parsing the transfer; the balance guide covers integer handling.

Send 25 USDC from 80 USDC

Prepare and approve the payment

Open Send in the wallet, select the correct USDC asset and enter the destination and amount. When paying an invoice, compare those values with the invoice's network-specific instructions.

Review the final approval screen for the source account, destination, mint, quantity and SOL expenses. If account creation is included, understand which account will be created and who controls it. A combined setup-and-payment transaction can be normal when it matches that purpose.

Approve the transaction, then save its signature. A payment app may also provide an order ID or reference. Keep that business identifier alongside the network signature; they identify different records.

If the send response times out, check the original attempt before trying again. Rebuilding a transfer can create another transaction and a second payment even when both carry the same invoice reference.

Verify the token receipt and any service credit

Open the signature in an explorer for the intended cluster. Check execution success, then locate the transfer and token-account changes. Use the mint to establish asset identity and compare the credited quantity with the intended amount.

For our example, Alice's USDC holding should decrease from 80 to 55, and Bob's relevant holding should increase by 25, assuming no other token movements in the transaction. SOL fees and setup funding belong in their own part of the record.

A receiving wallet can discover and display the token after the onchain update. If its asset list lags, inspect the holding account before assuming the transfer failed. A service can take a separate step to credit a customer balance after recognising the receipt.

If a service has not credited a successful transfer, provide the signature, mint, quantity and deposit instructions to its support channel. A second transfer cannot allocate the first one correctly. For an actual execution error, use the transaction's error and logs to identify the failing instruction.

Check all holding accounts when the wallet total looks wrong

A receiving authority can control more than one token account for the same USDC mint. The familiar associated token account is a default address, not proof that every holding sits there. An application or earlier workflow can leave another valid holding account under the same authority.

Use an illustrative recipient with 10 USDC in account A and five in account B. A 25-USDC transfer credits B, leaving A at 10 and B at 30. The combined holding is 40. A wallet view that reads only A can appear unchanged even though the payment succeeded.

Inspect the destination token account named by the accepted transfer, its mint and its stored owner. Then enumerate the relevant owner's token accounts and sum integer raw amounts before formatting. Keep accounts controlled by a lending program or another position separate from freely controlled wallet holdings; an identical displayed asset does not make the authorities the same.

If the target was a custodial service, use that service's deposit instructions and credit record. Finding a token somewhere under a related address does not establish that the service assigned it to your customer account. Preserve the signature and exact destination when requesting support.

This check helps locate an existing receipt. Moving the tokens again merely to make an interface discover them introduces another transaction and is usually unnecessary for diagnosis. The balance-reading guide explains discovery, aggregation and precision.

Keep a payment record you can reconcile

A useful receipt records the network, USDC mint, intended recipient, amount and signature. For an invoice, add its reference and the merchant's final status. This is enough to investigate whether a transfer, matching step or fulfilment step needs attention.

For repeated business payments, use a deliberate reconciliation process rather than treating a wallet's notification as the accounting system. Merchant reconciliation explains how to validate and match receipts, including extra payments and late arrivals.

The transfer establishes delivery of the token. Exchanging it for another asset or redeeming through an eligible service is another operation, with its own evidence. See payouts and redemption when your intended outcome is bank money.

Common questions