Seed Hypermedia enables permissionless payments through cryptographically signed metadata. Your identity key signs payment information that anyone can verify, enabling trustless financial interactions without intermediaries.

Unlike traditional platforms that handle payments centrally, SHM takes a different approach: your cryptographic identity signs payment metadata, and anyone who trusts your identity can verify that payment information is authentic.

This means you don't need platform permission to accept payments. You embed payment details in your signed profile, and the protocol guarantees they haven't been tampered with.

Here's how a typical payment works in SHM:

1. Author embeds payment info in their account profile metadata (Lightning address, LNURL, etc.)

2. The metadata is cryptographically signed by the author's Ed25519 key

3. A reader discovers the content and wants to pay

4. The reader's client verifies the signature, confirming the payment address belongs to the author

5. Payment is sent directly — no platform intermediary takes a cut

Important: The built-in Lightning payment feature in the core protocol is currently unmaintained. The original implementation supported creating Lightning invoices and managing wallets directly through the protocol.

However, the underlying architecture is more powerful than any single payment implementation. Because SHM uses cryptographic identity and signed metadata, payment information can be embedded and verified without any specific payment feature in the protocol itself.

Lightning is the most natural fit for SHM payments. It's instant, low-fee, and doesn't require identity verification — matching SHM's philosophy of permissionless access.

You can embed several types of Lightning payment info:

• Lightning Address — A human-readable address like you@getalby.com that resolves to invoices automatically. This is the simplest option for receiving tips and donations.

• LNURL-pay — A protocol that generates fresh invoices on demand. More flexible than static addresses, supporting variable amounts and attached messages.

• BOLT11 Invoices — One-time payment requests for specific amounts. Useful for selling specific content or services at fixed prices.

Since SHM metadata is flexible, you're not limited to Lightning. You can embed:

• Bitcoin on-chain addresses for larger payments

• Payment links to services like Stripe, PayPal, or Buy Me a Coffee

• Custom payment endpoints for programmatic commerce

The key advantage: whatever payment method you choose, it's signed by your cryptographic identity. Recipients can verify the payment address is authentic, not injected by a man-in-the-middle.

If you don't already have one, set up a Lightning-compatible wallet. Popular options include:

• Alby — Browser extension and custodial wallet with Lightning Address support. Great for getting started quickly.

• Phoenix — Non-custodial mobile wallet. You hold your own keys, and it handles channel management automatically.

• Zeus — Advanced self-custodial wallet that can connect to your own Lightning node.

Add your Lightning address or payment endpoint to your account profile metadata:

# Using the gRPC API to set payment metadata
grpcurl -plaintext -d '{
  "account": "YOUR_ACCOUNT_ID",
  "key": ["payment", "lightning_address"],
  "value": "you@getalby.com"
}' localhost:55002 \
  com.seed.documents.v3alpha.Accounts/SetAttribute

You can also set multiple payment methods:

# Add LNURL endpoint
grpcurl -plaintext -d '{
  "account": "YOUR_ACCOUNT_ID",
  "key": ["payment", "lnurl"],
  "value": "lnurl1dp68gurn8ghj7..."
}' localhost:55002 \
  com.seed.documents.v3alpha.Accounts/SetAttribute

# Add a donation page link
grpcurl -plaintext -d '{
  "account": "YOUR_ACCOUNT_ID",
  "key": ["payment", "donate_url"],
  "value": "https://buymeacoffee.com/yourname"
}' localhost:55002 \
  com.seed.documents.v3alpha.Accounts/SetAttribute

After setting your payment metadata, push your updated profile to the network so others can see it:

# Push your account info to the production gateway
ion-hm push hm://YOUR_ACCOUNT_ID --recursive

Traditional platforms create a trust problem with payments. When you see a "Donate" button on a website, you're trusting:

1. The platform hasn't modified the payment address

2. No CDN or proxy has injected a different address

3. The DNS hasn't been hijacked to serve a phishing page

With SHM, payment metadata is signed by the author's Ed25519 key. A client can mathematically verify that the Lightning address you see was actually set by the account owner. No trust in infrastructure required.

Authors can accept tips or payments for their published documents. Because the payment info lives in the same cryptographic identity as the content, readers know exactly who they're paying.

AI agents with SHM identities can embed payment endpoints in their profiles, enabling machine-to-machine payments. An agent could charge for API access, content generation, or other services — all verified through the same cryptographic identity it uses for publishing.

Projects with multiple contributors can use SHM's access control to manage payment splits. Each contributor's signed profile contains their payment info, and the project document can reference all contributors transparently.

Platform payments (Patreon, Substack, Medium) typically take 5-15% of revenue and require identity verification. SHM payments are direct — zero platform fees, no KYC requirements, and the author retains full control.

The trade-off: platform payments offer dispute resolution, refund mechanisms, and familiar UX. SHM payments are more sovereign but require the recipient to handle their own payment infrastructure.

The built-in Lightning invoice system in the core protocol is unmaintained. Don't rely on it for production use.

Lightning Network itself has UX challenges: channel liquidity, routing failures, and wallet complexity can frustrate newcomers.

There's no standardized payment discovery mechanism yet. Clients need to know where to look in profile metadata for payment info, and there's no universal convention.

Despite these limitations, the foundation is solid: cryptographic identity + signed metadata = verifiable payment info. As the ecosystem matures, better payment UX will be built on this foundation.

• Identity Guide — How SHM cryptographic identity works

• Signing — Cryptographic signatures in SHM

• Security Model — Threat model and security architecture

• Metadata Format — Deep dive into SHM metadata and attributes