Nostr Payment Tools
The Nostr checkout is not one button. It is a stack of invoices, zaps, wallet permissions, merchant tools, claim links, hosted wallets, self-hosted servers and user trust.
Checkout begins before payment
A checkout is not only the moment a wallet pays an invoice. The commercial flow begins earlier: the buyer sees an offer, identifies the seller, checks the amount, understands the currency, approves a wallet action and expects something to happen after settlement. Nostr changes several of those steps because identity, social proof and payment instructions can be tied to signed events.
This is why the Commerce hub separates payment tools from marketplaces. A marketplace may show the thing for sale. A payment tool decides how value moves and what the user is asked to trust. A claim link, an invoice, a wallet connection, a zap and a self-hosted merchant server all feel like payments to a user, but they carry different risk.
The page matters because when you understands the payment surface makes better choices. They can tell when they are approving one invoice, connecting a wallet service, trusting a hosted processor or running their own stack.
BTCPay Server is the self-hosted merchant anchor
BTCPay Server is not a Nostr-specific project, but it belongs in Commerce because it remains one of the strongest examples of sovereign Bitcoin payment infrastructure. A merchant can run a payment processor, generate invoices, connect wallets, avoid a custodial processor and build checkout flows without handing the core payment relationship to a third party.
In a Nostr context, BTCPay is useful as a bridge between protocol-native identity and familiar merchant operations. A seller can publish, communicate or prove context through Nostr while still using a mature Bitcoin payment processor for invoices, stores and accounting. That is less glamorous than a pure Nostr checkout and often more realistic.
You takeaway is simple: Nostr commerce does not need every tool to be Nostr-only. It needs the right boundary. Use Nostr for identity, discovery, events, public proof and social graph. Use a battle-tested payment processor when the merchant needs reliability, reporting and operational control.
NWC turns wallet access into a permission question
NIP-47, Nostr Wallet Connect, describes communication between a client and a wallet service through encrypted messages over relays. A user gets a connection URI from a wallet service, gives it to an app, and the app can request actions such as paying invoices, creating invoices, reading balances or listing transactions, depending on what the wallet service allows.
For commerce, NWC is a huge convenience and a serious trust boundary. A web app no longer needs to integrate every wallet directly. A wallet can sit behind a standard protocol. But a user needs to know what the connection can do, what budget limits exist, when it expires and how to revoke it.
This is the wallet-permission layer behind many modern Nostr payment experiences. A product can feel smooth because the wallet is already connected. That same smoothness can become dangerous when users approve broad permissions without reading them. Good payment pages explain the difference between a single invoice and a reusable wallet connection.
Zaps are social payments, not generic receipts
NIP-57 defines zap requests and zap receipts for Lightning payments between Nostr users and events. Zaps can reward posts, profiles, streams, articles and goals. They make money visible in the social graph. They also carry a caveat: a zap receipt is a receipt event from the recipient's LNURL server, not a universal court-grade proof that every business obligation has been fulfilled.
That distinction matters in commerce. A zap can support a creator, tip a post, fund a goal or pay attention into a room. It is not always the same as buying a product, settling an invoice for goods or paying an escrow. A hub that blurs these categories confuses you.
Payment tools such as ZapplePay, NostrPX, Flash and NakaPay sit in this broad payment zone. You need to know what action each tool actually performs: tipping, checkout, links, invoices, balances, receipts, wallet connection or merchant workflow.
BitcoinLink shows how small the surface can get
BitcoinLink is valuable because it turns a payment into a claimable link. Its page in this archive already goes deep into NWC permissions, encrypted events, relay assumptions and claim flows. The reason it belongs beside payment tools is that it demonstrates a product pattern: send value without building a full account system or custodial database.
That pattern is easy to underestimate. A single-use payment link can be useful for gifts, refunds, small transfers, vouchers, event perks or customer service. It can also leak value if the link is forwarded, indexed, phished or stored badly. The link itself becomes part of the security model.
The Nostr angle is not that every payment link becomes social. It is that signed, encrypted, relay-carried events can coordinate state without the product owning every part of the relationship.
What to check before using a payment product
When you evaluate a payment tool can use a simple checklist. Is the payment custodial or non-custodial? Does the user approve each invoice or grant a reusable connection? Can the connection be capped and revoked? Which relays carry messages? Does the product use NIP-47, NIP-57, LNURL, WebLN, Cashu, on-chain Bitcoin or a hosted wallet API? What happens when an invoice expires? What happens when the app says paid but the merchant does not deliver?
Those questions are not paranoia. They are ordinary checkout literacy for open networks. Nostr can make payments feel small and social. Commerce still needs the adult parts: limits, refunds, receipts, privacy, support and clear permission boundaries.
Use this page as the payment map before opening the individual product profiles.
A wallet connection is a commercial relationship
NWC makes payment apps feel smooth because the wallet can sit behind the product. The user connects once, then the app can request actions through relays. That convenience changes the emotional feel of Nostr commerce. A payment stops being a separate ceremony and becomes part of the product surface.
The commercial risk changes too. A reusable connection is not the same as scanning one invoice. It can carry permissions, budget limits, expiration rules and notification behavior. If the user does not understand those boundaries, the product has become too easy in the wrong way.
Good NWC products make permission visible. They explain what can be done, how much can be spent, which wallet is connected, how to revoke access and what happens if the relay connection fails. That is not extra documentation. It is the checkout experience.
This is why payment tools belong beside Wallets and Privacy. The same click can be convenience, exposure or trust, depending on the permission.
Merchant payments still need operations
BTCPay Server remains important because merchants have operational needs that a social protocol cannot wish away. Stores need invoices, order tracking, refunds, accounting exports, tax context, product catalog connections, plugin ecosystems and staff workflows. A Nostr listing or profile can help discovery, but a merchant still needs to run a business.
The most realistic Nostr commerce may be hybrid for a long time. Nostr handles identity, public proof, announcements, customer relationships, listings, zaps or community context. Mature Bitcoin payment processors handle invoices and settlement. That is not a compromise in a negative sense. It is a division of labor.
You should not expect every Nostr commerce tool to replace BTCPay. Sometimes the better product is a connection between a Nostr audience and a payment system that already works.
The hub should make that visible so builders do not rebuild weak checkouts for ideological reasons.
Payment links are small but sharp
BitcoinLink-style products show how small a payment surface can be. A link can carry a claim path, a gift, a reimbursement, an event perk or a simple value transfer. It can feel lighter than asking someone to install a wallet, register an account or open a full checkout flow.
Small surfaces are easy to underestimate. A link can be forwarded to the wrong person, scraped, phished, expired, duplicated or stored insecurely. The product needs to explain who can claim it, how long it lasts, what happens after claim and what metadata is exposed along the way.
This is where Nostr event logic can be useful. State can be coordinated without every step living in a central database, and wallet permissions can be separated from the visible link. But the user should never have to guess whether the link itself is money, a pointer, an authorization or a receipt.
Payment tools earn trust when they make the small surface legible.
Receipts are not all the same
A Lightning invoice, a zap receipt, an NWC notification, a BTCPay order status and a marketplace message are different kinds of evidence. They can all appear near payment, but they do not prove the same thing. A paid invoice proves settlement of an invoice. A zap receipt proves a zap flow occurred. An order status says what a merchant system believes. None automatically proves delivery of the purchased good.
This distinction is especially important for creator commerce and marketplaces. A creator tip, a paid article, a product order and a P2P trade all have different post-payment expectations. The payment proof needs to match the promise.
The Commerce hub should teach you to ask: what does this receipt prove, who issued it, and what remains outside the payment record? That is how payment literacy starts.
Nostr can make more proof public and portable, but it cannot remove the need to read the promise carefully.
NIP-47 makes revocation part of UX
A wallet connection is only safe when the user can end it. NIP-47 makes long-lived app-to-wallet relationships possible, so the product must make revocation as visible as connection. A user should know where the permission lives, which app has it, which relay carries messages, what the spending limits are and how to kill the connection quickly.
That is not a security afterthought. It is the core UX of wallet-connected commerce. A product that makes connecting easy but revoking obscure is borrowing trust it has not earned.
The best NWC surfaces will feel almost boring: clear name, clear wallet, clear limit, clear expiration, clear recent activity and clear disconnect. Boring is good when money is involved.
Commerce needs this literacy because many you will first meet NWC through a convenient app, not through the standard text.
NIP-57 makes public money legible
Zaps are not only payments. They are public social receipts. A zap request and zap receipt let clients show that value moved in relation to a note, profile, stream, article or goal. That makes money legible in a way older web payments usually are not.
The legibility can be useful. A creator can show support. A post can gather visible appreciation. A goal can show progress. A community can reward a helpful answer. But the visibility can also become a ranking game, a harassment vector or a misleading signal of quality.
This is why zaps need context. A large zap does not prove a claim. A missing zap does not make work worthless. A zap receipt does not prove delivery. It proves a payment event in a specific flow.
Payment pages should keep that distinction close to you.
Cashu, ecash and wallet products widen the payment story
Nostr commerce increasingly touches Cashu and ecash-style wallets, even when the core protocol page is about listings or zaps. Ecash can make small balances, offline-feeling payments, wallet UX and privacy tradeoffs feel different from pure Lightning invoice flows. Some products combine Nostr identity, NWC permissions and ecash behavior in ways that are still evolving.
The important point is not to memorize every wallet architecture. It is to notice when the trust boundary changes. Is a mint involved? Is a wallet service involved? Is the payment a Lightning invoice, a zap, an ecash token, a claim link or an NWC request?
Different payment objects create different failure modes. A token can be lost. A mint can fail. A wallet service can be over-permissioned. A Lightning invoice can expire. A merchant processor can have order-state bugs.
Commerce gets safer when the page names the object before praising the product.
The merchant, the user and the wallet each see a different product
A merchant sees invoices, settlement, order status, support and bookkeeping. A user sees a button, a wallet prompt, a receipt and a promise. A wallet sees permissions, invoices, balances and transaction history. A payment tool succeeds only when all three views line up well enough.
Nostr complicates this because the wallet, identity and client may be separate. The merchant may know a public key, an email, a shipping address, an invoice ID or none of the above. The user may believe they paid because the wallet said so. The merchant may wait for a processor callback. The client may show a zap receipt that is not an order receipt.
Good payment design reduces those mismatches. It tells each party what happened in language they can understand. It does not ask a user to infer merchant state from protocol state.
That is why the article spends time on receipts. The visible proof must match the commercial promise.
NIP-98 and service auth sit near checkout
NIP-98 HTTP auth is not a payment standard, but it often sits close to commerce because services need to know that a request came from a key. A marketplace, media host, storage service or paid endpoint may need signed HTTP requests so the service can connect web behavior to Nostr identity.
This matters for product design. A user might sign into a merchant admin, upload media, call an API, fetch a protected file or manage payment settings. The payment may happen through Lightning, but service access may depend on signed HTTP authentication.
For you, the point is not to memorize NIP-98. It is to notice when a commerce product asks the user to sign something that is not a post or payment. The signing prompt should explain the action.
Commerce safety includes every signature near the checkout, not only the invoice.
Refunds are the adult test
A payment product can look excellent until a refund is needed. Refunds test whether the merchant knows who paid, whether the buyer can prove payment, whether the amount and currency are clear, whether the wallet can receive a return payment and whether the product has support workflows.
Bitcoin and Lightning payments are not card payments. That can be good for sovereignty and bad for lazy support assumptions. If a product sells goods or access, it needs to explain what happens when the wrong item ships, content fails to unlock or a duplicate payment occurs.
Nostr can help by tying identity, messages and receipts together, but the refund still needs product rules. A marketplace that ignores refunds is not mature commerce. A creator tool that ignores failed unlocks is not mature paid access.
You should look for this before trusting a payment surface.
What to open after this page
After the payment-tools overview, open NIP-47 and NIP-57 before judging individual products. NIP-47 explains why wallet connections feel convenient and why permission limits matter. NIP-57 explains why zaps are social payments rather than normal checkout receipts.
Then open BTCPay Server, BitcoinLink and the wallet-related pages. Compare the role of each tool. One may be a merchant processor, one may be a claim-link product, one may be a wallet connector, one may be a zap surface. Treating them as the same kind of payment app will confuse you.
Finally, read the Wallets hub. Commerce is where money moves; Wallets is where the user grants authority. The two pages belong together every time an app asks for reusable payment permission.
Sources worth opening
These are the primary trails used for this article. Open them when you want the protocol text, repository context or project surface behind the explanation.
