fixedfloat marked my LN payout as sent and nothing arrived

Swap completed on fixedfloat about ninety minutes ago. Order shows Done, payout marked sent over Lightning. Nothing my side. No pending HTLC, no failed attempt in the log, no invoice marked settled.

Assume every part of this is recorded on their end and on mine. Before I open a ticket and hand them more than they already have: has anyone had an LN payout from them go missing this week, or is this mine to fix?

It's yours. Their side says sent because a preimage came back. If you have no HTLC in your log your node never saw the offer — inbound liquidity, or a channel that went to sleep. Not them.

A preimage coming back means the payment settled somewhere. If it settled and I did not receive it, I want to know where it went before I file that under my problem.

FWIW the thing that separates the two cases:

lncli listinvoices --max_invoices=20 | grep -A3 settled
lncli listpayments | tail -40

If the invoice isn't in there at all, the payout never reached your node and their retry expired. If it's there and settled, check whether you have a second wallet on the same seed — I've watched someone burn two days on this and the sats were on a phone in his other pocket.

IME with LN payouts from swap services the failure is nearly always inbound liquidity on a channel nobody has rebalanced in a month.

or take it on chain and stop debugging a payment rail to save ninety seconds

Preimage doesn't mean settled to you, it means settled. A route can die on a hop that already claimed. You're arguing with how the protocol works, not with the service.

I am arguing with a service that reports Done when it does not know that it is done. Those are two different claims and I am conceding neither.

Ticket is open. Not expecting much.

Why 'sent' and 'received' are separate claims on Lightning

Worth unpacking properly, because this comes round every few weeks and the thread always ends with two people talking past each other.

A swap service marks a payout sent when its node gets a preimage back. That is a real cryptographic fact: somebody on the route revealed the secret that unlocks the payment. What it does not establish is that the final hop delivered to the invoice you think it delivered to. In practice, the overwhelming majority of the time, it did. But 'the sender saw a preimage' and 'the recipient has the sats' are different statements, and a sender can only ever honestly make the first one.

The four things it actually is, in the order I would check

1. No inbound liquidity. Your channels are full on your side, the payment could not be routed to you at all, and nothing settled. If this is it, the service has a failed attempt in their log — that is the thing to ask for.
2. A second wallet on the same seed. More common than anyone admits. A seed restored onto a phone months ago, forgotten, quietly answering invoices.
3. An expired invoice. If you generated it well before the swap completed, some services retry, some silently drop, and a few mark the order done anyway because the retry logic and the status field are not the same piece of code.
4. A genuinely stuck HTLC. Rare. Resolves when the channel force-closes or the timeout expires, and it shows in your pending channel state rather than in your invoice list.

What to put in the ticket

Ask for the payment hash and the failure reason from their node's log. Not the order ID — the payment hash. A service that cannot produce one either is not logging properly or is not going to help you, and both are useful to establish in the first reply rather than the ninth day.

I have not tested this against a service that flatly refuses to hand over payment hashes, so I do not know what the second move is if they say no.

Summary: a preimage proves settlement happened, not that it happened to you. Get the payment hash, check your own invoice list first, and assume inbound liquidity before you assume malice.

bookmarking this, half of it is over my head but the checklist is gold!

The ticket will be answered in nine days by someone called Anna.