On this page
- The customer's receipt appears at Solana's confirmed stage; your dashboard marks the payment Succeeded, and sends order.paid, only at finalized.
- Ask for the transaction signature: the Payments search finds a payment by its whole signature, and Solscan shows what moved.
- Refunds, duplicate payments and "money moved" failures are yours to settle from your own wallet. Fianto never holds the funds.
Why does a USDC payment not show up for the merchant yet?
A USDC payment usually "does not show up" because it is confirmed but not yet finalized: the customer's page already says it worked, while your dashboard still waits for Solana to make it final. Two questions start here.
1. "I paid, but you say you haven't received it."
The checkout shows the receipt, "Payment received", as soon as Solana confirms the transaction. Solana's RPC documentation defines confirmed as "A block directly voted on by a supermajority of stake, meaning more than two-thirds of the network's active stake." Finalized is the strongest confirmation state the network uses. Fianto marks the payment Succeeded and the order Paid, and sends order., only at finalized. So for a short while the customer holds a receipt and your Payments list shows the payment as Confirmed. Solana's Alpenglow upgrade, scheduled to activate on 21 October 2026, is set to bring the two stages together. Why the two stages exist is in confirmed vs finalized for Solana payments, and how long each takes next to a card payment in how long a USDC payment takes to settle.
Where to look: ask for the transaction signature, which is on their receipt as a Solscan link. Paste the whole signature into the search on Payments. If nothing matches, search by their wallet address or the email they typed; the search needs at least 2 characters.
2. "The page said my payment did not complete. Did I lose the money?"
The customer saw this message, with your business name where <merchant> stands: "This payment did not complete. Check your wallet's recent activity first: if the USDC left your account, do not pay again, and contact <merchant>. If it did not, press Pay to try again." The checkout never tells them nothing was taken once they have signed, because a failed payment can still have moved USDC.
Where to look: open the payment. A payment marked Failed whose transfer still reached your wallet says "This payment failed, but a transfer reached your wallet." It is listed under the Payments chip "Money moved" and on Needs attention, in "Failed payments where money moved". If the money is there, refund it or send them a new checkout; do not ask them to pay again without checking.
What should a customer do when the checkout refuses their wallet?
A checkout refusal names its own reason, and each reason has one fix. Fianto's checkout accepts any Solana wallet that follows the Wallet Standard and can sign a transaction without sending it, because Fianto broadcasts the signed transaction itself. When a wallet is missing from the list, why a wallet does not show at checkout goes through the causes.
3. "My wallet says Cannot sign here."
The wallet sheet marks such a wallet "Cannot sign here", and if it was picked anyway the page says: "This wallet can only send payments itself, and we need it to sign the payment so that we can send it. Pay with a different Solana wallet." Tell the customer to use another wallet; the sheet names Phantom, Solflare, Backpack and MetaMask among others, and Phantom vs Solflare vs Backpack compares the first three.
4. "It says my wallet does not have USDC, but it does."
Fianto takes USDC on Solana only. "This wallet does not hold any USDC yet" means the wallet has no USDC account on Solana, which is common when the customer holds USDC on Ethereum, Base or an exchange. The checkout warns about the same thing under the token row: "Send only USDC on Solana. Anything else is lost." If the page instead says how much USDC is needed and how much the wallet holds, the balance is short of the price plus fees. What happens to USDC sent on the wrong network is in crypto payment mistakes.
A wallet with too little SOL gets its own message with the amount to add. That case, and why USDC transfers need SOL at all, is in why you need SOL to send USDC.
5. "Can I just send USDC from my exchange?"
No. The checkout shows no address to send to: the customer connects a wallet and signs one prepared transaction, and a subscription page states it outright, "No manual address: a subscription needs a signature, not a transfer." An exchange account cannot sign that. The customer can withdraw USDC to their own Solana wallet first, then pay from there.
Why did the payment link expire, and what if they paid twice?
A checkout page expires because every checkout session has a deadline, and a customer who pays twice is refunded by you, not by Fianto.
6. "The link expired."
The page's heading turns into "This payment request expired" ("This subscription link expired" on a subscription), and on an API checkout the line under it reads "<your order ID> for <amount> USDC is no longer open. Ask <merchant> for a new link; nothing was charged." A session made by your server lasts 30 minutes unless you set expires_, anywhere from 5 minutes to 24 hours; shop and payment-link sessions always last 30 minutes. With a payment link, the customer can simply open your link again: each click starts a fresh checkout. With an API checkout, create a new session for the same order_ and send the new URL.
7. "I think I paid twice."
The checkout tries to stop it, with "A payment for this order is already being processed. Leave this page open while it finishes. Please do not pay twice." If a second transfer lands anyway, the order page in your dashboard says "Paid twice." and how much reached your wallet, the order carries the "Unmatched" tag, and it appears on Needs attention under "Orders with an unmatched transfer". If you have a webhook endpoint, it also gets order.. The extra USDC is in your wallet, so the refund is a transfer you send; the steps are in how to refund a USDC payment.
Where is the receipt, and who can see the payment?
The receipt is the checkout page itself, and the payment is public on Solana. Customers used to card emails ask about both.
8. "Where is my receipt? I got no email."
Fianto sends no receipt email for checkout or payment-link payments. The one exception is a shop purchase: a shop buyer who typed an email gets one when the purchase is paid. The checkout receipt has "Save the receipt", which prints it, and a link to the transaction on Solscan, which stays there for good. If you need emailed receipts, send them from your own system when order. arrives.
9. "Why is my wallet address public?"
Because every Solana transaction is, as privacy on a public blockchain explains. The checkout says so above the button: "Your wallet address and payment are public on Solana." The email field on the checkout is labelled "Email, optional", and the note under it reads "Shared with <merchant> so they can reach you." It stays between the customer, you and Fianto; it is not written on chain. In your dashboard that email is labelled as typed by the payer and not verified.
Why won't a customer's discount code work?
A discount code fails for one of a few fixed reasons, and the checkout deliberately gives the same answer to every wrong code.
10. "The code you gave me does not work."
A wrong, misspelled or unknown code gets "This code is not valid. Check it and try again.", whether or not the code exists, so the answer reveals nothing. Check in Billing, then Coupons, that the code is active and unexpired and has redemptions left. Three other cases have their own words:
| What the customer saw | What it means | What you do |
|---|---|---|
| "This code cannot be used for this purchase." | The discount would take the price below the 0.01 USDC minimum | Use a smaller discount, or a higher price |
| "This wallet has already used this discount code." | The coupon is set to once per wallet | Give them another code, or let them pay full price |
| No code field at all | You have no active, unexpired coupon, or this checkout was already prepared for payment without a code | Create a coupon under Billing, then Coupons |
Codes are 3 to 32 letters, digits or dashes and are stored in capitals, so case does not matter. The value and duration of a coupon are fixed when you create it; its end date and limits stay editable.
Who should a customer contact, the merchant or Fianto?
The customer should contact you, the merchant, about the payment itself, and Fianto only about its checkout page or customer portal. Fianto's own payer help page tells customers the same, and points them to support@fianto.xyz for the checkout page and the portal.
Make sure they can reach you. Set a support email in Settings. The field's hint tells you payers see it on checkout, and the checkout footer then reads "Questions:" followed by your address. Without it, a customer whose payment went wrong has nowhere obvious to write. An address at fianto.xyz is refused, so nobody mistakes your support for Fianto's.
See what your customers see before they pay: the hosted checkout, its fees and its messages.
Tour the hosted checkoutSubscription customers have their own questions, and each has a full answer elsewhere: why a USDC subscription did not renew, how to cancel a crypto subscription and what a wallet needs for a USDC subscription. They manage everything themselves in the customer portal at fianto.xyz/my, after signing in with a message that moves no funds.