Summary
A live SOL invoice is shown as PAID in the invoice UI, while the associated payment API reports status confirmed even though there is no on-chain transaction.
Observed state
- Invoice API: status = paid
- Payment API: status = confirmed
- Payment confirmations = 0
- tx_hash = null
- forward_tx_hash = null
- Solana mainnet getSignaturesForAddress returns an empty result for both the derived payment address and the configured merchant wallet
- Both addresses have a zero balance
- The browser wallet shows no transactions and a zero balance
The affected invoice is INV-002, created on 2026-08-24. I can provide the invoice/payment UUIDs privately to a maintainer; wallet addresses are intentionally omitted from this public report.
Expected behavior
An invoice/payment should not reach PAID/confirmed unless a real incoming transaction has reached the required confirmation threshold. After forwarding, the forward transaction hash or a durable forwarding failure/retry state should be recorded and visible.
Impact
This creates a false-positive settlement state: a merchant can deliver work and record revenue even though no SOL was received on-chain.
Suggested checks
- Verify the code path that transitions a payment to confirmed when confirmations is zero.
- Require a non-null incoming transaction hash before invoice settlement.
- Persist forward transaction hash and forwarding error/retry state.
- Add a regression test for a SOL invoice where no transaction exists at the derived address.
Summary
A live SOL invoice is shown as PAID in the invoice UI, while the associated payment API reports status confirmed even though there is no on-chain transaction.
Observed state
The affected invoice is INV-002, created on 2026-08-24. I can provide the invoice/payment UUIDs privately to a maintainer; wallet addresses are intentionally omitted from this public report.
Expected behavior
An invoice/payment should not reach PAID/confirmed unless a real incoming transaction has reached the required confirmation threshold. After forwarding, the forward transaction hash or a durable forwarding failure/retry state should be recorded and visible.
Impact
This creates a false-positive settlement state: a merchant can deliver work and record revenue even though no SOL was received on-chain.
Suggested checks