Hallo!

Theres a lot of people want to accept Monero on their websites but get discouraged by how heavy/difficult setup of most self hosted solutions are.

You usually end up having to run a dedicated server, manage a full node, and maintain extra infrastructure just to receive payments....

xmrpay was made to remove that friction :)

The idea is simple: make Monero payments easy to accept without forcing you to run a heavy self hosted instance.

Why its lighter:

• WordPress users : they can install the WooCommerce plugin and start accepting Monero directly inside their existing site. Verification runs in pure PHP!!, no Node.js, no background daemon, and no extra server process required for normal operation....
• For other platforms (Joomla, custom sites, etc.): ofc you can embed a lightweight widget. You only need a small stateless endpoint if you want automatic verification.
• You don’t have to run your own Monero node. It can work with public nodes or minimal setups. ( But please, run a Monero node :) )

The goal is to let normal site owners accept Monero without turning their setup into a full crypto infrastructure project... I wanna help to improve Monero adoption

Try it right now on stagenet (test coins):

• Widget demo: https://xmrpay.shop/demo.html
• Live demo store: https://demo.xmrpay.shop
• Configure the plugin/agent: https://live.xmrpay.shop
• Check the donation widget, it's using xmrpay: https://xmrpay.shop/index.html

Links:

• Main project: https://github.com/SlowBearDigger/xmr-pay
• WooCommerce plugin: https://github.com/SlowBearDigger/xmr-pay-woocommerce

I’m the developer. I built this because I wanted something practical that people could actually use without a big self hosted setup.

Yes, I use Claude code, but I don't rely 100% on it, mostly to deploy or things that are boring/annoying to me.

Would love some honest feedback from anyone who runs a store or has tried other Monero payment solutions.

Please be harsh, any kind of feedback is welcome

In the last couple of weeks, people have been fueling this project! and for that, many many thanks!

the XMR donations sent to the xmrpay address were put to good use:

https://x.com/SlowBearDigger/status/2072039459864879435?s=20

Disclosure: I’m the one who made the changes.

Hello!, the old official monerowhmcs repo has been broken for a while on current WHMCS versions.

money_format() got removed in PHP 8, plus some other deprecated stuff and a dead price feed, so the gateway would just fatal error when a customer tried to pay...

I went ahead and fixed it while keeping the original approach: self hosted, your own monero-wallet-rpc + daemon, integrated addresses, and either a QR or just a copiable address at checkout.

What I changed:

• Fixed PHP 8 compatibility (money_format, sanitization, null checks on database lookups)
• Switched the price feed to CoinGecko with Kraken fallback
• In one branch I replaced the old third-party QR service (api.qrserver.com) with local QR generation so the address and amount don’t get sent to an external site

Tested end to end on WHMCS 8.13.4 and 9.0.5 with PHP 8.3.

Two branches:

• fix-php8-local-qr > it has local QR generation (recommended)
• fix-php8-no-qr > only a minimal change, just copiable address, no QR

Repo: https://github.com/SlowBearDigger/monerowhmcs

Evidence and testing notes here: https://github.com/SlowBearDigger/monerowhmcs/blob/fix-php8-local-qr/docs/EVIDENCE.md

Now the real questions:

If you run WHMCS and accept Monero, would you like to have a new solution?
Would you give a try to a WHMCS version of XMRPAY? (see: https://github.com/SlowBearDigger/xmr-pay)

I already tested it myself and it works, but I’d rather have more people try it on real setups before calling it solid.

If you have WHMCS 8 or 9 and want to test it, I’d really appreciate feedback (even if it’s “broke on my setup because of X Y or Z")...

thanks!

Disclosure: I'm the creator of xmrpay.

This is the next step after the PHP engine plus theadapter guide I posted a while ago (where I said "soon for Joomla")...

Remember that xmrpay is free, open source (MIT), non custodial Monero payment verification using only your view key. without the need of monerod, no wallet-rpc 24/7, no middleman.
Funds go straight to your wallet. We already have the serverless JS library, PHP engine, WooCommerce plugin, Composer package and Laravel adapter!!

Now delivering on the Joomla promise :)

I built xmr-pay-build, it is a simple packager that generates ready to install Joomla extension packages from the canonical sources (single source of truth, no stale vendored code).

What you can get:

• One single ZIP per cart that installs both the payment method plugin and the settlement scheduler task (no separate installs needed).
• HikaShop > pkg_xmrpay_hikashop.zip (plg_hikashoppayment_xmrpay + plg_task_xmrpaysettle)
• VirtueMart > pkg_xmrpay_virtuemart.zip (plg_vmpayment_xmrpay + plg_task_xmrpaysettle_vm)

It automatically adds index.html files for directory listing protection + JED compliance, and always pulls fresh code from xmr-pay-php and xmr-pay-adapter-core.

Verified: Both packages install cleanly on Joomla 5.4.6 with HikaShop 6.5.0 and VirtueMart 4.6.4.

To get the packages: clone https://github.com/SlowBearDigger/xmr-pay-build and run ./build.sh > the ZIPs will be in dist/. Super transparent and reproducible.

Same honest trust model as the rest of xmrpay:

• View key only (can read payments, can never spend)
• Amount proven by on chain RingCT commitment (forged amounts rejected)
• Fails closed: commitment + confirmations + not time-locked + no double-count must all pass
• Refunds are manual (Monero is irreversible + sender is hidden)
• You only trust the node(s) you configure (run your own or use two for bigger amounts)

What I need from you all:

• Install and test on your real Joomla setups (different versions, other carts, etc.)
• Full flow test: configure payment method > create order > pay with Monero (start with stagenet) > check if the scheduler settles it correctly
• Feedback on the single ZIP bundling approach, is it convenient?
• Any issues with manifests, files, installation, or Joomla specific flows (tax, shipping, partial payments, multiple currencies, etc.)
• Docs are still minimal (it's mainly a build tool right now), what would actually help you?

Please be harsh. This is early. If something feels off, confusing, broken, or doesn't fit real merchant workflows, tell me. I'll fix it or document the limit.

The goal is solid, trustworthy Monero acceptance on Joomla without the usual infrastructure pain.

Links:

• Build repo: https://github.com/SlowBearDigger/xmr-pay-build
• Main xmr-pay context: https://github.com/SlowBearDigger/xmr-pay
• PHP engine + adapter writing guide (where I first mentioned Joomla): https://github.com/SlowBearDigger/xmr-pay-php

Thanks in advance, real feedback is what makes this stuff actually usable!! (Like on the wordpress plugin, thanks to feedback I was able to deliver a nice plugin for Woocommerce)

Disclosure: I’m the creator... and I know I been posting similar stuff... but listen..

Tired of running monerod + wallet-rpc 24/7 or trusting some third party gateway just to accept Monero on a PHP site? xmr-pay-php don't do like that...

PHP engine that verifies incoming payments using only your view key, pulling public chain data from any Monero node you point it at.
No monero-wallet-rpc, no daemon on your box, no backend service. It derives a per order subaddress, detects the output, verifies the RingCT amount commitment, checks confirmations and time locks, and handles the old burning bug deduping.

• WooCommerce plugin (runs in production): https://github.com/SlowBearDigger/xmr-pay-woocommerce
• The engine as Composer package: composer require slowbeardigger/xmr-pay
• Laravel adapter: composer require slowbeardigger/xmr-pay-laravel

It builds on the monero-integrations crypto primitives. Doesn’t reimplement them <3

The honest part, because you’ll find it anyway:

It only holds the view key, so it can read payments but never spend. The amount is proven by the on-chain commitment, not the ecdh value, so a forged amount gets rejected. It fails closed — commitment + confirmations + no time-lock + no double-count must all pass or the order stays unpaid. The only thing you trust is the node(s) you configure. For real money, run your own or use two so a lagging one can only delay, never falsely confirm early. Monero is irreversible and the sender is hidden, so refunds are manual.

State of it:

Fresh beta (v0.1.0). Not widely used yet outside the WooCommerce plugin. Verification logic is cross checked against the reference Monero library on real stagenet payments, and the same results come out across the JS library, the PHP package, the WooCommerce plugin, and the Laravel adapter.

There’s a short guide for writing adapters for other platforms (WHMCS, Joomla, PrestaShop, Symfony, etc.) if anyone wants to: https://github.com/SlowBearDigger/xmr-pay-php/blob/main/docs/WRITING-AN-ADAPTER.md

Feedback on the verification approach and the trust model is very welcome.

Please be harsh! try to break the checks with weird edge cases, node quirks, partial payments, whatever. If it doesn’t fit your setup or you spot something off, say it. I’ll fix it or document the limit.

Disclosure: I'm the creator of this project, and is inspired on GOXMR

After months of building, I'm releasing xmr-pay, a free, open source payment gateway for Monero that requires no backend infrastructure (serverless), holds zero funds (non custodial), and is completely transparent.

What is it?

A lightweight JavaScript library + widget that lets merchants accept Monero payments with proof verification instead of key custody. Two modes:

1. Tx-proof mode: buyers submit proof of payment; merchant verifies serverless (tx proof verification only, no Monero wallet)
2. Watch-mode: merchant optionally runs their own monero-wallet-rpc to auto detect subaddress payments

No accounts, no API keys, no middleman holding your keys. Merchants control their own address and run verification on their own infrastructure... and I think is nice...

The real thing:

• v0.1.6 live on npm &gt; u/xmr-pay package
• Open repo &gt; github.com/SlowBearDigger/xmr-pay (MIT licensed)
• Mainnet verified &gt; tested on real XMR transactions
• 41 test cases &gt; offline config/watch/uri parsing + 15 live stagenet validations
• Zero dependencies in core &gt; monero-ts only loads when verifying
• Widget is 73KB &gt; single file, no CDN calls, system fonts, pure CSS

What I need from you:

I'm looking for real feedback, not hype. This is genuinely free and open source:

• Can you break it? Try the tx proof path with edge cases (large amounts, old UTXOs, locked outputs)
• Does the verify flow work for your use case? (serverless endpoint, webhook signature, quorum nodes)
• Mobile UX? Widget tested at 375×812; does proof pasting work on your phone?
• Missing wallets? I documented Feather, GUI, CLI, Cake, Monerujo — did I miss your flow?
• Doc gaps? DEPLOY.md covers Vercel/Express; where does your setup differ?
• What's wrong? Anything confusing, broken, or overhyped?

Links:

• GitHub: https://github.com/SlowBearDigger/xmr-pay
• npm: npm install u/xmr-pay
• Docs: README + DEPLOY.md + WALLETS.md + SECURITY.md
• Examples: serverless endpoint + demo server + pay-links

The honest part:

• No inflation: real XMR amounts in piconeros, no pretending things work that don't
• No account BS: literally zero accounts to create
• Threat model documented: what I protect (tx proof verification), what you protect (your order DB + webhook secrets)
• Security audited: found and fixed unlock-time scams, replay bugs, quorum logic; documented the footguns you must handle...

Please be harsh. If this doesn't fit your workflow, or if you found a real bug, say it. I'll fix it or document the limit.

I coded this, took me a while, I been use Claude code for testing and tedious stuff (UI/UX I took from GOXMR, so Claude did the boring/annoying part)