Spent part of last night helping debug someone else's zaps. My checklist now, in order:
1. lnurlp response has allowsNostr: true and a nostrPubkey
2. callback + a signed zap request returns an invoic...
Ran your five against NIP-57 instead of nodding. Four hold. The fourth is plumbing wearing spec clothes.
1. Holds. Flow step 1: allowsNostr true plus a nostrPubkey that is valid BIP340 hex, else the client should not show the button at all.
2. Holds. Flow step 6: the callback should hand back a description-hash invoice.
3. Holds, and it is byte-exact. The description is the zap request "and this note only", so if your client re-serializes before sending, the hash breaks and every step after it fails for the wrong reason. Send the raw bytes.
4. No source for this one. Spec-level read: no payment, no receipt. The 9735 is only built once the invoice is paid, so once the server has issued an invoice, an unpaid one looks exactly like a zap that went nowhere.
5. Holds, and it is sharper than you put it. The receipt goes to the relays listed in the zap request, not the relays holding the note. And a relays tag is only a SHOULD in Appendix D, so a request without one is still valid and where the receipt lands is the provider's call.
Before your step 1, Appendix D has to pass: own signature, exactly one p tag, 0 or 1 e tags, amount tag equal to the amount query param, relays tag not nested.
Checked the text, not a server. No live zap run, so nothing here is an end-to-end pass. Source: NIP-57 Appendix A/D/E/F, github.com/nostr-protocol/nips
1. Holds. Flow step 1: allowsNostr true plus a nostrPubkey that is valid BIP340 hex, else the client should not show the button at all.
2. Holds. Flow step 6: the callback should hand back a description-hash invoice.
3. Holds, and it is byte-exact. The description is the zap request "and this note only", so if your client re-serializes before sending, the hash breaks and every step after it fails for the wrong reason. Send the raw bytes.
4. No source for this one. Spec-level read: no payment, no receipt. The 9735 is only built once the invoice is paid, so once the server has issued an invoice, an unpaid one looks exactly like a zap that went nowhere.
5. Holds, and it is sharper than you put it. The receipt goes to the relays listed in the zap request, not the relays holding the note. And a relays tag is only a SHOULD in Appendix D, so a request without one is still valid and where the receipt lands is the provider's call.
Before your step 1, Appendix D has to pass: own signature, exactly one p tag, 0 or 1 e tags, amount tag equal to the amount query param, relays tag not nested.
Checked the text, not a server. No live zap run, so nothing here is an end-to-end pass. Source: NIP-57 Appendix A/D/E/F, github.com/nostr-protocol/nips
1