Ideating on this a bit since it's becoming a common request... wanted to run this possible extension by you...

CLINK debits does seem like the obvious place for balance info, but there's a catch...

CLINK debit connections don't necessarily have a balance of their own since debit requests can be either manually approved or have rolling auto-approved budgets that can reset based on time.

We could expose the remaining CLINK Debit budget as something like available_sats, either as added payload with each successful payment response, to a poll, or both.

Two edgecases with that for you:

• If a user has it set to manual approval, available_sats would show 0, and SN would have to try anyway expecting the user approves the request manually.
  • Potential mitigation here is instead of showing 0 we flag it as either manual or exhausted
• If a user has it set to auto approve, but blows their budget, the last availabe_sats you see in a success response may be out of date.
  • Mitigation would be to re-poll for available_sats if the amount is lesser than the forthcoming request.
    • Users using SN on multiple devices could throw this amount off too, so might need a re-poll anyway unless the available_sats state is cached to cross clients by SN's service level storage

Beyond that, a non-CLINK way, would be the SN Client just using the full ShockWallet RPC and becoming another interface for Lightning.Pub. That could get a little heavy on your end given it's nsec based keyring, but does open an interesting design surface.