NakaPay
NakaPay is not a social client or a wallet brand. It is a developer-facing Lightning payment layer for businesses that want invoices, checkout components, webhooks and optional non-custodial settlement through Nostr Wallet Connect.
NakaPay is payment infrastructure, not a Nostr client
NakaPay sits in the merchant layer of the Nostr and Lightning ecosystem. It is not trying to be a timeline, a social app, a browser signer or a general wallet. The product gives developers and small businesses a way to accept Bitcoin Lightning payments through payment requests, API calls, checkout components, webhooks and a dashboard. The customer sees a payment flow. The developer sees an API. The merchant sees records and settlement.
That makes NakaPay closer to a lightweight Bitcoin payment processor than to a Nostr app in the social sense. A site can call the NakaPay API, create a payment request for a number of satoshis, present a Lightning invoice or checkout modal, then wait for status changes. If the merchant has connected a wallet through Nostr Wallet Connect, NakaPay says the payment can go directly to that wallet. If not, the managed mode handles payment flow and forwarding.
The useful way to read NakaPay is to ask what part of a business workflow it wants to own. It is not the cold-storage policy, the whole accounting system, or the social identity layer. It is the transaction surface between a product and a payer: create the invoice, show the payer what to scan or copy, learn whether the payment completed, and give the merchant enough API and webhook data to unlock the thing that was sold.
The public footprint is young but unusually explicit
NakaPay's own site describes the product as Bitcoin Lightning payments for developers, with non-custodial wallet support, low fees and fast integration. The documentation is more concrete than the homepage. It names API keys, a v1 API, a payment-request endpoint, SDK installation commands, React components, webhook events, fee fields, NWC mode flags and status values such as pending, completed, expired and failed.
The operator trail points to RapidMVP and the GitHub account hubavka. NakaPay's footer says it is built by RapidMVP, and RapidMVP's projects page describes NakaPay as a non-custodial Bitcoin Lightning payment platform with a complete SDK ecosystem, webhook system and merchant dashboard. The SDK repositories live under hubavka, not under a large foundation account. That does not make the product bad, but it tells you to read it like an early, focused startup product rather than a long-lived public standard.
The code footprint is also modest. The Node SDK repository is public, MIT licensed, and has a small commit history. The React component repository is public too. The main hosted service is not presented as fully open-source infrastructure, so your trust is split: you can inspect client libraries and examples, but you still depend on the hosted NakaPay service, its dashboard, API behavior, uptime, data handling and future pricing.
Where Nostr enters the payment flow
The Nostr link is Nostr Wallet Connect, usually shortened to NWC. NWC is defined around NIP-47 and uses Nostr relays as a transport between an app and a wallet service. A wallet gives an app a connection string with a wallet public key, relay and secret. The app can then send encrypted requests through the relay and the wallet can answer or perform an action according to the permissions granted.
For NakaPay, NWC is not a marketing badge. It changes who receives money and who must be online. The non-custodial documentation says the merchant can connect a compatible Lightning wallet, and the required permissions include `make_invoice`, `get_balance` and `pay_invoice`. With that connection in place, new payment requests can be processed using the merchant's own wallet while NakaPay handles the workflow around the payment.
That is the important distinction for a reader. NakaPay does not become a social Nostr client because it uses NWC. It becomes a Nostr-aware payment service because it can talk to wallets over a Nostr relay. The user should not confuse that with posting notes or using the merchant's public Nostr identity. A payment connection should be treated as a payment credential, not as a casual login.
Dual payment modes are the core product choice
NakaPay documents two payment modes. In non-custodial mode, a merchant connects a Lightning wallet and payments go directly to that wallet. In custodial mode, NakaPay manages the payment process and forwards funds to the configured Lightning address. The developer's integration is meant to stay the same while the account configuration decides which route is used.
That automatic switching is convenient, but it is also a place where you should slow down. A business needs to know which mode is active for each payment, especially when reconciling money later. The API reference exposes an `isNwc` field, and webhook payloads can include `isNwc`, `nwcRelay`, `preimage`, `feeAmount` and `feePercentage`. Those fields should not be ignored as technical decoration. They are the clues that tell you how the payment actually moved.
The product promise is therefore not simply non-custodial. The more precise reading is that NakaPay supports non-custodial settlement when you connect a compatible NWC wallet, while retaining a managed mode for easier setup. That is a practical tradeoff. A merchant can start quickly, then tighten control by connecting a wallet, but should verify that the dashboard, exports, webhooks and internal records make the current mode visible.
API keys belong on the server
NakaPay's docs repeat one security point with unusual force: API keys must stay server-side. The getting-started guide, SDK guide, React documentation and GitHub READMEs all warn against exposing a NakaPay key in frontend code or in public environment variables such as a Next.js `NEXT_PUBLIC_` prefix. That warning should shape the integration from the first commit.
The intended pattern is straightforward. Your backend stores `NAKAPAY_API_KEY`, receives a purchase request from your frontend, validates the amount and description, calls NakaPay from the server, and returns only the payment data your browser needs. The browser should never hold the secret that can create payment requests, read payment history or interact with account-level payment tools.
This matters because payment APIs are a different category of developer convenience. A leaked analytics token might be annoying. A leaked payment token can let someone create transactions, scrape records, test your limits or trigger weird customer-facing states. If you use NakaPay, review logs, build output, environment variable names, client bundles and deployment dashboards for accidental key exposure before launch.
Payment requests are the smallest useful unit
The API reference centers on payment requests. A create request sends an amount in satoshis, a description, a destination wallet value, optional metadata and an expiration time. The response can include an ID, invoice, status, amount, fee information, metadata, payment hash and mode fields. That is exactly the object a checkout or paid feature needs to track.
The subtle part is the `destinationWallet` field. The API reference says it is required, but in non-custodial NWC mode it is stored for records while payments go directly to the connected wallet. In custodial mode, it tells NakaPay where to forward funds. A developer should not assume this field is always the actual final path of the money. It is part of the record, and the active mode decides the behavior.
Good integrations treat the payment request ID as the durable reference. Store it beside the order, content unlock, invoice, customer account or donation record. Do not rely only on a wallet notification, a copied invoice string or a browser success screen. If your app sells access, the backend should be able to answer a boring question later: which NakaPay payment request paid for this thing?
The SDKs are convenience layers, not magic
NakaPay publishes a Node.js SDK named `nakapay-sdk` and React components named `nakapay-react`. The SDK wraps server-side API calls such as creating payment requests, checking payment status, retrieving history and registering webhooks. The React package gives developers payment buttons, modals and real-time update options for user-facing checkout flows.
The current npm data is small but concrete: `nakapay-sdk` is published as an MIT-licensed package with a public GitHub repository, and `nakapay-react` is also MIT licensed with its own repository. Both packages were last modified in June 2025 according to npm metadata checked on June 12, 2026. That is not a guarantee of maintenance quality, but it is a useful date for evaluating whether the package line is active enough for your risk tolerance.
You should still design around the API boundary, not around a component as if it were a payment system by itself. A React button can start the user flow, but the backend must create the payment securely, validate amounts, verify status, process webhooks idempotently and decide what the customer gets after payment. The SDKs make the integration shorter; they do not remove your responsibility for payment state.
React checkout needs a backend spine
The React documentation is useful because it does not pretend the frontend can do everything. It shows `NakaPayButton` and `NakaPayModal`, but it also tells the developer to create backend endpoints for payment creation and status checks. That is the correct pattern for a payment component: the browser handles the interaction, while the server owns secrets and final state.
The React package supports multiple real-time strategies: Ably, WebSocket, Server-Sent Events and polling fallback. That is a broad set of choices for a small payment product. In a serverless deployment, Ably or SSE can be easier than running a permanent WebSocket service. On a dedicated server, a WebSocket path may be lower latency. During development, polling is simple and predictable.
The operational lesson is to choose one method intentionally. A payment confirmation that arrives two seconds later is fine for a donation button. A point-of-sale experience may need faster visible confirmation. A membership unlock must be resilient to page reloads. NakaPay gives options, but the merchant still needs to decide how much latency, infrastructure and dependency complexity the checkout can tolerate.
Webhooks are where money becomes product state
NakaPay's webhook guide describes events for completed, failed and expired payments. The payload example includes amount, description, status, timestamp, mode fields, NWC relay, preimage, fee data and metadata. That is the data your backend needs when a payment should unlock a download, mark an order paid, extend a subscription, send a receipt or alert a team.
A webhook handler should be boring and strict. Verify the payload or signature method that applies to your account, store the event, process it once, return success only after durable work, and handle retries without double-granting access. If the documentation and package examples differ in event naming, test the real dashboard behavior before writing production logic around a name.
Do not make the browser the source of truth for paid access. The browser can show a success state, but the backend should wait for NakaPay status or a webhook before delivering durable value. This protects the merchant from closed tabs, duplicate clicks, fake client events, stale modals and customers who pay from a different device than the one that opened the checkout.
NWC permissions deserve a separate review
NakaPay's non-custodial documentation names three required NWC permissions: `make_invoice`, `get_balance` and `pay_invoice`. The first lets NakaPay request invoices from the connected wallet. The second lets it read balance. The third matters because NakaPay can collect fees through the merchant's wallet permission set. Smooth fees and direct settlement are useful, but they should be scoped.
If your wallet supports budgets, spending limits, expiration, app names or revocation, use them. Create a dedicated NakaPay connection rather than reusing a broad wallet credential across many services. Test whether the connection can be revoked from the wallet side and from the NakaPay side. Confirm that a revoked connection stops new NWC payments and that the app fails clearly rather than silently falling into an unexpected mode.
This is where NWC becomes powerful and risky at the same time. The connection string may include enough information to authorize wallet actions through a relay. Never paste it into a support chat, screenshot it publicly, or store it in a place that ordinary staff can read. Treat it with the same seriousness as a production API key, because in practice it can be a live permission path into payment operations.
Fees are simple on the page and detailed in the records
NakaPay markets a low transaction fee, usually presented as 0.5%. The getting-started guide and API reference add detail: payments below 1,000 sats use 10 sats or 0.5%, whichever is higher, and payments of 1,000 sats or more use 0.5%. The minimum payment amount is documented as 21 sats. Those details matter for micropayments where a fixed 10-sat fee can be a large percentage of a tiny payment.
The API and webhook records include `feeAmount` and `feePercentage`. A merchant should store those fields rather than recalculating fees later from a marketing page. Fee logic can change, special agreements may exist, and rounding can matter. If you are selling digital goods or paid access in small amounts, a few satoshis of difference can distort margin analysis across many events.
For non-custodial payments, pay special attention to the fee collection path. The documentation describes NakaPay collecting its fee through the connected wallet's permissions. That may create a second wallet-side action around a customer payment. Your accounting records should distinguish gross customer payment, NakaPay fee, network costs, final net amount and any failed fee collection cases.
The LightMarket demo shows the intended developer story
NakaPay links to LightMarket, a showcase app for digital products. The public demo presents a marketplace for UI kits, icons, photos, fonts, templates and tips, with Lightning payment messaging around instant global purchases. The associated GitHub repository describes the app as a complete reference implementation using Next.js 15, React, TypeScript, `nakapay-sdk` and `nakapay-react`.
A showcase is not production evidence by itself, but it reveals what NakaPay thinks its best use case looks like. The fit is digital commerce: a product has a price in sats, the customer clicks, the app creates a payment request, the UI shows a payment flow, and a backend endpoint maps payment state back to the product. That is more concrete than a generic payment API pitch.
When evaluating NakaPay, use the showcase as a pattern library, not as proof that your own checkout is done. Compare the example to your own needs: tax, refunds, access control, email receipts, fraud policy, subscription state, customer accounts, invoice expiry, support tools and accounting exports. A demo can teach the happy path. Production is where you test every path that is not happy.
Alby Hub adds a second signal
NakaPay also appears in the wider NWC ecosystem. The getAlby awesome-nwc list describes it as a Bitcoin Lightning payment service for developers and entrepreneurs, and Alby Hub release notes mention adding NakaPay to the Hub App Store. That matters because Alby Hub is one of the most visible NWC wallet-service environments, and app-store inclusion makes NakaPay easier for a self-custodial user to discover.
This does not make NakaPay an Alby product. It means the product is visible inside an ecosystem where wallets and apps connect through NWC. If a merchant already uses Alby Hub, the path from wallet to payment app may be shorter. If a merchant uses Zeus, LNbits or another NWC-compatible wallet, the same principle should apply once the wallet grants the required permissions.
You should still verify compatibility from your own wallet, not from a logo row. NWC is a protocol pattern, but wallets differ in permissions, budget controls, relay defaults, uptime and error handling. A NakaPay integration that works smoothly with one wallet service may need extra testing with another. Wallet selection is part of payment infrastructure, not an afterthought.
Custody language needs careful reading
NakaPay's site emphasizes non-custodial payments and says payments flow directly to the merchant's wallet when non-custodial mode is active. Its FAQ also says the service supports both non-custodial and custodial modes. Those two statements can both be true, but they need to be held together. The product is not simply one fixed custody model in every account state.
For a reader, the practical question is not whether the homepage uses a reassuring phrase. The question is which mode will be used for your next payment. Check the dashboard, inspect an API response, review webhook fields, and pay a test invoice while watching the wallet. If the mode is non-custodial, the wallet should receive funds directly. If the mode is managed, you should understand forwarding, timing and responsibility.
This is especially important for businesses that use Bitcoin as money rather than as a novelty. A hobby page can tolerate a little ambiguity. A merchant with invoices, support obligations, books and staff cannot. Write down the active mode, the connected wallet, the NWC permissions, the fallback behavior and the person responsible for revoking the connection if something looks wrong.
The privacy and terms pages clarify responsibility
The privacy policy says NakaPay processes information such as transaction amounts, recipient addresses, invoices or node IDs to facilitate payments, and that LNURL authentication data may include public keys and signed challenges. It also says the service may use information to manage accounts, process transactions, analyze usage, notify users and comply with legal obligations. That is normal service language, but it is still data a business should account for.
The terms page frames NakaPay as a non-custodial Bitcoin Lightning payment processing service and says users are responsible for securing their own Lightning wallet and private keys. It also has acceptable-use language and limitation-of-liability language. That is a reminder that a non-custodial payment stack does not transfer operational responsibility away from the merchant.
Before using NakaPay with customers, check whether the privacy and terms language fits your own obligations. If you sell to users in regulated regions, process personal data, issue receipts, or maintain customer records, your own policies may need to describe the payment service. NakaPay can handle checkout mechanics, but you remain responsible for how your business communicates payment, data and refund practices.
NakaPay is not the NAKA Pay card app
There is a naming collision worth avoiding. Searches for NakaPay can surface a separate NAKA Pay+ mobile app related to a virtual Visa card and USDt. That is not the NakaPay covered here. The Nostr ecosystem entry is the Bitcoin Lightning developer payment service at `nakapay.app`, with docs, SDKs, React components, NWC support and a RapidMVP footer trail.
This distinction is more than tidy labeling. Payment tools ask for sensitive credentials, wallet connections, account data or checkout setup. If you land on the wrong app store listing or a similarly named crypto product, you may evaluate the wrong risk model. Always verify the domain, favicon, docs, repository links and NWC ecosystem references before connecting a wallet or creating an API key.
The safe habit is to begin from the official site, then cross-check the documentation links, GitHub repositories and npm package names. The current project trail points to `nakapay.app`, `api.nakapay.app`, `nakapay-sdk`, `nakapay-react`, `hubavka/nakapay-sdk`, `hubavka/nakapay-react` and the LightMarket showcase. Anything outside that trail deserves fresh verification.
The strongest use cases are narrow and real
NakaPay is easiest to justify when you have a concrete checkout problem. You want to sell a digital download, accept a small Bitcoin payment in an app, add a tip button, unlock content after payment, or test Lightning revenue without building a full wallet integration. The API, SDK and React components are designed for that narrow path.
It also fits developers who want a server-side payment object and a frontend component without wiring every Lightning and NWC detail by hand. If you already use React or Next.js, the package examples map cleanly to common app structures. If you use another backend stack, the REST API still provides the underlying payment-request model.
NakaPay is less obviously suited to high-volume enterprise payments, heavy compliance workflows, complex refunds, multi-entity accounting or businesses that need a mature, audited, fully open-source processor. That does not mean it cannot grow into those uses. It means your first production deployment should be sized to the product's current evidence, not to the most ambitious version of its homepage.
Reliability depends on more than NakaPay
A NakaPay checkout depends on several systems at once: the NakaPay API, the merchant's backend, the payment UI, the Lightning Network, the connected wallet, the NWC relay, webhook delivery and whatever database stores order state. In non-custodial mode, wallet uptime and liquidity matter directly. If the wallet is offline or lacks inbound liquidity, customer payments can fail.
The non-custodial documentation is honest about this. It tells users to check wallet online status, NWC permissions, inbound liquidity, relay accessibility and outbound liquidity for fee collection. Those are not niche concerns. They are the operational reality of using your own wallet for business payments. Self-custody gives control, and control brings maintenance.
Plan for graceful failure. If a payment request expires, the customer should know what happened. If webhook delivery fails, the backend should retry or reconcile. If NWC mode fails, the merchant should know whether the product falls back to managed mode or rejects the payment. The better your failure behavior, the less a Lightning checkout feels experimental to ordinary customers.
Accounting starts at metadata
NakaPay lets payment requests carry metadata such as order IDs or customer IDs. Use that. The most common payment integration mistake is treating payment success as a separate world from product state. If a payment request is not tied to your internal order, account, invoice or content item, reconciliation becomes detective work later.
Metadata should be useful but not careless. Store internal IDs, not unnecessary personal data. Avoid putting sensitive customer notes into payment metadata unless you have a strong reason and understand retention. Keep enough context to reconcile, refund or support a user, but remember that payment services and logs can become long-lived records.
Also test exports and history before you need them. Create several payments with different amounts, statuses and metadata, then retrieve them through the dashboard or API. Confirm that the fields you need for bookkeeping are present: amount, fee, status, timestamps, mode, wallet path, invoice or payment hash, preimage where applicable and your own order reference.
Security checklist before production
Start with secrets. Keep the API key server-side, rotate it if it was ever copied into a frontend, and separate development from production. Put the NWC connection in a dedicated wallet profile or connection slot. Grant the minimum permissions NakaPay needs and use budgets or spending limits if your wallet supports them.
Then test small. Create a 21-sat payment, a 100-sat payment, a payment above 1,000 sats and an expired payment. Compare NakaPay's API response, dashboard record, wallet history, fee amount and webhook payload. Revoke the wallet connection and test the next payment. Change webhook URLs and confirm failure behavior. Reconnect and test again.
Finally, document the human side. Who owns the NakaPay account? Who can see API keys? Who can change the connected wallet? Who gets alerts? Who can access the email used for the account? What happens if the founder leaves, the wallet device is lost, or the product is sold? Payment infrastructure is technical until it breaks, then it becomes an operations problem.
How to decide whether to use it
Use NakaPay when you want a developer-friendly Lightning checkout with NWC-aware settlement and you are willing to test it like production money software. It is especially interesting for small digital products, creator tools, experimental marketplaces, paid app features, donation flows and builders who want a straightforward API before building their own payment stack.
Pause if you need mature enterprise controls, public audits, deep accounting exports, regulated fiat processing, complex refund workflows or a long public operating history. The product is promising, but the public footprint is still young. A careful merchant can still use it, but should start with bounded volume and keep a tested fallback payment method.
The healthy verdict is practical. NakaPay is a real NWC-connected Bitcoin Lightning payment tool, not a duplicated wallet page and not a generic Nostr client. Its value is the bridge between developer checkout code and wallet settlement. Its risk is the same bridge: API keys, NWC permissions, webhook state, wallet uptime and fee handling all need to be understood before the first meaningful customer payment.
Sources worth opening
Open NakaPay's own website and documentation first, then compare the SDK repositories, npm packages, LightMarket showcase, NWC references, NIP-47, Alby Hub release notes and independent NWC security commentary before putting production revenue behind it.
- NakaPay official website
- NakaPay getting started documentation
- NakaPay API reference
- NakaPay Node.js SDK guide
- NakaPay React components documentation
- NakaPay non-custodial payments documentation
- NakaPay real-time notifications documentation
- NakaPay webhooks guide
- NakaPay FAQ
- NakaPay About page
- NakaPay Privacy Policy
- NakaPay Terms of Service
- NakaPay contact page
- NakaPay showcase page
- LightMarket NakaPay demo
- hubavka/nakapay-sdk GitHub repository
- hubavka/nakapay-react GitHub repository
- hubavka/lightmarket-showcase GitHub repository
- nakapay-sdk npm package
- nakapay-react npm package
- getAlby awesome-nwc project list
- Nostr Wallet Connect official documentation
- Nostr Wallet Connect official site
- NIP-47 Nostr Wallet Connect specification
- Alby blog introducing Nostr Wallet Connect
- Alby Hub v1.18.2 release notes mentioning NakaPay
- RapidMVP projects page with NakaPay
- RapidMVP official website
- NWC Nostr profile announcement stream
- Bitcoin Magazine article on Nostr Wallet Connect
- The Bitcoin Manual NWC risk analysis
- Breez SDK Liquid NWC guide
