NIP-63a: Minimal Payment Gateway Descriptor (kind:10164)

draft

Summary

This NIP introduces a new event kind (10164) that allows content creators to declare payment gateways, pricing models, and subscription rules for accessing paid content.

It complements NIP-63 by:

• Decoupling payment handling from subscriber management
• Supporting multiple payment providers
• Enabling flexible pricing and discounts
• Allowing Nostr clients to display premium content plans
• Used from payment providers to proceed in actual payment and update subscribers list

Each event represents one gateway, but supports multiple methods and plans.

---

Event Kind

kind: 10164

---

Event Structure

{
  "kind": 10164,
  "tags": [
    ["u", "<payment_url>"],

    ["method", "<method_id>", "<label>", "<type>"],
    ["price", "<method_id>", "<plan_id>", "<label>", "<amount>", "<interval>"],
    ["currency", "<method_id>", "<currency_code>"],

    ["discount", "<method_id>", "<plan_id | *>", "<amount>", "<amount-type>"]
  ],
  "content": "",
  // other fields
}

---

Tag Definitions

Payment URL

["u", "<payment_url>"]

• Entry point for the payment flow
• Clients redirect users here after selection

---

Methods

["method", "<method_id>", "<label>", "<type>"]

• Declares a payment method
• method_id is used to group related tags
• label is a human-readable name for display in clients

Supported Method Types (Proposed)

[
  "bitcoin",
  "lightning",
  "ethereum",
  "solana",
  "fiat",
  "paypal",
  "bank_transfer"
]

Examples

["method", "m1", "Bitcoin", "bitcoin"]
["method", "m2", "Credit Card", "stripe"]
["method", "m3", "PayPal", "paypal"]
["method", "m4", "Lightning", "lightning"]

---

Currency

["currency", "<method_id>", "<currency_code>"]

• Defines supported currencies per method

Examples

["currency", "m1", "BTC"]
["currency", "m2", "USD"]
["currency", "m2", "EUR"]

---

Pricing

["price", "<method_id>", "<plan_id>", "<label>", "<amount>", "<interval>"]

• Defines subscription plans for a method
• label is a human-readable name (e.g., “Monthly”, “Pro Plan”, “6 Months”)

Supported Intervals

["life", "weekly", "monthly", "3-months", "6-months", "yearly"]

Examples

["price", "m1", "p1", "Monthly", "0.0002", "monthly"]
["price", "m2", "p1", "Basic", "10", "monthly"]
["price", "m2", "p2", "6 Months", "50", "6-months"]
["price", "m2", "p3", "Yearly", "120", "yearly"]

---

Discounts

["discount", "<method_id | *>", "<plan_id | *>", "<amount>", "<amount-type>"]

• Applies a discount to:
  • A specific method + plan
  • A whole method (plan_id = *)

Amount Types

["percentage", "fixed"]

Examples

["discount", "m1", "*", "10", "percentage"]
["discount", "m2", "p2", "20", "percentage"]

---

Rules

• method_id MUST be defined before being referenced
• plan_id MUST be unique within a method
• currency SHOULD match the method context
• Multiple tags of the same type are allowed

---

Client Behavior

Clients SHOULD:

1. Read all 10164 events from a creator
2. Group data by method_id
3. Build UI:
   • Method (label) → Currency → Plans (label)
4. Apply discounts:
   • Exact match (method + plan)
   • Method-level (plan_id = *)
5. Redirect user to u for payment

---

Example

{
  "kind": 10164,
  "tags": [
    ["u", "https://pay.example"],

    ["method", "m1", "Bitcoin", "bitcoin"],
    ["currency", "m1", "BTC"],
    ["price", "m1", "p1", "Monthly", "0.0002", "monthly"],

    ["method", "m2", "Credit Card", "stripe"],
    ["currency", "m2", "USD"],
    ["currency", "m2", "EUR"],
    ["price", "m2", "p1", "Basic", "10", "monthly"],
    ["price", "m2", "p2", "6 Months", "50", "6-months"],
    ["price", "m2", "p3", "Yearly", "120", "yearly"],

    ["discount", "m1", "*", "10", "percentage"],
    ["discount", "m2", "p2", "20", "percentage"]
  ],
  "content": "",
  // other fields
}

---

Notes

• One event = one gateway
• Fully tag-based (no JSON in content)
• Supports multiple methods and pricing strategies
• Labels improve UX in clients without affecting logic

---

Conclusion

The event provides user-specific payment context for paid content, and it’s for display purposes only on Nostr clients, where for payment gateways, it should be used for actual payment, validating plans and updating subscribers list

It enhances usability by introducing labels for methods and plans, while keeping the model simple, extensible, and fully compatible with Nostr principles.