Lightning Enable

• Name: Lightning Enable
• URL: https://lightningenable.com/
• Category: Lightning commerce orchestration middleware / L402 wrapper / provider-routed agent-payments glue
• Tags: bitcoin-ecosystem
• Summary: Lightning Enable is BYOA Lightning commerce middleware. It sits between the app and a provider like Strike or OpenNode, normalizes L402 or MPP-facing flows, and packages producer plus MCP tooling around that connection. Useful operator glue, not a new rail.
• What it does:
  • Connects platforms and APIs to Strike or OpenNode through a BYOA model so Lightning payments can be accepted without the customer running its own Lightning payment operations
  • Positions itself as middleware that forwards requests to the payment provider while the provider handles custody, settlement, and compliance
  • Supports both L402 and Machine Payments Protocol (MPP) flows for pay-per-request API monetization and machine-facing authentication
  • Ships an open-source MCP server with 23 tools spanning wallet actions, L402 API access, producer flows, and Agent Service Agreement tools for agent-to-agent commerce on Nostr
  • Offers platform integrations such as Shopify Commerce and Kentico Commerce in addition to the core API and dashboard surface
  • Uses subscription pricing rather than per-transaction fees, while the connected provider may still charge its own processing fees
• Key claims:
  • The official site says Lightning Enable is “the infrastructure layer that turns payment into authentication,” which is the clearest clue that this is orchestration and access middleware rather than custody or settlement infrastructure
  • The docs explicitly call it a commerce orchestration layer and repeatedly stress that Lightning Enable never holds funds while the chosen provider keeps payment processing, custody, and compliance
  • The product overview says the model is BYOA: customers bring their own Strike or OpenNode API key and funds flow directly to that account, which keeps the note grounded in provider-routed middleware rather than merchant-of-record rhetoric
  • The same materials say all plans include REST API access, L402 support, MCP compatibility, and producer features, so the product is trying to package both buyer- and seller-side machine-commerce workflows rather than only a checkout plugin
  • The open-source MCP repository documents support for Strike, LND, and Nostr Wallet Connect wallets such as CoinOS and Alby Hub, which shows Lightning Enable is packaging wallet and provider routing above the underlying paid-request rails rather than defining a new one
  • The official site and docs both emphasize flat subscription pricing with no per-transaction fee from Lightning Enable itself, reinforcing that the business model is middleware and product access, not payment take rate
• Whitepaper: No canonical standalone Lightning Enable whitepaper or litepaper surfaced in this pass. The clearest current source of truth was the official site, the product/docs portal, and the open-source Lightning Enable MCP repository; see ../whitepapers/lightning-enable-primary-sources-2026-05-03.md.
• Sources:
  • https://lightningenable.com/
  • https://docs.lightningenable.com/
  • https://docs.lightningenable.com/products/product-overview
  • https://github.com/refined-element/lightning-enable-mcp
  • https://raw.githubusercontent.com/refined-element/lightning-enable-mcp/main/README.md

Internal linkages

• Keep this note on l402 and lightning-agent-tools.

Control surface

• The leverage sits in provider choice, BYOA account dependence, which paid-request flow gets exposed, how producer endpoints are wired, and whether the MCP layer is just wallet access or a broader agent-commerce wrapper.

• That matters, but Lightning Enable still lives above the actual payment provider and above the underlying Lightning request-auth rail.

• Keep the note centered on orchestration and packaging, not on grand agent commerce rhetoric.

• Last reviewed: 2026-06-14 UTC