MoneroPay is an open-source daemon that turns a monero-wallet-rpc instance into a REST API for receiving and tracking XMR payments. This review covers its features, setup, and privacy trade-offs.
MoneroPay functions as a standalone GPL-3.0 daemon that provides a simple HTTP REST API for receiving, sending, and tracking Monero payments. It runs on top of a user-controlled monero-wallet-rpc instance and adds optional HTTP callbacks to notify external systems when payment status changes.
The project lists its primary repository on GitLab with a mirror on GitHub, where it holds 173 stars as of October 2026. Official documentation lives at moneropay.eu. Because the service exposes only an API layer, it requires a separate Monero daemon connection and works with either remote nodes or local instances.
MoneroPay is explicitly not an e-commerce plugin. It operates as a general-purpose HTTP service that any custom script, donation page, ATM interface, or paid-service backend can call directly. All amounts move in atomic units, subaddresses handle individual payments, and the daemon supports both PostgreSQL and SQLite3 for storage while allowing view-only or hot-wallet configurations.
MoneroPay supports subaddresses for each payment request, partial payments that credit once the threshold is reached, and either view-only or hot wallets for different risk profiles. It handles timelocks natively, stores data in PostgreSQL or SQLite3, and offers an optional 0-conf mode that triggers three separate callbacks for 0-conf, 1-conf and unlock events. HTTP callbacks notify external systems of status changes without polling, and all amounts are expressed in atomic units.
The project has shipped three notable point releases that each added targeted operational improvements. The table below summarises the exact changes and release dates drawn from the official changelog.
| Version | Date | Key Additions |
|---|---|---|
| v2.6.0 | 2024-10-27 | Optional 0-conf support with three callbacks; configurable payment check interval |
| v2.7.0 | 2024-11-24 | Wallet auto-creation feature; DELETE /receive/{address} endpoint |
| v2.8.1 | 2025-11-24 | Fix for dependency bug in go-monero library |
An intermediate v2.8.0 release on 2025-09-11 further improved 0-conf handling by returning mempool transactions when the mode is enabled. These incremental updates have kept the daemon stable while expanding flexibility for self-hosted deployments that require fine-grained confirmation logic or simpler wallet lifecycle management. No usage fees apply to the self-hosted software itself.
MoneroPay runs as a standalone daemon that must connect to both a Monero daemon and a user-controlled monero-wallet-rpc instance. Remote nodes are supported for the daemon, but the wallet RPC must remain under the operator’s direct control because it handles all address generation and transaction signing.
The service stores payment state in either PostgreSQL or SQLite3. SQLite3 suits single-instance testing while PostgreSQL is recommended for production or multi-instance deployments. No other database backends are documented.
The official installation path uses Docker Compose. The repository supplies a compose file that brings up MoneroPay alongside monero-wallet-rpc and a PostgreSQL container, exposing the REST API on the host network or behind a reverse proxy. Operators edit environment variables for RPC endpoints, database credentials and the poll frequency before starting the stack.
Incoming-payment checks default to a 5-second interval and are adjustable with the --poll-frequency flag. Shorter intervals increase daemon load; longer ones delay callback delivery. All configuration is passed at startup; there is no runtime configuration API.
Because the service is intended for local-network or reverse-proxied use, operators must ensure the wallet RPC is not reachable from the public internet and that TLS terminates at the reverse proxy when callbacks are enabled.
MoneroPay exposes a REST API that developers call to create receive addresses, query payment status, and initiate outgoing transfers. All amounts passed to or returned by these endpoints must be expressed in atomic units (piconero), eliminating floating-point handling on the client side.
Receive creation typically returns a fresh subaddress together with an identifier that later endpoints reference. Status checks can be performed by polling the relevant endpoint or by registering an HTTP callback URL; when 0-conf mode is active the service fires three distinct callbacks covering mempool arrival, first confirmation, and unlock. The same callback mechanism supports custom scripts that need immediate notification without constant polling.
Outgoing sends are submitted through a dedicated send endpoint that accepts destination addresses and amounts in atomic units. Version 2.7.0 added the DELETE /receive/{address} endpoint, allowing integrators to cancel an unused receive address and free the associated database record without waiting for expiry.
Common integration patterns include embedding the create-receive call inside an e-commerce checkout flow, wiring callbacks to update order databases, and using the send endpoint for automated withdrawals or refunds. Because the service sits in front of monero-wallet-rpc, any application already comfortable with HTTP requests can treat MoneroPay as a thin payment layer without managing wallet RPC details directly.
MoneroPay inherits Monero’s base privacy model but introduces operational exposure points that require deliberate hardening. The service connects to a Monero daemon and can use remote nodes; any clearnet remote node reveals the operator’s IP to that node operator and potentially to observers of the node’s traffic.
Optional HTTP callbacks for payment status send requests from the MoneroPay instance to merchant endpoints. If the callback target is reachable only over clearnet, the destination server logs the originating IP address of the MoneroPay host. Reverse-proxy misconfiguration can leak the internal wallet-rpc port or allow unauthenticated access to the REST API.
KYC on-ramps remain the most direct link between an XMR balance and an identity; once funds enter a KYC-controlled exchange, the subsequent on-chain history can be correlated regardless of MoneroPay’s use of subaddresses.
Concrete steps include running monero-wallet-rpc and MoneroPay on an isolated local network, terminating TLS at a properly configured reverse proxy that also enforces IP allow-lists or authentication, and routing daemon traffic through Tor or a trusted VPN. Callbacks should target onion or authenticated HTTPS endpoints. Use view-only wallets for monitoring where hot signing is unnecessary. These measures reduce but do not eliminate linkage risks; operators must still assess their threat model against the remaining metadata surfaces.
Yes. Version 2.7.0 added wallet auto-creation, so the service can generate a new wallet file and connect it to monero-wallet-rpc without manual intervention.
Optional 0-conf mode, added in v2.6.0 and improved in v2.8.0, returns mempool transactions when enabled and fires separate callbacks for 0-conf, 1-conf, and unlock states. Reliability still depends on your node policy and network conditions.
SQLite3 works for single-instance or low-traffic setups. PostgreSQL is recommended for concurrent access, replication, or production deployments that need better concurrency and backup tooling.
You must keep the Monero daemon, monero-wallet-rpc, and MoneroPay itself updated. Database backups, log rotation, and monitoring the poll process are the main recurring tasks; no usage fees apply.
The default poll interval is 5 seconds and is configurable via the --poll-frequency flag.
Yes. Every amount field in the REST API uses piconero (atomic units), so integrators must convert to XMR themselves.
