No progress bars, no fake quarters. Pins on a board: what's shipped, what's in motion, and what's still just an idea taped up so we don't lose it. Drag the notes around. Nothing here is a promise.
Everything pinned around this card is a thin adapter. The shared substrate isn't us — it's Monero + the merchant's keys. An address + view key is a portable, sovereign receiving identity. Widget, verifier, watch agent: one engine, reused everywhere below.
beta zip on GitHub, live demo store
composer require, on Packagist
adapter-core extracted, 27 tests green
pushed, not run vs real WHMCS yet
Long-polling, no open port, runs behind NAT. Per-order subaddress + QR in DM.
Relays as a decentralized notification bus — no webhook server, ever.
Every NIP-15 client settles in Lightning/Cashu. Monero is the missing payment leg.
Self-hosted = Node, reuse the lib directly. Ghost Pro (hosted) = thin adapter.
Hosted SaaS can't run our code — thin merchant-side adapter + the hosted checkout.
Once the PHP engine is a stable Composer package, these are thin wrappers, not copy-paste.
Same shape as the Telegram bot — a bot process, the JS agent, "on paid" swapped per use-case.
Non-custodial escrow. The server should never be able to become the wallet.
Not a monolith. Every card above stays standalone and installable on its own — that doesn't change. The direction is just: once there are enough thin adapters, give them one shared install/config path so picking your channels (Woo + Telegram + Nostr, or just PHP alone) feels like snapping in modules, not repeating setup for each one. Segmented, plug-and-play, opt-in per piece.
┌────────────────────┐
│ xmr-pay core │ address + view key
│ widget · verify │ = the merchant's own
│ watch agent │ sovereign identity
└──────────┬─────────┘
┌───────┬────────┼────────┬────────┬─────────┐
[woo] [php] [tg] [nostr] [discord] [escrow] ...
shipped idea wip idea idea
// each bracket: standalone today. "the suite" = one shared
// spine to install/configure them, later — not a rewrite.