LNURL small payments seem to be ignored

[akovalenko]

I'm the user of lnvps.cloud, nostr pubkey npub1nv9ut8f... I realize I'm not authenticated here, but the question is generic enough to deserve a generic answer. By the way, your support form on account/support has broken cloudflare captcha and is currently unusable.

I've recently paid small amounts of sats using lnurl-pay 1536@api.lnvps.net, hoping to get a small amount of time expansion for the vps. (100 sat and 300 sats, I'll provide details if you want). I have memories that this has worked earlier, and even let me to buy a throw-away vps for several hours in the past (which the natural flow of payment didn't allow, full month minimal). However, today I do not see either VM expiry expansion or the payments in payment history.

I'm experimenting with an LLM paying to lnvps automatically, and being able to do it in small amounts is critical for debugging the entire flow.

What I'd like to know:

• whether the full-month-only startup and extension payments are your real policy, or it's just a technical glitch
• whether lnurl-pay is still the acceptable way of topping-up the balance
• if the policy and not a glitch, why lnurl-pay does not limit the minimum amount you're ready to accept at the real value? As a participant in the discussion that ended up in lnurl-pay as we know it, and as a first person in the world that has implemented a lnurl-pay server -- I can say that the minimum amount is there exactly for this purpose.

Thank you.

[isolkewo]

I checked this on the backend — the small payments are working correctly.

Here's what I found for the two small test payments you mentioned:

• 100 sats → 34,426 seconds added to VM expiry (~9.5 hours) ✅
• 300 sats → 103,094 seconds added (~28.6 hours) ✅
• VM was started right after the first payment and renewed both times

The backend is processing them fine and extending expiry proportionally. The time extensions for small amounts are small — 100 sats buys less than half a day — so it may not be obvious in the UI that it worked.

That said, I agree the support form Cloudflare captcha is broken and needs fixing. And adding to the LNURL-pay metadata is a good idea to reject amounts below what makes sense for your minimum billing unit.

Re: whether full-month is the real policy — no, pay-as-you-go top-ups via LNURL-pay are working as intended. The minimum is just whatever the smallest useful increment would be (which is effectively set by the rate, not a policy floor).

[akovalenko]

@isolkewo Hello, thank you for the prompt response. We could indeed miss small period extensions, it's the LLM who was comparing before/after expiry, will now re-run the experiment. I'm still worried because all these small extensions leave no traces in https://lnvps.cloud/vm/billing (which I've checked right now and did not see neither 100 nor 300 sats)

[akovalenko]

@isolkewo some news about my problem. Somehow our lnurl payments to 1536@ were routed to vm 1416, which is not mine (Extend VM 1416 is mentioned in my lndhub history). It could be our bug (mine or LLM's) in the payment flow, but it could also be a misrouting on your lnurl server side. Continuing investigation.

[akovalenko]

@isolkewo Investigated further, and there IS a misrouting on your side. One of my payments for 1536@ was manual from my lnbits wallet (no llms involved in the flow), and still reads "Extend VM 1416" in history.

So paying the LNURL-pay renewal link for my VM 1536 credits a different VM, 1416, which is not on my account. VM 1536 receives nothing: its expires never moves and the payment never appears in its ledger.

Account has exactly one VM: GET /api/v1/vm -> [1536].

Root cause — the callback mints an invoice bound to VM 1416, not 1536:

1. LNURL-pay params are correct:
   GET https://api.lnvps.net/.well-known/lnurlp/1536
   -> metadata = [["text/plain","Extend VM 1536"]], callback = .../api/v1/vm/1536/renew-lnurlp
2. But the callback invoice references VM 1416:
   GET /api/v1/vm/1536/renew-lnurlp?amount=100000
   -> decode(bolt11) description = "VM renewal 1416 to 2026-07-04 14:00:19 UTC"
3. The description field encodes the VM id. Proof: my two real paid renew invoices that correctly credited 1536 both decode to "VM renewal 1536 to <expiry>" (2026-06-27 and 2026-07-27). The format is VM renewal <VM-ID> to <resulting-expiry>. Real renew = 1536, LNURL-pay = 1416.
4. VM 1416 is not mine: GET /api/v1/vm/1416 -> {"error":"VM does not belong to you"}.

Impact (observed):

• GET /api/v1/vm/1536 expires = 2026-07-27T21:38:34Z, unchanged to the second before and after the payments.
• GET /api/v1/vm/1536/payments contains only the two paid renew invoices plus one unpaid renew test invoice — no LNURL-pay payment.
• A 300 sat LNURL-pay payment left my wallet (memo VM renewal 1416 to ...) and never reached VM 1536.

Secondary (LUD-06): the LNURL-pay invoice carries a plaintext d description tag instead of description_hash = sha256(metadata), so it also does not comply with LUD-06 — but the headline issue is the wrong VM id.

[akovalenko]

@isolkewo reproduced on another VM order:

• VM 1536 → invoice id 1416 (diff 120)
• VM 1735 → invoice id 1615 (diff 120)

An interesting systematic off-by-120 bug.