● articles / Marchand — POS
MoneroPay et AcceptXMR : intégrer XMR dans ton propre logiciel
· MoneroPay · AcceptXMR · intégration · API · Rust · Go
Si tu écris ton propre logiciel (SaaS, app mobile, plateforme custom, donation widget) et tu veux y intégrer Monero proprement, deux outils sérieux existent : MoneroPay (daemon Go, API HTTP, intégration langage-agnostique) et AcceptXMR (librairie Rust, intégration in-process pour apps Rust). Tous les deux sont open-source, non-custodial, view-only based. Voici comment choisir et le pattern d’intégration.
TL;DR
| Critère | MoneroPay | AcceptXMR |
|---|---|---|
| Langage | Go (daemon) | Rust (lib) |
| Intégration | API HTTP REST | In-process Rust |
| Setup | Daemon séparé + ton app | Lib intégrée à ton app Rust |
| Cas usage | App n’importe quel langage | App Rust uniquement |
| Custody | Non-custodial (view-only) | Non-custodial (view-only) |
| Persistence | Configurable | Persistente, recovery sur crash/power loss |
| Repo | github.com/moneropay/moneropay | github.com/busyboredom/acceptxmr |
Choisis MoneroPay si : tu écris en Python, Node, PHP, Ruby, Java, ou tout autre langage, et tu veux une API REST simple à appeler depuis ton code.
Choisis AcceptXMR si : ton app est en Rust et tu veux la lib embarquée pour éviter un process externe.
MoneroPay (daemon Go)
github.com/moneropay/moneropay — standalone payment processor for incoming and outgoing transactions.
Architecture :
┌────────────────┐
│ Ton app │
│ (n'importe │
│ quel lang) │
└───────┬────────┘
│ HTTP REST
▼
┌────────────────┐
│ MoneroPay │
│ daemon (Go) │
│ ├─ view key │
│ ├─ subaddress │
│ │ manager │
│ └─ webhooks │
└───────┬────────┘
│ RPC
▼
┌────────────────┐
│ monero-wallet │
│ -rpc │
└────────────────┘
│
blockchain
Forces :
- API HTTP simple :
POST /receivepour générer une nouvelle invoice (= subaddress + montant attendu),GET /receive/<id>pour voir le statut,POST /transferpour envoyer (si tu lui donnes la spend key, sinon view-only seul). - Webhooks : MoneroPay POST sur ton endpoint quand un paiement est confirmé. Ton app n’a pas à poller.
- Langage-agnostique : tu intègres en 30 lignes de Python/Node/PHP/Ruby.
- Daemon stable : tourne en service systemd, recovery sur crash, gestion des reconnexions au wallet RPC.
- Mode view-only : tu peux le configurer pour qu’il ne fasse que recevoir, sans avoir la spend key.
- Mode full wallet : si tu veux qu’il puisse aussi envoyer (ex: payouts automatiques), tu lui donnes la spend key — mais à n’utiliser que sur un serveur fortement sécurisé, pas sur n’importe quel VPS.
Faiblesses :
- Process séparé à maintenir (systemd service, restart policy, monitoring).
- Latence HTTP (négligeable en pratique, mais à connaître pour des cas latency-critical).
- Sécurité de l’endpoint REST : à protéger via firewall, mTLS, ou bind localhost only.
Cas d’usage typiques :
- API SaaS qui facture en XMR.
- Site donation custom.
- Marketplace P2P avec gestion de paiements multiples.
- Bot Telegram / Discord avec paiements.
- App mobile dont le backend gère les paiements XMR.
AcceptXMR (librairie Rust)
github.com/busyboredom/acceptxmr — a slim & performant library for use in Rust applications.
Architecture :
┌─────────────────────────────────┐
│ Ton app Rust │
│ ├─ AcceptXMR lib (in-process) │
│ │ ├─ view key │
│ │ ├─ scanner │
│ │ └─ invoice store │
│ └─ ton code business │
└───────┬─────────────────────────┘
│ direct RPC
▼
┌────────────────┐
│ monero-daemon │
│ (node) │
└────────────────┘
Forces :
- Lib intégrée : pas de process séparé à gérer, pas de HTTP overhead, code Rust idiomatique.
- Non-custodial strict : ne nécessite que la view key + adresse principale — pas de hot wallet, pas de spend key.
- Persistence des invoices : recovery sur crash ou coupure de courant. Si le serveur reboot pendant qu’une invoice est en cours, AcceptXMR retrouve son état au redémarrage.
- Slim : peu de dépendances, peu de RAM, idéal pour edge computing ou raspberry Pi.
- Génère subaddresses depuis ta primary address + view key — privacy intacte.
Faiblesses :
- Rust uniquement. Si ton app est en Python ou Node, AcceptXMR n’est pas pour toi (utilise MoneroPay).
- Pas de “send” : si tu veux envoyer (payouts), tu dois passer par un autre outil/wallet pour la spend.
- Maintenance liée à
busyboredom(un seul maintainer principal en 2026, projet vivant mais petit).
Cas d’usage typiques :
- App Rust serveur qui veut intégrer Monero sans daemon externe.
- Edge / IoT qui doit accepter Monero localement.
- Service Rust performance-critical où le overhead HTTP est rédhibitoire.
Quand utiliser MoneroPay vs AcceptXMR vs autre
┌─ Tu écris du Rust ?
│
┌── Oui ─────┤
│ │
│ └─→ Tu veux lib intégrée → AcceptXMR
│ Tu veux daemon HTTP → MoneroPay
│
────┤
│
└── Non ──────→ Tu veux daemon HTTP → MoneroPay
Tu veux ne pas écrire de code →
- WordPress / WooCommerce → monerowp
- Multi-coin / boutique → BTCPay / Bitcart
- POS boutique physique → XMRetail / SuperPay
Décision en 30 secondes selon ton stack et ton cas d’usage.
Pattern d’intégration MoneroPay (exemple Python)
import requests
from flask import Flask, request
MONEROPAY_URL = "http://127.0.0.1:5000" # daemon localhost
app = Flask(__name__)
@app.route("/api/create-invoice", methods=["POST"])
def create_invoice():
amount = request.json["amount_xmr"]
description = request.json.get("description", "")
# Demande à MoneroPay de générer une invoice
r = requests.post(f"{MONEROPAY_URL}/receive", json={
"amount": int(amount * 1e12), # XMR → atomic units
"description": description,
})
invoice = r.json()
# invoice["address"] = subaddress unique pour cette commande
# invoice["payment_id"] = ID interne MoneroPay
return invoice
@app.route("/webhook/moneropay", methods=["POST"])
def moneropay_webhook():
# MoneroPay POST ici quand un paiement est confirmé
data = request.json
payment_id = data["payment_id"]
amount_received = data["amount"]
# Marquer la commande comme payée dans ton DB
# ...
return {"ok": True}
Côté config MoneroPay : --callback-url http://localhost:8000/webhook/moneropay.
Pattern d’intégration AcceptXMR (exemple Rust)
use acceptxmr::{PaymentGateway, AcceptXmrError};
let gateway = PaymentGateway::builder(
private_view_key.to_string(),
primary_address.to_string(),
"/var/lib/myapp/invoice_store.sled".to_string(), // persistence
)
.daemon_url("http://127.0.0.1:18081".to_string())
.build()
.await?;
// Run le scanner en background
gateway.run().await?;
// Génère une invoice
let invoice_id = gateway.new_invoice(
100_000_000_000, // 0.1 XMR en atomic units
1, // confirmations attendues
10, // expiration en blocs
"Order #1234".to_string(),
)?;
// Subscribe aux updates
let mut subscriber = gateway.subscribe(invoice_id)?;
while let Some(invoice) = subscriber.recv().await {
if invoice.is_confirmed() {
// Marquer la commande comme payée
break;
}
}
OPSEC pour les deux
- View-only mode obligatoire sur serveur exposé. La spend key reste sur une machine distincte (idéalement air-gapped).
- Backups réguliers :
- MoneroPay : fichier
wallet/du wallet RPC + DB SQLite des invoices. - AcceptXMR : fichier
invoice_store.sled(ou DB que tu as choisie).
- MoneroPay : fichier
- HTTPS / mTLS sur l’endpoint REST de MoneroPay si tu l’exposes au-delà de localhost.
- Firewall : MoneroPay HTTP daemon → bind 127.0.0.1 par défaut, pas 0.0.0.0.
- Update régulier : suis les releases sur GitHub pour patchs sécurité.
- Monitoring : un Prometheus exporter ou un simple ping toutes les 5 minutes pour détecter si MoneroPay s’est crashé.
Limites communes
- Pas de send sans spend key : pour les payouts (refunds, salaires, etc.), tu dois soit (a) passer la spend key à MoneroPay sur un serveur très sécurisé, soit (b) gérer les payouts manuellement depuis ton wallet froid.
- Volatilité prix : ces outils ne fournissent pas de cotation USD/EUR → XMR. Tu dois fetcher le rate côté ton app (CoinGecko, Kraken API, etc.) et convertir avant d’appeler
new_invoice. - Fiscal : pas d’export comptable automatique. À implémenter côté ton app ou export CSV manuel.
En résumé
| Si… | Tu prends |
|---|---|
| App Python / Node / PHP / Ruby / Java / Go | MoneroPay |
| App Rust performance-critical ou edge | AcceptXMR |
| Tu veux pas écrire de code (WordPress) | monerowp |
| Tu veux multi-coin avec UI complète | BTCPay ou Bitcart |
Les deux outils Monero-native sont solides, maintenus, non-custodial. Le bon choix dépend uniquement de ton stack technique. Une fois intégrés, tu accèptes Monero exactement comme tu accepterais un virement bancaire — avec privacy en plus.
Sources : github.com/moneropay/moneropay, github.com/busyboredom/acceptxmr, docs.rs/acceptxmr, getmonero.dev/accepting-monero/overview.html.
● profils liés