A customer paid twice in USDC: what to check, what to send back, and what else lands in Needs attention.

What shows up in the Needs attention queue?

Needs attention is a page in the Fianto merchant dashboard that lists the records that may need you to act, in three tables. The sidebar shows the total beside it, and the Overview shows a strip such as "2 things need you" with a Review button whenever the total is above zero. Each row opens its record, and See all opens the full filtered list.

The page's own one-line summaries are worth reading as written. For an unmatched transfer: "money arrived for an order that was already paid; refund it from your wallet if it was a mistake". For a failed payment: "the payment failed but a transfer reached your wallet; check it before you contact the customer". The counts are not limited to a month or to the range you picked on the Overview. An old case stays until it leaves on its own terms, which are covered further down.

How do you handle a customer who paid twice?

A double payment on Fianto is a second transfer that carries the same checkout's payment reference after the order was already paid. A payment reference is a unique key Fianto puts in each checkout transaction so it can match a transfer to its order. Fianto broadcasts the checkout transaction itself, and it also looks for transfers it did not broadcast by searching for that reference: every 60 seconds while a checkout session is open and for 24 hours after it closes, recording up to 20 such transfers per session, according to its docs as of 15 October 2026.

Here is what you see when it happens on, say, a 25.00 USDC order at Brisklow:

• The order page opens with a notice that starts "Paid twice." It says a second transfer of the order's amount reached your wallet after the order was paid, and that Fianto never holds money, so a mistaken payment goes back from your wallet to the customer.
• In the Orders list the order carries an "Unmatched" tag, and the Needs attention table counts its "Extra transfers".
• Your webhook endpoint receives order.duplicate_payment, with a duplicate object naming the second transfer's signature and amount. The order's status stays PAID, and order.paid does not fire again.

Then work through it in this order:

1. Open the second transfer on an explorer such as Solscan from its signature, and confirm the amount, the sending wallet and that it reached your receiving wallet.
2. Ask the customer whether it was a mistake. A customer may have paid again on purpose, for a second seat or a gift, and a second order is the cleaner record for that.
3. If it was a mistake, send the same amount of USDC back from your receiving wallet to the wallet the transfer came from. Never send it to an address the customer types into a chat without checking it against the sending wallet.
4. Write down the refund's own transaction signature next to the order ID, in whatever ledger you keep.

The full refund walk-through, with what to do about any fee the customer paid on top and a policy to adapt, is in how to refund a USDC payment. A refund is an ordinary Solana transfer that your wallet signs, so your wallet pays its Solana fee in SOL like any transfer you send: the base fee is 5,000 lamports per signature, per Solana's fee documentation on 15 October 2026. Fianto takes no part in the refund and charges nothing for it.

Why does a failed payment still put money in your wallet?

A payment marked Failed on Fianto means Fianto did not accept it as the order's payment, not that no USDC moved. Two cases cause it. The transfer finalized but did not match what the payment asked for, such as the wrong amount or fee. Or the checkout session behind it had been superseded, by a newer session for the same order or by changed order terms, so the payment is recorded Failed even though its money landed.

The payment page says so in plain words: "This payment failed, but a transfer reached your wallet. Check it on Solscan before you contact the customer." On the Payments list, the "Money moved" chip shows every such payment. When a wrong-amount transfer fails and no other payment for the order is still under way, the checkout session expires at once, the order turns Expired, and your server gets order.expired with checkout.session.expired. Do not read either event as "the customer kept their money".

What should you tell a customer whose payment failed?

Never tell a customer "nothing was taken" until you have opened the failed payment and checked whether a transfer reached your wallet. If it did, you have two honest options, and the customer should pick:

1. Refund the USDC from your wallet to the wallet it came from, and let them pay again if they still want the product.
2. Or keep it and deliver by hand, by agreement. The order still reads Expired in Fianto, so note in your own records why you fulfilled it.

If they pay again on an order your own integration created, have your server create a new checkout session for the same order_id: an Expired order goes back to Pending and can be paid normally, one of the cases idempotency keys and order ids sets out. An Expired order can also still turn Paid on its own if a late payment for it finalizes, so check the order once more before you refund. Fianto does not quietly treat a mismatched transfer as payment, and that is the right default: a wrong amount is a question for you to settle with the customer.

What does a past-due subscription in the queue mean?

A past-due subscription is one whose renewal failed for a reason the customer can fix, and nothing was taken from their wallet. The table shows each one's customer, product, "Last failure", "Next try" and the amount due. The last failure reads as one of four phrases:

Fianto tries a renewal four times in all: at the period boundary, then about one hour, six hours and a day after it. The first counted failure makes the subscription Past due and sends subscription.past_due. The fourth ends it with the reason "Four charges failed", and that period is never billed later. A successful retry makes it Active again and takes it off the list. The schedule is explained step by step in failed renewals and retries, and the customer-side causes in why a USDC subscription didn't renew.

Your job here is the one Fianto does not do. Fianto sends customers no renewal reminders and no past-due emails, so a short message from you before the last try is the customer's only nudge. Do not refund anything on a past-due row. There is nothing to refund.

Why is the order still listed after you refunded it?

Orders with an unmatched transfer and failed payments where money moved stay in Needs attention after you refund, because Fianto cannot see a transfer you send from your own wallet. A past-due subscription leaves on its own, when a charge succeeds or the subscription ends.

So keep a short refund log: the order or payment ID, the amount, the refund's transaction signature and the date. Put it next to the payments CSV export when you close a month; accounting for USDC revenue covers what else to record. There is no "mark as resolved" button today, so the log is how you tell an open case from a settled one.

These rows are not disputes. A USDC payment on Solana cannot be pulled back by the customer or their bank, which is the trade explained in chargebacks vs crypto refunds. Every refund in this queue happens because you decided to send it.

Which webhooks match the Needs attention tables?

Each table has a webhook you can act on in code, so a support ticket can open before anyone looks at the dashboard. A webhook route on Node, Workers or Bun is built in accepting USDC with Hono. The events per table:

Delivery is at least once, so dedupe on the event ID. Events, payloads and retries are documented in the webhook event reference, and the dashboard side in the docs page on Needs attention.