CraysBitvora
Bitvora is built for teams that want Bitcoin payments inside an application: invoices, withdrawals, Lightning addresses, on-chain addresses, API keys, SDKs, webhooks and Nostr Wallet Connect support.
A developer wallet, not a timeline app
Bitvora sits in the wallet layer because the product is about moving value. The public website calls it a developer Bitcoin wallet and emphasizes Lightning, on-chain support, an API, webhooks, approval rules, Nostr Wallet Connect, Lightning addresses and transaction reports. That makes it closer to a payment operations account than to a Nostr client a person opens to read posts.
The important distinction is who the product is built for. A normal consumer wallet starts with a person who wants to hold sats, scan invoices and manage keys. Bitvora starts with a developer or business that wants payment primitives inside a product: create an invoice, send a withdrawal, receive a webhook, attach metadata, expose a Lightning address or let another app control spending through NWC.
That changes the safety questions. The first question is not whether the app has a beautiful feed. It is who controls the Bitvora account, how API keys are scoped, which approvals are enforced, how webhooks are verified, what limits apply, what happens when a payment fails and whether users understand the custody and permission model behind the product.
What Bitvora actually provides
The core Bitvora surface is a Bitcoin payment API. The docs show endpoints for estimating withdrawals, creating Lightning invoices, creating Lightning addresses, creating on-chain addresses and confirming withdrawals. A destination can be a Lightning address, on-chain Bitcoin address, Lightning invoice or LNURL string, which is exactly the kind of variety a business has to normalize before payments feel simple.
The public examples also show metadata traveling with invoices, addresses and withdrawals. That matters for products that need to tie a payment to a user, order, subscription, creator payout, marketplace transaction or internal accounting record. Bitvora is not only moving sats; it is giving builders a payment object that can be tracked inside their own software.
The product page adds the business features around that API layer: enterprise-grade security language, webhook notifications, approval rules, Nostr Wallet Connect, unlimited Lightning addresses and transaction reporting. The result is a hosted wallet control plane for developers who would rather integrate an API than operate every Lightning and on-chain detail themselves.
Lightning, on-chain and the bridge between them
Bitvora presents both Lightning and on-chain support, with pricing tiers that separate Lightning-only testing from broader production use. The Bitcoin endpoints show Lightning invoice creation, Lightning address creation, on-chain address creation and withdrawal confirmation. That combination is useful because business payment flows rarely stay inside one rail forever.
Lightning is the natural rail for small, fast app payments, zaps, subscriptions and content unlocks. On-chain Bitcoin remains useful for deposits, larger settlement, compatibility with external wallets and accounting flows that need a chain address. Bitvora's docs expose both through a common API vocabulary: deposits, withdrawals, balances, transactions, statuses and metadata.
The bridge is not magic. Each rail has different failure modes. Lightning payments can fail because of liquidity, routing or invoice expiry. On-chain payments involve confirmation time, address format and chain fees. A serious integration has to show pending states, settled states, failed states and reconciliation clearly instead of treating every payment as a single happy-path button.
Nostr Wallet Connect is the Nostr doorway
Bitvora belongs in the Nostr wallet conversation because it advertises Nostr Wallet Connect support and appears in NWC ecosystem lists as a wallet. NWC lets an app communicate with a wallet service through Nostr relays using encrypted request and response events. The user or account owner grants a connection, and the app can then request wallet actions within the allowed scope.
For Bitvora, NWC is not the whole product. It is one control surface on top of a broader payment platform. The API, SDKs, webhooks, Lightning addresses and reporting features matter even when no Nostr app is involved. But once NWC enters the picture, a Nostr client, bot, commerce tool or automation can ask the wallet service to pay, receive or report wallet state without holding the seed itself.
That is powerful and risky in the same breath. NWC reduces the need to paste private keys or wallet secrets into apps, but it creates a new permission object that can move money. The right use of Bitvora with NWC depends on budgets, revocation, account separation, approvals and clear monitoring. A connection that can pay should be treated like a payment credential, not a login decoration.
The API model is built around operational payment objects
The Bitcoin endpoint examples show a payment system built around structured objects rather than casual wallet clicks. An estimate returns recipient information, recipient type, sat amount, Bitvora fee and success probability. A Lightning invoice returns an internal id, node id, memo, hash, sat amount, settlement status, payment request and metadata.
That structure is useful for software. A product can create an invoice, show it to a customer, listen for settlement, fetch the deposit later and reconcile the order. A payout system can estimate a withdrawal, confirm the send, store the returned id and watch its status. A creator platform can attach internal user ids or order metadata without forcing a human operator to copy invoice strings all day.
The same structure requires discipline. Metadata can become sensitive. API responses can end up in logs. A payment id can become the join key between a public Nostr action and a private customer record. Bitvora gives builders the objects; the integration still has to decide what should be stored, displayed, redacted and deleted.
SDK coverage makes it feel like infrastructure
Bitvora publishes SDK documentation for Node.js, Python, Rust, Go and PHP. The Python examples show sending Bitcoin to multiple destination formats, creating Lightning addresses, creating Lightning invoices, fetching balances, listing transactions and looking up deposits or withdrawals. The Go docs show account balance, transactions, withdrawals, estimates, invoices and Lightning addresses.
The Rust docs make the same pattern explicit for typed application code: initialize with an API key, estimate a withdrawal, create a Lightning invoice, create a Lightning address, create an on-chain address, fetch withdrawals, fetch deposits, fetch balances and list transactions. The PHP docs add the same merchant-friendly vocabulary for projects still living in classic web stacks.
That range matters because payment infrastructure is often adopted by existing products rather than greenfield experiments. A media site, marketplace, SaaS tool, bot, restaurant system or internal dashboard may already be written in a language the team will not replace. Bitvora's SDK story is strongest when it lets a team add Bitcoin payment rails without turning the whole app into a wallet project.
Webhooks are where payments become product events
Bitvora's webhook docs say the platform can send a server notification when a Bitcoin transaction's state changes. The example payload includes an event name, sat amount, chain transaction id, timestamps, fee, id, Lightning invoice id, metadata, network type, rail type, recipient and status. That is the difference between a payment processor and a wallet screen.
A product needs those callbacks because users do not wait politely inside one tab. A checkout needs to mark an order paid. A subscription system needs to extend access. A marketplace needs to release a digital good. A zap or reward bot needs to know whether a payment actually happened. A webhook turns settlement into an application event that other systems can react to.
The same docs warn that webhook signatures must be validated. That warning should be taken literally. If a server accepts fake payment callbacks, an attacker can mark unpaid orders as paid or trigger payouts from bad data. The webhook secret, signature validation and replay handling are part of the wallet integration, not a nice-to-have afterthought.
Approval rules and account limits belong in the product design
The public pricing grid lists account tiers, transaction limits, fees and custom approval rules. Free accounts are positioned for testing and small projects, with Lightning Network only, a monthly transaction limit and bitvora.me Lightning addresses. Premium and Pro add broader support, higher or no transaction limits, lower listed fees and stronger support language.
These details are not just pricing trivia. Limits define what happens when a product grows. Fees define whether tiny payments remain economical. Custom domains for Lightning addresses affect branding and user trust. Approval rules decide whether an app can move money automatically or whether a human has to approve certain classes of payment.
A good Bitvora integration should make those constraints visible before launch. A prototype can tolerate manual checks and low limits. A production commerce flow needs a plan for monthly volume, failed withdrawals, approval thresholds, support response, user refunds and accounting exports. The wallet account becomes an operational dependency.
The Zapvertiser tutorial shows Bitvora in a Nostr flow
The clearest public Nostr example from Bitvora is the Zapvertiser Bot tutorial. It walks through a Go bot that uses a Nostr secret key and a Bitvora API key, fetches followed profiles, finds Lightning Addresses, prepares a zap request, calls the LNURL callback and then pays the returned invoice through the Bitvora Go SDK.
That example matters because it shows Bitvora as a payment backend for Nostr automation. The Nostr side discovers people and produces the zap context. The Lightning Address and LNURL side produces an invoice. The Bitvora side executes the payment. The bot is not a wallet UI; it is a programmable wallet action inside a Nostr social graph.
It also shows why permission boundaries matter. A bot with a Nostr signing key and a payment API key can spend money according to code. That can be delightful for rewards, ads, experiments and creator support, but it can also go wrong quickly if the account lacks budgets, logs, limits and a kill switch.
Public repositories reveal the wider stack
The Bitvora GitHub organization identifies Bitvora Inc in Canada and links back to bitvora.com. Its public repositories include SDKs, relay projects, a wallet relay, NWC tools, commerce backend and frontend work, and subscription/content experiments such as satsclub. That repository mix supports the public positioning: Bitvora is not only a hosted wallet account, but a builder-oriented Bitcoin and Nostr infrastructure company.
The SDK repos are small but useful signals. bitvora-ts, bitvora-py, bitvora-rs, go-bitvora and bitvora-php show language-specific integration work around the API. The wallet-relay repository describes itself as a specialized relay for wallet service providers to process NWC and Cashu wallet events, built on Khatru. The nwc-tools repository describes a terminal wallet interface for NWC.
The commerce repositories are equally important. bitvora-commerce-backend is described as a merchant payment solution powered by Bitcoin and NWC, while bitvora-commerce-frontend and satsclub point toward checkout, merchant and subscription use cases. These are not all polished end-user products, but they show where Bitvora is placing its infrastructure bets.
Wallet relay work makes NWC more than a checkbox
NWC depends on relays because wallet requests and responses move as Nostr events. Bitvora's wallet-relay repository is therefore especially relevant. It is described as a high-performance relay for enabling NWC and Cashu wallet events, with setup instructions, environment variables, LMDB storage and optional systemd/nginx deployment.
That does not mean every Bitvora customer needs to run Bitvora's relay code. It does mean Bitvora's public work recognizes that wallet connectivity has infrastructure requirements beyond an API endpoint. Relay reliability, event handling, storage, authentication and deployment all matter when apps are expected to request wallet actions in real time.
For users, the practical point is simple: if an app says it works with Bitvora through NWC, the payment path may involve the app, the wallet service, one or more relays, Bitvora's API and the underlying Bitcoin rail. Debugging needs to separate those layers. A failed zap may be a relay problem, wallet permission problem, invoice problem, API problem or Lightning routing problem.
Commerce and subscriptions are the natural use case
Bitvora's site has solution pages for industries such as digital content, SaaS, e-commerce, marketplaces, restaurants, charities, hotels, gambling, freelancing and exchanges. The digital content page talks about subscriptions, streaming payments and the possibility of automatic monthly payments through Nostr Wallet Connect as support increases.
That framing makes sense. Nostr and Bitcoin payments become most interesting when small value can move around content, memberships, creator access, communities, tickets, paid APIs and digital services. Bitvora gives those products a way to receive, send, report and automate payments without each project becoming a Lightning operations company.
The open question is user experience. Bitcoin can reduce card-network friction and make small payments possible, but businesses still need refunds, receipts, tax records, fraud handling, support, legal compliance and clear settlement accounting. Bitvora can supply payment rails; the merchant still has to make the purchase feel normal.
Custody, trust and API keys are the real risk surface
Bitvora is a hosted payment platform. That means trust sits in the account, the API key, the approval system, the service availability, the legal terms and the operational security behind the platform. It is not the same risk profile as a self-custodial mobile wallet or a Lightning node a user controls directly.
API keys are especially sensitive. A leaked key can expose balances, create invoices, fetch transaction history or initiate payments depending on permissions. A badly stored key in a bot, web server, client bundle, CI log or analytics event can turn a payment integration into a loss event. Keys belong on servers, in secret managers and behind narrow permissions.
NWC adds another permission channel. A connection string or pairing can authorize an app to ask the wallet service for actions. The better pattern is to isolate use cases: separate accounts or keys for testing, operations, bots, high-volume production and experimental Nostr apps. Small limits and visible revocation turn a scary integration into something manageable.
Privacy depends on metadata choices
Bitcoin and Lightning can reduce exposure compared with card payments, but Bitvora integrations still create data. The docs repeatedly show optional metadata fields such as internal user ids and email-like values. Those fields are useful for reconciliation, but they can also link wallet actions to customer records, social identities and business events.
A Nostr-facing product needs extra care because public social actions and private payment records can become easy to correlate. A zap is often public. A Lightning Address can identify a person. A merchant order may include email, shipping, IP logs and account records. Bitvora can carry metadata; that does not mean every integration should send everything it knows.
A safer practice is to store only the metadata needed for support and accounting, use opaque internal ids where possible, keep webhook payloads out of public logs, redact secrets from error reporting and document what payment data the product keeps. Payment privacy is not a single feature; it is a habit across API calls, logs, dashboards and support workflows.
Where Bitvora is strong
Bitvora is strongest where a builder wants Bitcoin payments as infrastructure rather than as a hobby project. The docs are practical, the SDK surface spans several languages, the endpoints map to real product actions, and the public Nostr work shows that Bitvora understands zaps, NWC and relay-based wallet connectivity.
It is also strong for businesses that need both receiving and sending. Many payment tools only focus on checkout. Bitvora's examples include invoices, Lightning addresses, on-chain addresses, withdrawal estimates, withdrawal confirmation, balances, transactions and webhooks. That is closer to a treasury and payout layer than a one-button donation widget.
The platform is especially interesting for Nostr products that need payments but do not want to hold keys in the client. A creator tool, bot, media app, marketplace or membership system can pair Nostr identity with a hosted payment backend. Used carefully, that gives users and operators more flexibility than a closed, single-app wallet balance.
Where Bitvora needs careful checking
Bitvora should not be treated as interchangeable with a self-custodial wallet. If an app promises users control, it has to explain which part is controlled by the user, which part is controlled by Bitvora, which part is controlled by the app and which part depends on NWC permissions. Hosted infrastructure can be useful without pretending it is sovereign custody.
Availability also matters. A payment product depends on API uptime, Lightning liquidity, on-chain fee conditions, relay behavior for NWC, webhook delivery and support response. Before using Bitvora for serious volume, a team should test failed payments, expired invoices, duplicate callbacks, API errors, approval blocks, limit exhaustion and key rotation.
The public documentation should be checked at integration time because payment services change quickly. Pricing, limits, network support, supported SDK versions, account permissions and NWC capabilities can move. A good launch checklist includes a current docs review, a small live test, a rollback path and a clear way to disable automated payments.
What to verify before connecting an app
Start with the account model. Know who owns the Bitvora account, who can create API keys, who can approve payments, who can see reports, what limits apply and how funds are recovered or withdrawn. A developer wallet becomes business infrastructure once users depend on it.
Then test the payment rails separately. Create a Lightning invoice, create a Lightning address, test a small withdrawal, estimate fees, create an on-chain address if the plan supports it, inspect transaction history and verify webhook signatures. Add NWC only after the basic API behavior is understood.
Finally connect the app with small limits. Test revocation, replayed webhooks, relay outages, API-key rotation, failed invoices, expired invoices, duplicate zap attempts and metadata leakage. Bitvora can make Bitcoin payments easier to build, but the app still has to prove that money moves only when the product really means it.
Sources worth opening
Start with Bitvora's own product page and developer docs, then inspect the public GitHub organization, SDK repositories, wallet-relay work, NWC references and the Zapvertiser tutorial that shows the wallet API inside a real Nostr zap workflow.
- Bitvora official website
- Bitvora developer documentation introduction
- Bitvora supported SDKs
- Bitvora Python SDK documentation
- Bitvora Rust SDK documentation
- Bitvora Go SDK documentation
- Bitvora PHP SDK documentation
- Bitvora Bitcoin endpoints documentation
- Bitvora endpoints status code documentation
- Bitvora webhook documentation
- Bitvora Zapvertiser Bot tutorial
- Bitvora digital content payments solution
- Bitvora GitHub organization
- bitvora/wallet-relay
- bitvora/nwc-tools
- bitvora/bitvora-commerce-backend
- bitvora/bitvora-commerce-frontend
- bitvora/satsclub
- bitvora/sw2
- bitvora/aegis
- bitvora/team-relay
- bitvora/bitvora-ts
- bitvora/bitvora-py
- bitvora/bitvora-rs
- bitvora/go-bitvora
- bitvora/bitvora-php
- GitHub API metadata for Bitvora organization
- GitHub API metadata for Bitvora repositories
- getAlby awesome-nwc list
- Nostr Wallet Connect documentation
- NWC benefits and features
- NIP-47 Nostr Wallet Connect
- OpenSats Nostr Wallet Connect topic
- Alby introduction to Nostr Wallet Connect
- Bitcoin Magazine on Nostr Wallet Connect
- The Bitcoin Manual on NWC security risk
