LNTPay

• Name: LNTPay
• URL: https://www.lntpay.com/
• Category: hosted Lightning ledger backend / invoice-and-webhook payment middleware / paid-API billing plumbing
• Tags: bitcoin-ecosystem
• Summary: LNTPay is a hosted Lightning backend for paid apps and APIs, not a general checkout stack. It issues BOLT11 charges, keeps the workspace ledger, signs webhook events, and can pay outbound invoices. Useful provider plumbing, not L402 itself or the broadest Lightning commerce stack.
• What it does:
  • Lets developers create BOLT11 payment requests (“charges”) for per-request APIs, paywalls, bots, and other Lightning-native micropayment flows
  • Tracks paid and pending invoice state inside workspace-level ledger balances split into available and locked funds
  • Delivers payment lifecycle events through signed webhooks with retries so an app can unlock content or usage after charge.paid
  • Supports outbound withdrawals by paying external BOLT11 invoices from available workspace balance
  • Separates sandbox and production environments with environment-scoped API keys, bearer auth, and idempotency-key guidance for write operations
  • Provides an SDK and an opinionated quickstart showing how to gate an API response on Lightning settlement
• Key claims:
  • The homepage describes LNTPay as “Lightning-native infrastructure” for pay-per-use, paywalls, and microtransactions with sats, centered on ledger, webhooks, and instant settlement rather than broad merchant checkout
  • The docs explicitly say LNTPay is not a multi-coin checkout, not an e-commerce payment plugin, and not a fiat or stablecoin gateway, which helps narrow the category to Lightning-native micropayment infrastructure
  • The docs define a workspace as the grouping for API keys, charges, webhooks, withdrawals, and the ledger, and define charges as BOLT11 invoices whose paid state credits workspace balance
  • The docs say the ledger distinguishes available balance from locked balance, with locked balance used for reserved flows such as withdrawals
  • The docs say authenticated requests use bearer API keys, write operations should include an idempotency key, and scopes can restrict access such as charges:read or charges:write
  • The pay-per-request quickstart shows a canonical flow where an app creates a charge, waits for a charge.paid webhook, verifies the x-lntpay-signature HMAC-SHA256 signature against the raw request body, and then unlocks the protected API response
  • The quickstart requires charges:write and webhooks:read, which reinforces that the intended operating model is programmatic gating of application actions on payment settlement
  • The public Swagger page is surfaced as the canonical API reference and advertises endpoint groups including /v1/charges, /v1/charges/usage, /v1/withdrawals, and /v1/webhooks/endpoints, which is consistent with a ledger-and-webhook payment backend rather than a simple invoice generator
• Whitepaper: No canonical standalone LNTPay whitepaper or litepaper surfaced in this pass. The clearest current sources of truth were the official site, docs corpus, quickstart, and public API reference; see ../whitepapers/lntpay-primary-sources-2026-05-02.md.
• Sources:
  • https://www.lntpay.com/
  • https://docs.lntpay.com/docs
  • https://docs.lntpay.com/quickstart-pay-per-request
  • https://api.lntpay.com/docs

Internal linkages

• Best upward reads: l402 and lightning-agent-tools.

Control surface

• The leverage sits in workspace-key scope, charge creation defaults, signed webhook truth, ledger balance and lock handling, withdrawal policy, and the boundary between LNTPay-managed state and the application logic waiting on charge.paid.

• That makes LNTPay useful hosted payment plumbing, but still narrower than the Lightning paid-request rail itself or the broader operator bundles layered on top.

• Last reviewed: 2026-06-14 UTC