Zap Bot
Zap Bot brings Bitcoin payment actions into Discord. The useful promise is simple: add a bot to a server and let people send sats where the conversation already happens. The serious part is the boundary around Discord permissions, MakePrisms' operated service, NWC wallet authority, Lightning Address recipients and beta payment-state handling.
What Zap Bot is
Zap Bot is the Discord-facing payment bot from MakePrisms. The official Apps page uses the name `Discord Zap Bot` and says the bot can be added to a Discord server to enable one-click Bitcoin payments. That is the project this page follows, because the Nostr Wallet Connect ecosystem list links Zap Bot to `makeprisms.com/apps`.
That identity check matters. A web search also turns up other Discord bots and open-source experiments with similar names, including a separate `nwc-discord-bot` repository. Those may be interesting, but they are not the hub entry being covered here. The Crays page should describe the MakePrisms bot, its public app page, its Discord invite and its payment-service context.
Zap Bot is not a wallet. It is not a Nostr relay. It is not a full Nostr client. It is a Discord bot that puts Bitcoin payment actions into a Discord server. The Nostr part comes through the payment infrastructure around Nostr Wallet Connect and the broader MakePrisms product family, not through a public Nostr timeline inside Discord.
For a reader, the useful question is practical: if a community adds this bot, who can trigger payments, which wallet or payment service actually sends the sats, which recipient identifier is used, what Discord permissions are granted, and how clearly does the bot show payment status before a social chat becomes a money rail?
What the official page proves
The MakePrisms Apps page is compact but specific. It has an Apps section, a heading for Discord Zap Bot, a line that says the bot enables one-click Bitcoin payments in a Discord server, and an `Add Zap Bot` link. The same page also presents a Nostr Zap App for creating multiparty prisms and zapping hundreds of Nostr users.
The Discord invite URL is public enough to inspect. It goes through Discord OAuth, uses client id `1195455108813684786`, requests `scope=bot`, and includes permission integer `377957190784`. A server admin should treat that invite as a security surface, not as a decorative button. Adding a bot means adding a new actor to a server.
The official screenshot is also useful evidence. It shows a Discord channel named `#zaps`, a user running `/stats`, and Zap Bot returning all-time top totals with sent and received sats. That suggests the bot is not only a payment button; it has server-visible accounting or ranking behavior around payment activity.
The public page does not expose every command, every wallet path or every database field. A serious article should therefore stay close to what can be verified. Zap Bot is an operated MakePrisms Discord payment bot. Its public promise is one-click Bitcoin payments. Its deeper behavior should be tested in a low-value Discord server before it is trusted in a real community.
Where the payment backend shows through
Zap Bot sits beside the Prism API and Nostr Zap App. The API page says MakePrisms offers one-click, instant global payments with a few lines of code and provides a contact path for API access. The JavaScript-rendered docs app contains an OpenAPI definition titled `Zap API`, version `0.3.2-beta`.
That docs bundle describes a bearer-authenticated HTTP API using JSON request bodies and JSON responses. It defines users, single payments, prism payments, NWC, Lightning Address, pending payments and sending payments. It also describes endpoints for creating users, sending payments, paying invoices, checking payment status and querying user payment history.
This is important context for the Discord bot. The bot may be the user-facing surface, but the service logic belongs to the MakePrisms payment system. A Discord command can feel simple because the complicated parts are hidden: user records, NWC sender connections, Lightning Address receiver resolution, invoice payment, status polling and optional fees.
That does not make Zap Bot worse. It makes the trust boundary visible. You are not installing a peer-to-peer protocol directly into Discord. You are installing an operated bot that talks to an operated payment service that talks to wallets and Lightning endpoints.
The NWC side
The docs define NWC as Nostr Wallet Connect and describe it as a protocol for connecting to a user's wallet in a trust-minimized way. The usage section says a sending user can be created with `POST /user` and given an NWC so they can send. That is the core reason Zap Bot belongs in the NWC app map.
NWC is not a magic custody eraser. It gives an app or service a way to request wallet actions through a connection that the wallet can limit, expire and revoke. The NIP-47 model uses encrypted Nostr messages between an app and wallet service through relays. The app does not need to hold the user's bitcoin, but the wallet connection can still authorize real actions.
For Zap Bot, the safest user posture is the same as for other NWC apps: create a dedicated wallet connection for this bot or service, keep the spend budget small, set an expiration if supported, and revoke the connection when you no longer use it. A Discord server is social and fast-moving; wallet authority should be narrow and boring.
The docs also note that a payment can remain in `sending` while waiting for an NWC response or for the sender to confirm in their wallet, and that all initiated payments must be polled to reach a final state. That means one-click does not always mean one final instant. A good bot should make pending, sending, paid and failed states obvious.
The Lightning Address side
MakePrisms' docs define Lightning Address as a static internet identifier used for getting invoices from a user. They also describe a receiving user as someone who can optionally be created with a Lightning Address. This tells you how the service can pay people who are not directly sending through an NWC connection.
The docs say that if the receiver does not have a Lightning Address, the receiver can have a pending balance and the sender will not have funds taken from their wallet. The receiver can later claim by adding a Lightning Address with `PATCH /user/{userId}`. That is a subtle but important product behavior.
In a Discord server, pending balances can be useful because not every member has a payment endpoint ready. But they can also create confusion. A person may think they paid someone, while the service has only recorded a pending claim. The sender should know whether sats actually left the wallet, and the receiver should know what they need to add before anything settles.
Server admins should ask how Discord identities map to payment users, how Lightning Addresses are collected, whether address changes are verified, how pending balances expire, and what happens if a receiver never claims. Those questions matter more than the word noncustodial by itself.
Single payments and prism payments
The API docs distinguish a normal payment from a prism payment. A payment is one user paying another user. A prism payment is one user paying many users. The public $prism app demonstrates that same idea through split-zap recipient sets, where an event, list or interaction can become a group of recipients.
Zap Bot's Discord screenshot focuses on totals, not on the full command list. Still, the MakePrisms family clearly centers split and social payments. Discord is an especially natural place for this because communities already have contributors, moderators, event organizers, support helpers and casual group rituals that can be rewarded with small sats.
The risk is that group payment surfaces can hide complexity. A single payment needs a sender, receiver, amount and final status. A prism payment also needs weights, recipient eligibility, partial failures and clear accounting. If one recipient lacks a Lightning Address, if another wallet requires confirmation, or if a fee is attached, the server should not have to guess what happened.
A useful Zap Bot installation would show the difference between a paid payment, a pending receiver balance, a sending payment, and a failed action. Without that clarity, one-click payments can become one-click confusion.
Discord permissions deserve a slow click
The official invite uses Discord's bot authorization flow with a permissions integer. Discord documents permissions as bitwise flags. Decoded against the published flag values, the Zap Bot invite requests View Audit Log, View Channel, Send Messages, Read Message History, Create Public Threads, Create Private Threads and Send Messages in Threads.
Those permissions are not automatically outrageous for a payment bot that needs to respond in channels and threads. They are still worth reading. View Audit Log is a stronger-looking permission than ordinary message sending. Read Message History can expose context that is not part of a payment command. Thread permissions matter if the server uses private or public threads heavily.
A server admin should not add the bot at the top of the server and then forget it. Put the bot in a limited test server or limited channels first. Check which roles can call its commands. Check whether it can read channels where payments should not happen. Check whether payment announcements go to the right place.
Discord is a centralized platform with its own permissions, moderation model and logs. NWC can make the wallet side less custodial, but it does not make Discord permissions irrelevant. The bot still lives inside a server you administer.
What noncustodial means here
MakePrisms' Terms of Service say Prism is a noncustodial platform and does not operate Bitcoin wallet or node infrastructure to custody users' funds, keep backups or copies of passwords, seed phrases or similar wallet material. The terms also say Prism relies on third-party wallets and nodes to receive and process requests and complete payments.
That is an important promise, and it lines up with the NWC model. The bot or service should not be a bank account where all server members deposit funds. Instead, sender wallets and receiver endpoints do the payment work. The MakePrisms service coordinates, records and requests payment actions.
Noncustodial does not mean no risk. MakePrisms can still run the service, issue API keys, process user records, return payment states, apply fees where configured, change availability and be unavailable. The API terms say keys can be revoked or terminated, the API can be deprecated or terminated, and the service is provided as-is.
For readers, the right question is not whether MakePrisms holds seed phrases. The right question is which part of the payment path MakePrisms controls, which part your wallet controls, which part Discord controls, and what happens when any one of those parts fails.
Fees, API keys and operated-service risk
The docs describe optional fees attached to API keys. A fee can have a Lightning Address destination and a basis-points rate, where 100 basis points equals one percent. That is not necessarily a consumer-facing Zap Bot fee statement, but it proves the MakePrisms payment system can support fee settings at the API-key level.
This is exactly the kind of detail a Discord admin or developer should verify before adopting the bot. Are there service fees for bot payments? Are they visible before payment? Who sets them? Are they per server, per API key, per integration or per product? A payment bot is easier to trust when fees are explicit and boring.
The API license terms also matter. They say API keys are property of Prism and may be revoked or terminated, prohibit sharing credentials, prohibit excessive requests and allow changes to access methods for security and stability. Those are normal operated-service controls. They are also why the bot should not be described as a purely decentralized tool.
In practice, Zap Bot belongs in a middle category. It uses open payment primitives, wallet connections and Lightning identifiers, but it is still an operated service with terms, keys, permissions and availability. That category can be useful; it just needs to be named.
How it differs from ThunderTip
ThunderTip and Zap Bot sit near each other because both bring Lightning payments into chat platforms. ThunderTip is a Telegram bot with open-source code that stores encrypted NWC connection strings and coordinates tips between connected Telegram users. Zap Bot is the MakePrisms Discord bot tied to the broader Prism payment service.
The platform difference matters. Telegram flows often revolve around private bot chats and group commands. Discord flows revolve around server authorization, channel permissions, slash commands, threads and server roles. A Discord bot has to fit a server's permission model, not only a user's wallet model.
The evidence trail also differs. ThunderTip's repository lets a reader inspect TypeScript source directly. Zap Bot's public evidence is the MakePrisms Apps page, Discord OAuth invite, official screenshot, API docs bundle, terms and ecosystem references. That does not make one automatically better. It means the reader should evaluate them differently.
If you need a Telegram group bot, read ThunderTip. If you need a Discord server payment bot, read Zap Bot. If you need a browser handoff for Nostr zaps, read Zapper. The category is shared, but the trust boundaries are not identical.
How it fits Nostr without being a Nostr client
Zap Bot is in the Nostr map because NWC is a Nostr-based wallet connection protocol and because MakePrisms also builds Nostr zap and prism tools. That does not mean the Discord bot itself is a Nostr client. A Discord user may interact with the bot without seeing a Nostr event at all.
The Nostr connection is deeper than branding, though. NWC uses Nostr relays as the app-wallet communication layer. NIP-57 zaps use Nostr events to attach Lightning payments to users and notes. The MakePrisms Nostr Zap App uses event IDs, tags and Lightning Addresses to create multiparty payment sets. The same product family is clearly built around Nostr-shaped payment ideas.
This is a good example of Nostr escaping the social-feed box. The user may see a Discord channel, but the payment architecture can still benefit from a Nostr wallet-connection protocol. That is exactly why NWC matters: apps that are not Nostr clients can use it to talk to wallets.
The clean sentence is this: Zap Bot is a Discord payment app in the NWC ecosystem, not a Nostr social client. Its job is chat-native payments. The Nostr part is the wallet and payment protocol context.
Testing before a real server launch
Start in a throwaway Discord server. Add the bot from the official MakePrisms Apps page, not from a copied link in a random chat. Confirm the client id shown in the OAuth URL. Read the permission prompt. Do not grant the bot access to every channel if only one payment channel needs it.
Create a low-value wallet connection and a test receiving identity. Send the smallest payment the bot supports. Watch the sender wallet, receiver path and Discord message. If the payment enters a pending or sending state, wait and see how the bot reports the transition. A payment bot is only as useful as its failure messages.
Pay special attention to the first server prompt and the first command menu you see after installation. The public invite URL proves the bot-scope permission request, but the lived server experience can still include role restrictions, slash-command visibility, channel overrides and Discord-side command discovery. Record the initial settings before the first test payment, because those are the settings your moderators will need to understand later.
Test server behavior. Who can run commands? Can a moderator restrict the bot to a `#zaps` channel? Does it read or respond in private threads? Does it expose leaderboards or stats in a way the community wants? Can payments be mistaken for moderation rewards, role rewards or official server policy?
Then test cleanup. Remove the bot, revoke the wallet connection, rotate any API keys used for testing and confirm old commands no longer work. If the test cannot be safely undone, the production install is not ready.
What to ask before trusting it
Ask MakePrisms or the current docs how Zap Bot authenticates users, how Discord users map to Prism users, how payment commands are authorized, how pending balances are claimed, which wallets are supported, how NWC connections are stored or used, and whether fees apply to Discord payments.
Ask what data is retained. A Discord payment bot can learn server ids, channel ids, command timing, payment amounts, sender and receiver associations and wallet or Lightning Address metadata. The Privacy Policy and Terms are the starting point, but communities with sensitive membership should ask directly.
Ask how failed payments are handled. Does the sender wallet get charged only after a receiver can accept? The docs suggest pending receivers do not cause funds to leave the sender wallet, but the live bot behavior should be tested. What happens to partial prism payments? How are refunds, retries or unclaimed balances handled?
Finally, ask whether the bot is the right tool. For a public Discord where small tips and visible sats totals are part of the culture, it may be a strong fit. For private support channels, high-value payments or regulated commercial workflows, a more explicit payment approval process may be safer.
The bottom line
Zap Bot is a serious enough entry to deserve its own page because it shows NWC-style payments moving into Discord, one of the places where communities actually coordinate. It is not just another card on a map. It is a bridge between server chat, wallet authority, Lightning identifiers and MakePrisms' operated payment service.
The attractive part is obvious. A Discord server can reward contributors, send small thank-yous, track sats activity and make payment feel native to the room. The screenshot's `/stats` flow hints at the social layer: people can see sent and received totals, not only isolated invoices.
The caution is just as clear. A Discord bot brings permissions. A payment service brings terms, keys and availability. NWC brings wallet authority. Lightning Address brings recipient identity and claim behavior. One-click payments are valuable only if every click is understandable.
Use Zap Bot with a test server, small amounts, scoped channels and narrow wallet connections. Read the permission prompt. Read the payment state. Read the terms. If those checks feel too slow, that is exactly why they belong before money enters a busy chat.
Sources worth opening
Start with the MakePrisms Apps page, the Discord bot invite, the API page, the JavaScript-rendered docs app and its OpenAPI bundle. Then compare MakePrisms terms with NWC, NIP-47, NIP-57, Discord permissions and Lightning Address material.
- MakePrisms Apps page
- Zap Bot Discord OAuth invite
- MakePrisms API page
- Prism API docs app
- Prism API OpenAPI bundle
- $prism Nostr Zap App
- $prism create screen
- $prism zap screen
- MakePrisms Terms of Service
- MakePrisms API Terms
- MakePrisms Privacy Policy
- MakePrisms Discord bot screenshot asset
- MakePrisms prism completion screenshot asset
- getAlby awesome-nwc
- getAlby awesome-nwc raw README
- Nostr Wallet Connect site
- Nostr Wallet Connect docs
- NIP-47 raw markdown
- NIP-57 raw markdown
- NIP-01 raw markdown
- NIP-19 raw markdown
- NIP-51 raw markdown
- Lightning Address site
- LNURL LUD-06 pay request
- LNURL LUD-16 Lightning Address
- Discord permissions documentation
- Discord OAuth2 documentation
- Typefully NWC thread mentioning Prism Discord Zap Bot
- Lightning Labs Bitcoin Renaissance article
- BitcoinApps directory
- Zapper official app
- Snort web client
- Amethyst GitHub repository
