“I already have USDC” does not always mean “I can pay this Solana request.” The balance may be on Base, Polygon or another network. It may be inside an exchange account rather than available to the wallet used at checkout. Or the merchant's receiving account may not be ready.
At a busy counter, discovering this after scanning holds up both the customer and the queue. Put the useful information in the booking message, invoice or counter notice before the customer starts paying.
AI-generated concept illustration, not a wallet screenshot. The separated islands represent network-specific balances, not a bridge service or an automatic transfer.
First check which network holds the USDC
Open the asset details in the wallet or the balance's network information in the provider's interface. Check the full asset identifier against Circle's official USDC address list. A token name or dollar symbol alone does not establish the network or authenticity.
USDC on Base is not a spendable Solana balance simply because both assets are called USDC. Likewise, copying a Solana address into an unrelated network's transfer form does not turn that transfer into a Solana payment.
The Solana receiving-account guide supplies the official Solana mint and explains how it differs from the merchant's wallet address. Use the mint to verify the asset, never as the customer payment destination.
Diagnose the obstacle before asking for another payment
| What the customer sees | What to check | Practical next step |
|---|---|---|
| USDC balance, but not on Solana | The network holding the funds | Use another network already enabled and prepared on this merchant link, or arrange funding separately before checkout |
| Balance appears only at an exchange | Whether the payment flow can use that balance | Prepare a compatible wallet outside the queue; a withdrawal is a separate operation |
| Wallet does not open or cannot continue | The wallet flow offered by the payment page | Follow the supported connection flow; do not assume every wallet or exchange scanner works |
| Wallet reports an insufficient balance or fee issue | The requested USDC amount and the specific operation's fee requirements | Resolve the displayed requirement before retrying; do not assume all flows have identical gas handling |
| Receiving account is not ready | The merchant's configured Solana wallet and its USDC ATA | The merchant fixes receiving setup; repeated customer approvals do not initialize it |
| Payment was submitted, but completion is unclear | The existing payment reference and current record | Verify that operation before collecting again |
Does the customer need SOL as well as USDC?
Solana operations have network fees, but the fee payer depends on the operation and application. A separate wallet transfer, receiving-account initialization and the checkout's supported authorization flow should not be treated as interchangeable instructions.
The current PayIn Solana checkout uses the configured facilitator as the transaction's network fee payer. The buyer authorizes the USDC transfer; they are not configured as that transaction's network fee payer. This reduces a preparation step compared with asking a customer to make a separate ordinary wallet transfer. It does not fund the customer's USDC balance or cover receiving-account initialization, exchange withdrawals or unrelated wallet operations.
Read the wallet's actual request and any fee message for that operation. Do not tell every customer to buy a fixed amount of SOL, and do not promise that every operation is gas-free. Solana's token-account creation documentation describes the storage balance and transaction fee involved in account creation; it does not establish who sponsors a particular merchant checkout.
For PayIn specifically, the receiving USDC ATA must already exist. Checkout does not silently initialize it for the merchant. Prepare this before serving customers.
What if the customer's USDC is on Base?
If the merchant has also enabled Base with a prepared receiving setup on the same link, the customer can choose that supported network and review the resulting request. Use the Base receiving guide for merchant preparation.
If Solana is the only available choice, the customer needs a separate supported funding process before attempting that payment. PayIn does not automatically bridge USDC, swap another asset or convert a card balance inside checkout. External transfers or conversions may introduce costs, minimums and waiting; resolve them outside the checkout queue rather than promising immediate completion.
Do not send funds manually to an address as a substitute for the web payment flow and assume it will trigger PayIn's payment record or POS sound. An off-flow transfer requires separate verification.
Give customers a useful message before they arrive
For a merchant whose link is configured only for Solana, a short notice can say:
We accept USDC on Solana through our payment link. Please have the correct network balance in a compatible wallet before checkout. Scan our payment request, review the title and amount, and wait for staff to confirm the completed payment.
Adapt the notice to the networks actually enabled on your link. Do not print “all crypto accepted,” “any wallet” or a fixed completion time unless the actual setup supports the statement.
An invoice can carry the public payment link directly. At the counter, show the POS display toward customers and activate its sound. Keep private management and POS links out of the customer notice.
Separate readiness from payment confirmation
Correct funds and a compatible wallet make a payment possible; they do not prove it happened. Staff should match the new completed record and amount to the current sale. If the buyer has already submitted a payment, preserve its reference and verify the existing operation before asking for another attempt.
For the merchant-side sequence from scanning through handover, use the Solana counter walkthrough. For copying the setup address, use find your Solana receiving address.