Media

Bitcoin Lightning Publisher

Bitcoin Lightning Publisher belongs in the long-form publishing shelf because it lets a WordPress site charge tiny Lightning payments for content. Read it as publisher infrastructure: useful, specific, and worth checking carefully before it touches reader payments.

Media Publishing layer Articles, music, video, live events, reads, clips and media storage.

Media Articles Videos

Media27 min readWordPress plugin for Lightning paywalls, donations, Value-for-Value publishing and NWC-capable wallet connections

Bitcoin Lightning Publisher

The quick readBitcoin Lightning Publisher is not a Nostr social client, not a relay, and not a general wallet app. It is a WordPress plugin by getAlby for Lightning paywalls, donation widgets, Value-for-Value blocks, podcast:value RSS tags, Lightning meta tags, and REST endpoints that create and verify invoices. The plugin is listed by getAlby/awesome-nwc under Long-form Content Publishing because version 1.4.0 added support for NWC wallets, allowing a publisher to receive payments through any wallet path that supports Nostr Wallet Connect. The current WordPress and GitHub state checked on June 13, 2026 shows stable version 1.4.2, WordPress 5.6+ and PHP 7.4+ requirements, GPL-3.0 project licensing, around 90 to 100 active installations, and a security-relevant v1.4.2 fix for CVE-2024-12100, a reflected XSS issue affecting versions up to 1.4.1. Before using it on a live publication, verify the plugin version, WordPress compatibility warning, theme and block-editor behavior, wallet backend, NWC permissions, LNURL endpoint, caching rules, paywall bypass behavior, backups, and how refunds or reader support will be handled.

A WordPress payment layer

Bitcoin Lightning Publisher is a WordPress plugin before it is anything else. It installs into a normal WordPress site and gives the publisher paywalls, donation blocks, Value-for-Value widgets and Lightning invoice flows. The official WordPress page and the GitHub README describe the same core purpose: monetize digital content with instant Lightning microtransactions and receive payments directly to a preferred wallet.

That sounds simple, but the simplicity is attached to a specific environment. You are not installing a Nostr client. You are adding a payment layer to WordPress posts, pages, downloads, podcasts, videos or custom publication flows. The reader interacts with a paywall button, a donation block or a Lightning-enabled page. WordPress still owns the content, user experience, caching layer, theme output and plugin lifecycle.

The plugin comes from the getAlby ecosystem, which matters because Alby has been one of the main bridges between web publishing, browser Lightning payments and Nostr Wallet Connect. The repository is public under the getAlby GitHub organization, the WordPress plugin profile lists getalby as the author, and the Alby creator guide still points publishers to this tool for WordPress monetization.

For a Crays reader, the right framing is this: Bitcoin Lightning Publisher is publisher infrastructure. It helps a writer, podcaster, newsletter operator or media site test small Bitcoin payments without building a checkout from scratch. Its Nostr connection is real, but it arrives through NWC wallet support and the broader zap/value ecosystem, not through Nostr posts, relays or identity by itself.

Why it appears in the NWC map

The reason Bitcoin Lightning Publisher belongs in the Nostr Apps Hub is precise. getAlby/awesome-nwc lists it under Long-form Content Publishing and describes it as a WordPress plugin for donations and paywalls. That list is not saying the plugin publishes Nostr events or runs a relay. It is saying the project participates in the NWC payment ecosystem around apps and wallets.

The plugin changelog is the stronger evidence. Version 1.4.0 added support for NWC wallets, with the note that NWC lets a publisher receive payments to any wallet that supports NWC and that older connection options might eventually be deprecated in favor of NWC. That turns the plugin from a set of legacy backend connectors into a WordPress publishing surface that can connect to newer wallet services through Nostr Wallet Connect.

NWC itself is a protocol for communicating with a Lightning wallet through Nostr relays. NIP-47 describes a wallet service, an app, encrypted request and response events, a connection string, and commands such as `pay_invoice`, `make_invoice`, `get_balance`, `lookup_invoice`, `list_transactions` and `get_info`. In this case, WordPress and the plugin are the app side of the publisher flow; the wallet service is somewhere else.

That distinction keeps the article honest. A publisher should not read NWC support as a guarantee that WordPress becomes decentralized, censorship-resistant or Nostr-native. The content remains on the website. The paywall and donation UI remain WordPress features. NWC changes the wallet connection path: it can let the site request invoices or settle payments through an NWC-capable wallet service without handing WordPress broad custody over the whole wallet.

What the plugin actually does

Bitcoin Lightning Publisher gives a site several payment primitives. The paywall can hide part of a post or page until the reader pays. The donation tools can add a Lightning donation button or block. Value-for-Value support can add tags and widgets so readers or podcast apps can send sats without a normal card checkout. The REST API can create and verify invoices for custom integrations.

The paywall is intentionally flexible. The README and WordPress page mention pay-per-post, pay-per-view, pay-per-download, crowdfund mode, time-in mode, time-out mode, price configuration in sats or fiat currencies, shortcode configuration with `[lnpaywall]`, and Gutenberg block support. That is useful because publishers do not all sell the same kind of thing. A long article, a paid file, a podcast episode and a community post need different gates.

The donation side is lighter but important. A site can add donation widgets in Gutenberg or themes, publish a Lightning meta tag, and add `podcast:value` tags in RSS feeds. That makes the plugin more than a hard paywall tool. It can support softer audience-funding patterns where content stays open but the reader, listener or app is invited to send value back.

The REST API is the advanced path. The GitHub README documents endpoints for initiating and verifying paywall payments, exposing an LNURL-pay endpoint, creating a general invoice and verifying an invoice. Those endpoints make the plugin useful for custom WordPress builds, but they also create surfaces that need caching, rate-limiting, nonce, replay and payment-state review before a serious production rollout.

A reader sees a tiny checkout

From the reader side, the promise is simple: the site asks for a small Lightning payment and unlocks content quickly. That is the reason a plugin like this exists. Card payments and subscriptions are often too heavy for a single article, one file, a small tip or a one-off podcast boost. Lightning is interesting because the payment can be small enough to match the moment.

The plugin uses WebLN by default for one-click style payments where a reader has a compatible provider. WebLN is a browser-facing interface that lets Lightning web apps request payments or invoices from a connected wallet. If the reader has a WebLN-capable wallet extension or browser integration, the flow can feel like an approval prompt instead of a full checkout form.

Not every reader has WebLN. That is why QR codes, invoices, LNURL and wallet compatibility matter. A good publication should test the flow with multiple reader setups: desktop browser with a WebLN provider, mobile wallet scanning a QR code, a Lightning Address path if configured, a normal non-Bitcoin reader who needs context, and a reader behind aggressive tracking or script blockers.

The business risk is friction. The plugin can make micropayments possible, but it cannot make a reluctant reader understand Lightning instantly. If a paywall blocks important content with no explanation, the site may lose readers. If donations are framed as optional support, the same tool can feel generous. The publisher has to choose the relationship, not just the invoice amount.

The publisher receives through a wallet path

The plugin's wallet story has changed over time. The README and WordPress metadata list Alby, LND, LNDHub, LNbits, BTCPay Server and Lightning Address among connection options. The current GitHub README marks LND, LNDHub and LNbits as deprecated while keeping Alby, NWC-capable wallets, BTCPay Server and Lightning Address visible. The WordPress readme still presents the older list more broadly.

That difference is worth explaining because it tells you where the project is going. NWC support makes the plugin less dependent on a handful of direct backend adapters. Instead of wiring WordPress directly to every Lightning node or account API, the site can connect to a wallet service designed to expose scoped methods through Nostr Wallet Connect. This can simplify future compatibility if the wallet side is maintained.

A publisher still needs to know which wallet is on the other end. An Alby Account, an Alby Hub, a BTCPay Server setup, a Lightning Address receiver, an LND node, an LNbits account and a provider-backed wallet are different custody and reliability models. Some are self-custodial. Some are custodial. Some depend on channel liquidity. Some depend on a hosted account. Some are mostly receive-only for this use case.

The safe setup notes are practical. Use a wallet connection with the minimum permissions needed. Do not connect a high-balance wallet to an experimental WordPress site. Keep separate wallet paths for production and testing. Record how to rotate the connection. If the plugin uses an NWC secret, treat that connection string as a secret credential even when spending limits are low.

NWC is useful, not magic

Nostr Wallet Connect helps because a wallet service can sit apart from the WordPress site and handle payment requests over encrypted Nostr events. The NWC website describes the protocol as a way to connect Lightning wallets to apps. Alby's developer guide says NWC lets an app communicate with a Lightning node via Nostr and can allow backend or native payments without forcing the user to switch to a wallet for every action.

For Bitcoin Lightning Publisher, the direction is mostly about receiving and verifying payments. The site needs to create invoices, know when they are paid, and unlock content. NWC can help the plugin talk to a wallet service that supports those invoice methods. It does not turn WordPress into a Nostr identity system, and it does not remove the need for WordPress security.

NIP-47 also makes permissions visible. A connection can support different methods, and wallet services can publish info events listing capabilities. That matters because an app that only needs `make_invoice` and invoice lookup should not receive broad spending authority by accident. If the wallet service exposes budgets or method-level controls, use them.

The relay layer needs review too. NWC requests travel through Nostr relays. The content is encrypted, but relay choice can still affect reliability and metadata. If payments drive a production paywall, relay downtime can look like a broken checkout. Use a wallet service and relay setup you can monitor, and test what the WordPress site shows when the wallet path is unavailable.

The WordPress reality

WordPress is powerful because it is ordinary. Themes, blocks, shortcodes, membership plugins, page builders, caching plugins, security plugins and CDNs all meet in the same site. Bitcoin Lightning Publisher lives inside that ecosystem. Its usefulness depends not only on the plugin code, but also on the surrounding WordPress stack.

The WordPress plugin page currently shows version 1.4.2, PHP 7.4 or higher, WordPress 5.6 or higher, tested up to 6.7.5, a four-star rating from four reviews, and around 90 active installations on the public page while the plugin API reports 100 active installations. It also shows a warning that the plugin has not been tested with the latest three major WordPress releases. That warning should not be ignored on a live site.

Open issues reinforce the need for testing. The GitHub issue list checked for this article included reports about not being able to change wallet settings, a WordPress textdomain warning, WebLN donate button trouble, a request to use Bitcoin Connect, and older issues around Lightning meta tag behavior and paywall nesting. Some may be environment-specific, but they are exactly the kinds of problems that show up when payment UI meets a real WordPress stack.

Before enabling a paywall on important content, clone the site or use staging. Test the plugin with the active theme, Gutenberg blocks, classic editor if used, page builder if used, membership plugin if used, CDN, object cache, full-page cache, security headers, minification and mobile layout. A Lightning payment that succeeds but does not unlock content is still a broken reader experience.

Paywalls need product judgment

Bitcoin Lightning Publisher gives you mechanisms, not a business model. A publisher can put a single paragraph behind a paywall, require a few sats for a full article, ask for a voluntary boost, unlock a download, crowdfund a post until a target is met, or use time-based rules. The plugin can support those patterns, but it cannot decide which one respects the reader.

Micropayments work best when the reader understands the exchange. If a post costs 21 sats, say what happens after payment. Does the browser unlock that post only once? Is the unlock tied to a cookie, a token, a logged-in account, a Lightning preimage, or something else? What happens if the reader changes devices? What happens if the payment succeeds but the browser closes before the unlock call returns?

A crowdfund mode needs different wording. In that case, each reader may be contributing to a public or implicit unlock threshold. That can feel exciting for community content, but it can also confuse readers if the target, current amount or unlock rule is unclear. A time-in or time-out paywall has similar communication needs because the paid boundary changes over time.

The best use cases are narrow at first. Use the plugin for a bonus essay, a file download, a donation block, a podcast boost path or a small experiment with loyal readers. Watch support requests. Watch failed payments. Watch mobile behavior. Expand only after the payment and unlock story is boring.

Value-for-Value is the softer path

The plugin's Value-for-Value features are important because not every publication wants a hard wall. A writer may prefer to keep posts open and invite readers to send sats when the work helped them. A podcaster may want boostagrams from compatible podcast apps. A small research site may want a donation widget rather than an account system.

Podcasting 2.0's `podcast:value` tag is part of that context. The Podcast Namespace documentation describes the value tag as a way to designate the cryptocurrency or payment layer, the transport method and a suggested amount, with one or more value recipients. Bitcoin Lightning Publisher can add this sort of value signal to RSS feeds for podcast-related publishing.

The Lightning meta tag is another lightweight signal. Instead of forcing every reader through a visible checkout, the site can advertise a Lightning recipient path that compatible tools can discover. That fits the open-web spirit better than a popup-only donation model, but it still requires a working wallet endpoint and a clear recipient identity.

For Nostr users, this softer path overlaps with zaps culturally even when it is not literally a Nostr zap. The idea is the same: value moves from audience to creator with less ceremony. The protocol details differ. A Nostr zap has NIP-57 semantics and public event context. A WordPress Value-for-Value payment through this plugin is a website payment unless another layer adds Nostr event meaning.

Security history matters

The most important security fact is CVE-2024-12100. NVD and Wordfence describe Bitcoin Lightning Publisher versions up to and including 1.4.1 as vulnerable to reflected cross-site scripting because `add_query_arg` was used without appropriate URL escaping. Wordfence lists the issue as CVSS 6.1 medium severity and says the patched version is 1.4.2.

The GitHub release for v1.4.2, published on December 22, 2024, is short but direct: it fixes a small vulnerability discovered by the researcher. The WordPress readme upgrade notice says version 1.4.2 fixes escaping for transaction filter URLs. That is exactly the kind of detail a production publisher should check before installing an old ZIP from a tutorial or old server backup.

A reflected XSS issue is not automatically catastrophic in every site configuration, but it is serious enough for a payment plugin. A successful script injection can affect admin sessions, reader trust, checkout pages or wallet configuration surfaces depending on context. If the site is using the plugin, anything older than 1.4.2 should be treated as unpatched.

The practical advice is simple. Install only the current version from WordPress.org or the GitHub release you can verify. Check the version in the WordPress dashboard after upload. Keep WordPress core, the active theme and other plugins current. Do not expose the WordPress admin to the public internet without strong authentication habits. Test security plugins and content-security-policy choices against the payment UI before assuming everything is protected.

Caching can break payment truth

WordPress performance plugins are a hidden risk for paywalls. A static cache can serve the wrong version of a page. A CDN can cache a locked or unlocked view. JavaScript minification can break WebLN calls. Aggressive page optimization can move scripts in ways the plugin did not expect. Object caching can keep stale payment state longer than a reader expects.

Payment truth has to be dynamic. The site needs to know whether a particular payment was made, whether the token or preimage is valid, whether the reader should see the full content, and whether the unlock should persist. If that decision is cached at the page level, one reader's state can leak into another reader's experience or a paying reader can remain locked out.

The plugin exposes REST endpoints for paywall payment initiation and verification. Those routes should not be cached like ordinary posts. If a CDN sits in front of WordPress, add explicit rules for the plugin's REST namespace and any checkout or unlock endpoints. If the site uses a security plugin that blocks anonymous REST calls, test the flow carefully because the README marks some endpoints as not requiring authentication.

A staging test should include cache on and cache off. Pay for an article, reload, open in a private window, switch devices, wait for cache expiry, try a failed payment, try a duplicate callback if possible, and check logs. A paywall that only works in a logged-in admin browser is not production ready.

Customization is possible but sharp

The GitHub README documents customization paths for publishers who need a different unpaid button or custom paywall logic. A developer can copy a template into the theme or use a filter to override the unpaid paywall button template. The plugin also offers a filter or global function approach for deciding whether a post should show full content.

That is useful for membership sites, newsletters, course sites or publications where some users should bypass the paywall. For example, subscribers might see the full article while anonymous visitors see the Lightning paywall. The plugin's hook design gives developers a way to integrate that logic without editing the plugin core.

It is also an easy place to introduce bugs. A custom function that always returns the wrong value can unlock everything or lock everyone out. A theme override can be lost if a developer edits plugin files directly. A page builder can wrap shortcodes in unexpected markup. A membership plugin can conflict with the payment token model.

If you customize, document the rule in plain language: who sees full content, who must pay, where the state is stored, how long access lasts, and what support should do when a reader reports a payment problem. Then test that rule with logged-out users, subscribers, editors, admins, mobile browsers and cached pages.

The REST API deserves review

The README lists REST endpoints under `/lnp-alby/v1/`. The paywall path can initiate a payment for a post and verify it with a token and preimage. The LNURL-pay path exposes payment metadata and a callback. The invoice path can create a general invoice and verify it. This is useful for custom WordPress flows that go beyond a normal block or shortcode.

An open REST endpoint is not automatically unsafe, but it must be understood. The plugin says some endpoints require no authentication because anonymous readers need to pay. That means the endpoint design relies on payment tokens, invoice verification, nonce-like behavior, preimages, post IDs and rate limits rather than a logged-in WordPress user.

A production site should inspect server logs after launch. Are bots hitting invoice endpoints? Are failed verifications common? Are payment callbacks returning quickly? Does the endpoint expose enough error detail to debug without leaking secrets? Does the site use HTTPs everywhere? Are reverse proxy headers correct so callbacks and LNURL metadata show the intended public URL?

Developers should also review how payment state is stored. The bootstrap file defines a JWT key derived from WordPress `AUTH_KEY`, and the plugin has database code for transactions. That makes WordPress secret rotation and database backups relevant to paywall behavior. If you migrate the site, make sure the payment state and WordPress salts are handled deliberately.

Wallet and custody checks

Before a site takes real payments, decide where the sats land. An Alby account, an Alby Hub, BTCPay Server, a Lightning Address service, LND, LNbits and an NWC wallet service can all feel like a Lightning destination from the plugin's point of view. They are not the same operationally.

Ask custody questions in ordinary language. Who can spend the funds? Who holds keys or node access? Can the publisher withdraw? What happens if the wallet provider changes terms? What happens if the home server is offline? Are channels balanced enough to receive? Is the Lightning Address path custodial, self-hosted or forwarded?

For NWC, inspect the connection scope. Does the wallet service permit only invoice creation and lookup, or can the site also pay invoices? Is there a budget? Is the key unique to this WordPress site? Can it be revoked without changing other app connections? Which relay is used, and can you monitor it?

Keep balances low until the whole flow has survived updates and support requests. A WordPress paywall is not a treasury system. It should be connected to a receiving workflow that the publisher checks regularly, sweeps if needed, and can rebuild from backups.

Reader support is part of the product

Lightning payments are fast, but support still exists. A reader can pay the wrong invoice, close the tab, lose a token, use an incompatible wallet, hit a route failure, overpay or underpay depending on the flow, or find that the page remains locked after settlement. The plugin can verify payments, but the publication needs a human policy.

Write the support path before launch. Tell readers whether payments are refundable, whether access is device-specific, how to contact support, what information to send, and whether the site can manually unlock content. Do not ask readers to send private wallet secrets or screenshots that expose sensitive information.

Small payments reduce the sting, but they do not remove trust. If a reader pays even 100 sats and receives nothing, the site has broken a promise. If enough people hit that experience, the experiment will look like a gimmick rather than a better publishing model.

The best support signal is boring reliability. Use a visible test page. Keep amounts low. Monitor failed verification logs. Watch WordPress reviews, GitHub issues and release notes. Update the public wording when the payment flow changes. A Lightning paywall is still a reader relationship.

How to test before launch

Start on staging with the same theme and plugin stack as production. Install Bitcoin Lightning Publisher 1.4.2 or newer, connect a low-value wallet path, create a test post, add a paywall block or shortcode, add a donation block, and confirm that the WordPress admin can save settings without console errors.

Test reader flows next. Use desktop with a WebLN provider, mobile with a Lightning wallet, a browser with no Lightning tooling, a private window, a slow network, a failed payment, a repeated payment attempt, a refresh after payment, and a second device. Check the full-page cache and CDN configuration while doing this, not after.

Test backend behavior. Watch server logs, WordPress debug logs, wallet logs, NWC wallet-service logs if available, and relay status. Confirm that REST endpoints are not cached. Confirm the public site URL in LNURL metadata. Confirm that an expired or already-used token cannot unlock the wrong content. Confirm that deleting or revoking the wallet connection fails gracefully.

Only then move to production with tiny amounts. Keep the first paid content low-risk. Make a backup before and after plugin setup. Note the exact plugin version, wallet backend, NWC permissions, relay, theme override files and cache exclusions. Future maintenance becomes much easier when the launch state is written down.

When it is a good fit

Bitcoin Lightning Publisher is a good fit when a WordPress site already has readers who understand Bitcoin or are willing to try small Lightning payments. It is also sensible for a creator who wants a donation button, a V4V experiment, a paid file, a paid post or a podcast boost path without moving the whole site to a Nostr-native publishing platform.

It is especially interesting for publishers who want to keep WordPress as the editorial system. WordPress still has mature themes, editors, SEO tooling, author workflows, media libraries and hosting options. The plugin adds a Lightning layer to that existing surface instead of asking the publication to rebuild around a new protocol.

It is less suitable when the site needs a polished commercial subscription system, tax invoicing, refunds, credit-card fallback, account dashboards, enterprise support or guaranteed compatibility with every WordPress release. The install base is small, the plugin has open issues, and the WordPress page shows a compatibility warning. That does not make it unusable, but it does make careful testing mandatory.

It is also not the right answer if the goal is Nostr-native publishing. For that, look at tools such as Habla, Highlighter, YakiHonne or other long-form Nostr clients. Bitcoin Lightning Publisher can monetize a WordPress site with Lightning; it does not make the article itself a Nostr event.

The reader takeaway

Bitcoin Lightning Publisher is a small but meaningful bridge between the old web and the Lightning/Nostr payment world. It lets a WordPress publisher ask for sats at the point where a reader is already reading, listening or downloading. That is a more concrete promise than generic creator-economy language.

The project is strongest when used honestly: a WordPress plugin for Lightning paywalls, donations, V4V tags and wallet-connected publishing. NWC support gives it a modern wallet path and earns its place in the Nostr app map, but the operational work remains WordPress work: updates, themes, caching, security, backups and reader support.

Use it with small amounts first. Verify version 1.4.2 or newer. Test the wallet connection and NWC permissions. Exclude payment endpoints from caches. Confirm mobile and WebLN behavior. Keep a support path for failed unlocks. If those checks pass, the plugin can give a publication a practical way to experiment with direct reader value instead of treating Lightning monetization as an abstract idea.

Sources worth opening

Start with the WordPress plugin page, the GitHub README, the Alby creator guide, the release notes, the NVD and Wordfence vulnerability entries, and the NIP-47/NWC docs. Then read the WebLN, podcast:value, LNURL and WordPress block/customization references before adding it to a production publication.