The async-payment user story I'm interested in exploring is a mobile user (not always connected) who wants to receive donations (no PoP) via a static invoice from another mobile user.
My understanding of how this could work:
The static invoice should contain a blinded route to the payment receiver via their LSP and an ephemeral public key that the payment sender will use to encrypt the last hop of a payment onion containing a keysend TLV. The LSP of the payment receiver must support store-and-forward of onion messages.
A payment sender builds a payment onion where the first hop is their LSP that supports trampoline payments, onion messages and async-payments. The first hop of the onion includes a TLV to indicate the payment should be held until triggered (with a async-payment nonce) and gives the blinded route to the payment receiver. The last hop of the onion is encrypted to the payment receiver's ephemeral public key and includes:
- the keysend TLV payment secret
- the amount being sent
- After the payment sender updates their channel for the payment with their LSP, they send an onion message to the payment receiver using the receiver's blinded route. The onion message includes:
- the blinded return route to the payment sender's LSP
- the payment async-payment nonce
The payment sender's LSP (first hop) holds the payment until triggered or timed out.
The payment receiver's LSP (penultimate hop) queues the onion message from the payment sender until the message can be delivered.
When the payment receiver reconnects to their LSP the onion message is delivered and the payment receiver sends a trigger onion message to the payment sender's LSP. This trigger message contains the payment nonce of the held payment.
When the payment sender's LSP receives the trigger onion message it begins trying to forward the payment to the payment receiver via the blinded path given in the trampoline payment.
The payment succeeds if the payment receiver completes the payment, or fails otherwise. The payment receiver receives the payment secret and expected amount in the keysend TLV of the onion they decrypt.
The payment sender must also come online to settle the HTLC with their LSP sometime before it expires or their LSP will be forced to close the channel. The expiry timeout can be arbitrarily long to prevent unnecessary channel closes.
Nice graphic! Helps explain the concept well.