XMR-PAY

A drop-in, non-custodial Monero payment library — install via npm, drop a `<xmr-pay>` web component into a checkout page, and accept XMR directly to your own wallet without routing through a third-party processor. Listed at Grade C because the tool works on mainnet today (live demo at xmrpay.shop) and the operator (SlowBearDigger) has prior credibility from shipping [goxmr.click](/tools/goxmr) at Grade B in this directory — but the project itself is Beta 0.1.0, the GitHub repo and npm package metadata aren't fully indexable yet, there's no documentation beyond the landing page, and zero community discussion has accumulated. C is the new-developer-tool floor; the architecture earns more, the track record doesn't yet support it.

What it is. A client-side, non-custodial Monero payment toolkit for developers and merchants. Three components: (a) a zero-dependency web component (`npm i xmr-pay`) that renders a payment QR plus URI plus live status indicator on any HTML page; (b) stateless transaction-proof verification — a Monero tx-proof check that runs on-chain with no keys, no database, and no third-party API; (c) a view-only watch agent that assigns subaddresses per order and auto-detects on-chain payment. A WooCommerce plugin (Beta) wraps the above for WordPress stores. The entire payment path runs on the merchant's own infrastructure with funds going directly to the merchant's wallet — there is no operator-held balance and no centralised checkout server (the library has no operator at runtime — the developer ships releases, but nothing in the payment path goes through them).

Background. Built by SlowBearDigger — a solo developer who also ships [goxmr.click](/tools/goxmr) (privacy-first Monero link-in-bio tool, listed in this directory at Grade B). Same handle across both projects; the same X account (`@SlowBearDigger`) and GitHub org publish releases for each. Solo-dev shipping is the norm in the Monero tools ecosystem (a category that grew up around solo, pseudonymous developers), so the structure isn't a risk axis on its own — it's standard for the category and the bar both projects have already cleared once. The site at `xmrpay.shop` is a single-page landing that doubles as documentation and as a live mainnet coffee-tipping demo. The companion WooCommerce plugin is published at `github.com/SlowBearDigger/xmr-pay-woocommerce` as a downloadable `.zip`. Project itself versioned at 0.1.0 Beta as of 2026-06-17 — early-stage by the operator's own framing. Listed on monerica; no kycnot listing (kycnot scopes are wider than dev-tools, so absence here is mostly category-fit, not a negative signal).

What you trust.

• Non-custodial by architecture, not by promise. "Funds go straight to your address — no third party in the payment path." The npm library has no hosted service to compromise; funds settle to whatever Monero address you pass to the web component. There is no operator-held balance, no escrow, and no shared backend that could be seized or fail.
• Stateless proof verification — trust the math, not the operator. The library ships a tx-proof check that runs against the on-chain block data with no view-key, no wallet RPC, and no database. Merchants can confirm a payment cryptographically without trusting the library author or hosting any state about past payments.
• Live mainnet demo functions. The homepage hosts a real coffee-tipping demo on Monero mainnet — funds go to a live wallet, the watch agent detects the payment, the status indicator flips. Working code beats README claims; the demo is the strongest single signal on the listing.
• Solo-dev credibility via [goxmr.click](/tools/goxmr). SlowBearDigger ships under a consistent pseudonymous handle in the Monero privacy-tools space. goxmr.click is independently graded at B in this directory with a clean privacy posture (GDPR-aligned, no IP logs, HMAC-SHA256, bcrypt). Same dev shipping a second tool under the same name inherits the credibility floor — not the grade itself, which still depends on this project's own track record.
• monerica listing. Project is listed on monerica.com — at least one peer-directory has reviewed and indexed it.
• Open source. Source published on the operator's GitHub org. Anyone can audit the proof-verification logic; nobody depends on a centralised server staying up for the tool to keep working.

Operational specs.

• Site. https://xmrpay.shop — single-page landing + live demo (~24 KB).
• Install. `npm i xmr-pay` — published on the npm registry.
• Integration surface. Web component: `<xmr-pay address="4..." amount="0.05"></xmr-pay>`. That's the entire merchant-side install.
• Modules. Drop-in checkout widget · stateless tx-proof verification · view-only watch agent for subaddress assignment + payment detection.
• WooCommerce plugin. Beta `.zip` at `github.com/SlowBearDigger/xmr-pay-woocommerce`; routes payments directly to the merchant's Monero wallet.
• Version. 0.1.0 Beta (operator-flagged as Beta on the homepage).
• License. Open-source per operator GitHub org.
• No hosted service. No accounts, no API keys, no rate limits, no upstream operator who can suspend you.
• No data retention. Nothing to retain — the library doesn't see PII, doesn't store IPs, doesn't collect telemetry. Architecturally guaranteed, not a policy claim.
• No fees. XMR-PAY itself charges nothing. Merchants pay their own Monero network fees on settlement.
• Channels. X `@SlowBearDigger`, GitHub. No Matrix, Signal, SimpleX, or PGP key advertised.

Operator philosophy. Positioned as infrastructure for Monero sovereignty: *"Sovereign Monero payments. Accept Monero. Non-custodial."* The architectural choice — an npm library + web component rather than a SaaS platform — is the philosophy in code: merchants own their payment flow end-to-end, the library is stateless, there is no centralised operator to whom merchants delegate trust. This is the explicit opposite of BitPay / NOWPayments / Coinbase-Commerce style payment processors. The operator chose to ship a tool, not a service — meaning grades and incidents on the directory's usual axes (KYC, AML, reserves, custodial risk) don't apply in the conventional sense. What applies is code quality, operator track record, and integration adoption — and those are the axes the C-floor grade reflects.

Grade rationale. Listed at Grade C because it's a Beta 0.1.0 developer tool published recently with no merchant adoption signals on the public record yet — but the architecture is strong and the operator has a track record. The directory's tenure-in-grading rule normally defaults new operators to C in high-loss-asymmetric categories; for developer tools the loss model is different (a buggy widget makes you LOSE a sale, not gain a thief's wallet), and the same solo dev's goxmr.click sits at B in this directory. So C is what's earned by the *project's* age and adoption — not by the operator's credibility. Path to B: versioned releases past 0.1.x; documented WooCommerce-version + WordPress-version compatibility matrix; at least one third-party merchant publicly using it in production; a README / integration guide at the repo level beyond the landing page; ideally a security review of the proof-verification module from an independent reviewer. Path to A: all of the above plus a year of incident-free operation on real-merchant volume.

Useful when.

• You're a developer building a Monero-accepting website and you want a drop-in web component that generates a payment QR without depending on a third-party API. `<xmr-pay address="4..." amount="0.05"></xmr-pay>` is the entire integration.
• You run a WooCommerce store and want to accept Monero non-custodially — the Beta plugin routes payments directly to your wallet and runs detection on your own agent.
• You want to verify Monero tx-proofs cryptographically without running a wallet-RPC — the stateless verification module checks proofs on-chain with no keys or database.
• You've reviewed [goxmr.click](/tools/goxmr) and trust SlowBearDigger's track record enough to adopt a Beta tool from the same developer.
• You explicitly want a tool, not a service — no operator can suspend your account or seize your funds because there's no operator in the runtime path.

Caveats.

• Beta 0.1.0 — early-stage software handling real payments. Operator framing is explicit. Test thoroughly on testnet or with small mainnet amounts before deploying to a production store.
• No README / API reference / integration guide beyond the landing page. The homepage shows the integration surface but a full documentation set is not yet published. Adopters self-document by reading the source.
• WooCommerce plugin is Beta. Distributed as a downloadable `.zip` with no documented WooCommerce / WordPress compatibility matrix or known-issues list. Beta-stage handling real payments needs its own staging round.
• Zero merchant adoption signals on the public record. No third-party stores have publicly disclosed using it; npm download stats and GitHub fork/star counts aren't fully indexable yet. The architecture is sound but real-merchant volume is the only thing that confirms the integration model holds up under traffic.
• Single-source peer-dir trust signal. Monerica only. No kycnot listing (mostly a category-fit issue — kycnot doesn't review dev tools), but it does mean we're not triangulating across multiple directories.
• No published security review. Proof-verification code is the security-critical piece. A merchant relying on it for payment confirmation is trusting that the math is implemented correctly. An independent review hasn't been published.
• No Tor mirror. The landing page is clearnet-only; merchants integrating the npm package don't need Tor for the library itself, but a Tor mirror of the landing/documentation would help users browsing from Tor-only environments.