NWC Tester (Advanced)
The live page is titled NWC Tester, while ecosystem lists usually call it the advanced tester to distinguish it from Alby's smaller simple tester. It is useful for debugging NWC behavior, but it should only see disposable, low-value, narrow-permission wallet connections.
Start with the actual object
NWC Tester (Advanced) is not a wallet, not an account dashboard and not a general Nostr client. It is a browser workbench for a very specific job: paste a Nostr Wallet Connect URI and ask the connected wallet service which methods it supports, whether it responds, and how it behaves when real NIP-47 commands are sent.
The live page itself is titled simply NWC Tester. The advanced label comes from the surrounding ecosystem, where it needs to be separated from NWC Tester (Simple), the smaller Alby page that runs only a few calls. Super Testnet's version exposes a wider method surface: string validation, permission inspection, invoice creation, invoice lookup, payment request, balance reading and filtered transaction listing.
The public repository is `supertestnet/nwc_tester`. GitHub metadata checked on June 15, 2026 showed a small HTML-only project created in October 2024, last pushed in April 2025, licensed CC0-1.0, with no formal releases. The repository description says the tool is for testing NWC strings and identifying what they are and, more importantly, what they can do.
That phrase is the article's center of gravity. This page is not mainly about whether a string looks valid. It is about what authority the string carries. A NWC connection can be harmless enough to read public-ish wallet info, or powerful enough to spend from a wallet within configured limits. The tester helps reveal that difference.
What the page presents to you
The interface is plain on purpose. It is a stack of bordered panels with labels, inputs, submit buttons and monospace status output. There is no account creation, no styling system, no saved history and no onboarding flow. You enter a NWC string repeatedly in the panels you want to test.
The first panel checks the NWC string. The second checks permissions. The next panels create a Lightning invoice, check an existing invoice, request payment of an invoice, read the wallet balance and list transactions. The transaction panel accepts optional `from`, `to`, `limit`, `offset`, unpaid/included-settlement choice and incoming/outgoing type filters.
Those panels are not abstractions invented by the website. They map closely to NIP-47 and NWC reference methods. `get_info` answers capability questions. `make_invoice` asks the wallet to create an invoice. `lookup_invoice` or invoice lookup behavior asks about payment state. `pay_invoice` is the dangerous outgoing side. `get_balance` and `list_transactions` expose wallet state.
The design tells you something about the intended reader. This is a tool for a builder, tester, support person or wallet developer who already has a NWC string and wants to isolate wallet-service behavior from their own product code.
What the source code confirms
The raw `index.html` is small enough to read without a build step. It imports `https://supertestnet.github.io/nwcjs/nwcjs.js`, `noble-secp256k1@1.2.14` and `bech32@2.0.0` from public browser URLs. There is no framework layer hiding the method calls.
The string checker first runs `nwcjs.processNWCstring`. It verifies that the wallet pubkey and app private key look like valid hex, checks that the relay starts with `wss://` unless the user knowingly uses `ws://` for local testing, signs a simple event with the app private key, sends it to the relay, waits briefly and then asks the relay for the event it just sent.
That is a useful relay sanity check, but it is not a perfect relay audit. A paid relay, authenticated relay, temporary relay or relay with unusual policy may fail that simple round trip while still being valid for the wallet service's actual workflow. Conversely, a relay that echoes the test event can still be a poor choice for production if it drops NWC ephemeral traffic or has bad availability.
The permission checker calls `nwcjs.getInfo` and prints the wallet service's returned methods. The invoice panel calls `nwcjs.makeInvoice`. The invoice-status panel calls `nwcjs.checkInvoice`. The payment panel calls `nwcjs.tryToPayInvoice`. The balance and transaction panels call `nwcjs.getBalance` and `nwcjs.listTransactions`. This is why the page deserves the advanced label: it covers enough of the wallet API to show real behavior.
Why get info is the first serious test
If you are using the page safely, `get_info` should be the first real protocol call after basic string validation. It asks the wallet service what it supports, and the NWC docs describe the response as wallet account information plus a list of supported methods for that connection.
That matters because NWC is not one universal permission blob. One wallet connection may allow `get_info` and `make_invoice` only. Another may allow `pay_invoice`, `get_balance` and `list_transactions`. Another may advertise notifications. Your app should adapt to the methods on the connection instead of assuming every wallet behaves like the one you used during development.
For a reader, the practical value is simple. If the tester says the connection does not support the method your product needs, the next action is not to rewrite your app. It is to open the wallet service and check the permission settings, wallet backend and relay configuration. A failed method can be a settings problem rather than a protocol problem.
This is also where internal vocabulary matters. The page says permissions, while NIP-47 and the NWC docs often talk about methods and capabilities. In real use, both views meet: the wallet service exposes methods, and the wallet or user decides which methods a particular connection may use.
Invoice creation is more than a receive button
The `make_invoice` panel looks harmless because receiving is less scary than sending. Still, it tests a surprisingly long chain. The connection string must parse, the relay must be reachable, the request must be signed and encrypted correctly, the wallet service must decrypt it, the backend must create a Lightning invoice, and the response must return before the tester's delay tolerance expires.
The page asks for an invoice amount and description. In the source, it converts the input to a number, rejects an empty amount, then calls `nwcjs.makeInvoice` with a six-second delay tolerance. When the response succeeds, it prints the invoice or BOLT-11 value and the full result object.
The 2025 update added notification listening around this flow. After making an invoice, the page records the payment hash and creation time, then polls the relay for notification events from the wallet pubkey addressed to the app pubkey. It tries to decrypt them and watches for a `payment_received` notification matching the payment hash.
That makes the test more helpful when debugging a wallet that claims notification support. But it also means a failed notification test may be a notification issue, a relay-retention issue, a timing issue, an encryption issue or simply an unpaid invoice. The tool gives a clue; it does not give a final verdict by itself.
Payment testing is the sharp edge
The `pay_invoice` panel is the reason this page should never receive a broad main-wallet secret casually. If the pasted NWC connection can pay invoices, the tester can send an outgoing payment request. A user who treats the URI like a harmless API token has already misunderstood the risk.
The code deliberately uses `nwcjs.tryToPayInvoice`, a method from nwcjs that sends the payment request without waiting forever for Lightning settlement. After submitting the request, the page listens for `payment_sent` notifications for up to 60 seconds and compares notification data with the invoice you entered.
That behavior is useful for developers because Lightning payments can be pending, slow or route-failed. A page that waits indefinitely would be a bad tester. A page that sends the request and separately watches for notification events reflects the messy reality of payment flows better.
But from a reader's point of view, the safe procedure is strict. Use an amount-limited test connection, preferably with only a few sats available. Use an invoice you control. Verify the wallet's budget and approval settings before pressing Submit. Revoke the connection afterward if it was created only for this test.
Balance and transaction history are privacy tests
`get_balance` and `list_transactions` do not spend money, but they can still leak sensitive information. A wallet balance can reveal whether an account is worth targeting. A transaction list can reveal amounts, timing, descriptions, payment hashes, settlement state and usage patterns.
The balance panel converts the returned millisatoshi balance into satoshis for readability, while still printing the full response. The transaction panel lets you filter by time range, result limit, offset, unpaid status and incoming or outgoing type. Those filters match useful debugging questions: did the wallet see this invoice, did it settle, did the outgoing payment appear, and is the wallet returning the expected order?
For a builder, this is valuable when testing dashboards, receipts, accounting views or settlement monitors. For an ordinary user, it is another reminder that NWC permissions are not all equivalent. A connection that can list transactions deserves user-facing explanation and a real reason.
If you need to share tester output in a support issue, redact it. Do not paste a full transaction array into a public chat unless it came from a disposable wallet. The page is a debugging tool, not a privacy scrubber.
How it sits beside the simple tester
The advanced tester and NWC Tester (Simple) are best understood as two different diagnostic tools. The simple tester is a compact Alby-hosted page that runs a few SDK-backed calls quickly. The Super Testnet tester is more method-oriented and makes separate operations visible one by one.
Use the simple tester when you need a fast pulse check: does this secret return info, create a small invoice or show a recent transaction list through that page's SDK path? Use the advanced tester when you need to inspect permissions, try invoice lookup, test outgoing payment behavior or watch notification handling.
The advanced tester is also closer to Super Testnet's own ecosystem. The repository points users without a NWC string to Bankify, another Super Testnet project that turns a Cashu mint into a NWC-capable Lightning wallet for experiments. The tester also depends on Super Testnet's `nwcjs` browser library.
That lineage matters for expectations. This is an experimental builder tool, published in the open, with readable source. It is not a polished commercial support console. Its strength is that you can see what it is doing. Its limit is that you must bring your own operational caution.
Bankify is a useful but risky companion
The NWC Tester README sends people who lack a NWC string to Bankify. That is reasonable for experiments because Bankify can create a NWC connection from a Cashu mint and expose NWC-like wallet behavior without requiring the user to already operate a full Lightning node or wallet service.
The Bankify README is also unusually candid about danger. It says the web app stores private keys and ecash notes unencrypted in localStorage, is for testing and demonstrations, and should not receive money you are not happy to lose. It also explains that the web app's NWC connection lives in the browser tab, so closing the tab stops the wallet service behavior.
That warning should travel with the tester. A demo wallet is useful precisely because it is disposable. It gives you a realistic NWC string to paste into the advanced tester without risking a real wallet account. If it fails, you learned something about the test stack. If it succeeds, you learned how the methods behave.
Do not mistake a Bankify-plus-tester success for production readiness. Bankify is a learning and experimentation bridge. The tester is a workbench. Production apps still need durable wallet services, revocation, budgets, error handling, support paths, logging hygiene and clear user consent.
Relays are part of the result
NWC rides over Nostr relays. The relay forwards encrypted request, response and notification events between client and wallet service. The relay does not need to read the wallet command, but it still affects timing, delivery, filtering, retention and availability.
The tester's string check sends a simple event to the relay and asks whether it can fetch it back. That is a practical first probe. If the relay is down, misconfigured or unreachable from your browser, the connection will not behave well no matter how correct the wallet service is.
Still, do not overread the relay test. NIP-47 traffic has its own event kinds and timing expectations. A relay that handles a basic kind-1 echo may still drop or refuse wallet traffic. A relay behind authentication may reject the tester's simple probe while still working for an approved wallet service. A relay that does not retain events long enough can break notification debugging.
When a test fails, record the relay URL along with the wallet service and method. Good NWC debugging is not just wallet-versus-app. It is app, wallet service, relay, method, encryption, permission and timing.
Encryption details matter, but do not save bad hygiene
NIP-47 describes end-to-end encrypted request and response events between a client and wallet service. Current NIP-47 text includes NIP-44 v2 encryption support and a compatibility path for older NIP-04 assumptions. The page's notification code decrypts events with `nwcjs.decrypt`, which is why the imported cryptographic libraries and protocol compatibility matter.
The useful reader takeaway is not that you should audit every primitive before using the tester. It is that encrypted content does not make the NWC URI safe to paste everywhere. The URI still grants the app-side authority for that connection. If a page, extension or log captures it, the encryption scheme does not magically revoke the permission.
NIP-44 also documents limitations such as metadata exposure through relays and event structure. In NWC, relays may not see command contents, but they can still see event kinds, timing, participants and relay-level network information. Wallet privacy is a system property, not a single encryption checkbox.
So the safe posture is layered. Use `wss://` relays, narrow permissions, per-app connections, budget limits, short-lived test secrets, clean browser profiles and revocation. The tester can help you inspect the connection; it cannot protect a secret once you hand it to the wrong environment.
What a good test session looks like
Start by creating a fresh test connection in the wallet service. Give it a name that identifies the test. Allow only the method you need, or a very small set of methods. If outgoing payments are required, set a tiny budget and use a wallet balance that can be lost without consequence.
Open the tester directly from `supertestnet.github.io/nwc_tester/`. Do not use a shared URL that already contains a secret. Paste the NWC string into the string-check panel first. If that passes, run permissions. Then run only the method you actually need to debug.
When the page prints a result, copy the method, wallet service, relay, returned error code or result shape, and rough response time into your notes. Do not copy the NWC URI. Do not copy full invoices, payment hashes or transaction arrays unless they are from a disposable wallet and are necessary for the issue.
After the test, revoke the connection or leave it disabled. If the result influences product behavior, reproduce it with your own minimal script or a second tool. One browser page can diagnose a layer; it should not be the only evidence behind a shipping payment integration.
How developers should read failures
A failure in the advanced tester is not automatically a failure in NWC. It might be an expired URI, wrong relay, wallet service offline, unsupported method, missing permission, budget limit, insufficient balance, older encryption expectation, notification timing issue, browser extension interference or CDN/library loading problem.
The NWC docs list standard error families such as rate limiting, not implemented methods, insufficient balance, quota exceeded, restricted public keys, unauthorized connections, internal wallet failures and other errors. If the tester prints a structured error, keep that error instead of reducing the outcome to works or broken.
For payment failures, remember that Lightning can fail for routing and liquidity reasons even when the NWC layer worked. The page's `tryToPayInvoice` behavior is deliberately asynchronous because a Lightning payment may not settle immediately. A missing `payment_sent` notification within 60 seconds is a useful symptom, not the entire story.
The debugging order should be boring: validate string, inspect methods, test relay, test harmless method, test invoice creation, test balance or transactions only if needed, test payment last. That order protects funds and gives clearer evidence.
Where it belongs in a product stack
NWC Tester (Advanced) belongs in Developer Tools & Libraries because it is a diagnostic surface for the NWC layer. It helps app builders, wallet-service maintainers and support people verify what a connection can do without opening the full product under test.
It sits near NWC HTTP API, Alby JavaScript SDK, nwcjs, NIP-47 and relay tooling rather than near social clients. It is infrastructure-adjacent, not user-facing social software.
A product team might use it during onboarding docs, support reproduction, wallet compatibility testing, permission design and NWC wallet-service comparisons. A wallet team might use it to check whether `get_info`, invoice, payment and notification behavior matches expectations after a release.
A normal user should only encounter it if they are debugging with someone they trust or learning NWC deliberately. If a product requires ordinary users to paste broad wallet secrets into a tester as part of routine use, the product has pushed too much developer burden onto the user.
Useful Nostr context
If this page is your first encounter with NWC, start with NIP-47 and Nostr Wallet Connect before treating any tester result as obvious. The protocol exists so apps can ask wallet services for Lightning actions without each app holding custody of funds.
If you want a smaller comparison point, read NWC Tester (Simple). If you want the JavaScript library path behind this tester, read nwcjs. If you are building a production app rather than testing manually, compare Alby JS SDK and NWC HTTP API.
If you need a disposable wallet-service string for experiments, Bankify is relevant, but only with its own warnings in mind. If your failures look like delivery problems, step sideways into relay context and check whether the relay layer is part of the issue.
The practical close
NWC Tester (Advanced) earns its place because it turns an opaque NWC URI into visible behavior. It can tell you whether a relay responds, which methods a wallet service advertises, whether invoice and payment calls travel correctly, and whether balance or transaction calls return the shape your app expects.
Its value is also its risk. The page does real method calls from a browser. If the connection can spend, the tester can request spending. If the connection can reveal history, the tester can reveal history. If the connection is broad, old or not revoked, the test leaves a live credential behind.
Use it like a sharp bench tool: deliberately, briefly and with disposable material. Read the source, choose narrow permissions, prefer test wallets, keep notes, redact outputs and revoke secrets. Then move from the tester to your own integration with clearer evidence and fewer assumptions.
Sources worth opening
Open the live page, raw HTML and repository metadata first, then compare NIP-47, the NWC docs, nwcjs and Bankify so the tester's method buttons are understood as protocol calls with wallet-permission consequences.
- NWC Tester Advanced live page
- NWC Tester Advanced GitHub repository
- NWC Tester Advanced raw HTML
- NWC Tester Advanced README
- NWC Tester Advanced repository metadata
- NWC Tester Advanced contents API
- NWC Tester Advanced commits API
- NWC Tester Advanced repository license
- nwcjs GitHub repository
- nwcjs raw README
- nwcjs browser library
- Bankify live page
- Bankify GitHub repository
- Bankify raw README
- awesome-nwc raw README
- Nostr Wallet Connect homepage
- NWC docs welcome page
- NWC SDKs and Tools docs
- NWC app best practices docs
- NWC wallet best practices docs
- NWC reference overview
- NWC get_info reference
- NWC get_balance reference
- NWC make_invoice reference
- NWC pay_invoice reference
- NWC lookup_invoice reference
- NWC list_transactions reference
- NWC error codes
- NIP-47 raw specification
- NIP-44 raw specification
- NIP-04 raw specification
- NIP-01 raw specification
- NWC Faucet
- Alby JavaScript SDK repository
- Alby NWC JS SDK guide
- Breez SDK Liquid NWC guide
