LNTPay

• Name: LNTPay
• URL: https://www.lntpay.com/
• Category: Lightning micropayments infrastructure / paid-API control plane / BOLT11 invoice-and-ledger backend
• Tags: bitcoin-ecosystem
• Summary: LNTPay is a Lightning micropayment backend, not a general checkout stack. It issues BOLT11 charges, keeps a workspace ledger, signs webhook events, and handles outbound invoice payments. Useful because it packages paid-API plumbing cleanly enough for developers to build on.
• 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 comparison points: l402, boltwall, and btcpay-server.

• Last reviewed: 2026-05-02 UTC