Payment Receipt (Kind 5522)

While Kind 5521 handles traditional "Zaps" (payments with an associated Zap Request and comment/metadata), there are scenarios where a payment happens without any prior Nostr interaction.

A Kind 5522 (Payment Receipt) is generated when a direct Lightning payment is made to a Zapf-managed LNURL or Lightning Address without an accompanying Kind 5520 Zap Request attached to the transaction.

The Problem Solved

If Alice scans Bob's Zapf LNURL QR code with a legacy Lightning wallet (like Phoenix or Wallet of Satoshi) that doesn't understand Nostr, the wallet simply requests an invoice and pays it.

The IA receives the funds, but because there is no Zap Request, it cannot generate a compliant Kind 5521 Receipt (because Kind 5521 legally requires a description tag containing the sender's signed request).

To ensure the recipient's dashboard still reflects the payment, the IA generates a Kind 5522.

Event Structure

{
  "kind": 5522,
  "content": "Payment received without accompanying Zap Request.",
  "tags": [
    ["p", "<recipient_pubkey_or_server_pubkey>"],
    ["bolt11", "lnbc10u1..."],
    ["preimage", "<32_byte_hex_string>"],
    ["amount", "1000000"],
    ["r", "<lidp_identifier_hash>", "<lidp_name>"] 
  ],
  "pubkey": "<provider_pubkey>",
  "created_at": 1709424010,
  "id": "...",
  "sig": "..."
}

Key Differences from Kind 5521

1. No description tag: There is no Zap Request to embed.
2. No P tag: The sender's identity is completely unknown to the network.
3. Explicit amount tag: Because there is no requested amount in a description to reference, the settled amount is explicitly defined as a tag (["amount", "<millisats>"]).
4. Utilization of content: The content field is often used by the IA to provide human-readable context (e.g., "Direct Lightning Payment") since the sender could not provide a custom comment.

Like Kind 5521, Kind 5522 events fully support the custodial r tag for routing funds to unregistered legacy identities.