lolipop
  • demo
  • woo & widget
  • shipped
  • get xmr
  • compare
  • pricing
  • integrations
  • why xmr
|
get started
login
↑

// privacy

Privacy
Policy.

minimal data. enforced retention. no surveillance business model.last updated: 9 april 2026
01Our philosophy

lolipop is payment notification infrastructure for Monero, not a marketplace. We collect what the product needs to work, delete it on a schedule, and do not monetize attention or identity.

02What we collect from merchants

When you create an account and use the dashboard or API:

  • Email (magic-link login) and optional XMPP for outbound notifications
  • Monero primary address and encrypted view key (subaddress generation and payment detection)
  • Optional webhook URL and secret for signed callbacks; optional product reference fields on orders
  • API key fingerprints, plan, and billing metadata needed for the service

At rest: view keys and TOTP material are encrypted with AES-256-GCM. Webhook URLs and secrets and XMPP JIDs are stored sealed with the same key family (opaque ciphertext in SQLite). A derived hash is stored for XMPP login lookup; it does not reveal your JID without the server key.

You may set an optional per-merchant paid-order retention (clamped in the dashboard) when the default server schedule should not apply to your paid orders.

We do not require your legal name, postal address, government ID, or card data.

03What we collect from buyers (checkout)

Buyer-facing checkout is server-rendered HTML: no JavaScript, no third-party assets, no cookies.

  • We do not run analytics or ad trackers on checkout. Product images you pass in are fetched server-side at order creation and inlined so the buyer's browser does not call your CDN.
  • The Go service can write structured HTTP access lines. For GET /c/ routes, the client IP is logged as redacted by default so routine access logs are not a checkout deanonymization ledger. Operators can opt into full IPs with ACCESS_LOG_CHECKOUT_IP=true or disable access lines with ACCESS_LOG=false.
  • Your hosting provider, reverse proxy, or Tor exit may still see IP-layer metadata. Tor and careful proxy configuration reduce that exposure; lolipop does not depend on knowing the buyer's IP to confirm payment.

Each order gets a unique subaddress. That separates on-chain receive addresses between orders; on-chain privacy still depends on wallet behavior outside lolipop.

04View key handling

Your view key is:

  • Encrypted at rest (AES-256-GCM)
  • Not logged in plaintext
  • Not sent to third-party SaaS
  • Used only with monero-wallet-rpc to derive subaddresses and observe incoming transfers

A view key cannot spend funds. If disks or backups leak, encryption helps; if a live process or operator session is compromised, that protection is bypassed — see limitations below.

05Honest limitations

Encryption at rest helps with stolen disks and misplaced backups. It does not stop an attacker who compromises the running API — the service must decrypt secrets to sign webhooks and deliver notifications. Design assumes breach-hardening via the view-key trust model (no spend authority) and aggressive deletion, not magic confidentiality on a live host.

06Cookies and tracking

Merchant dashboard (Next.js):

  • Session cookie for authentication
  • No Google Analytics, Cloudflare, or ad pixels — by design

Buyer checkout (Go):

  • No cookies, no trackers, no external requests in the default template
07Third parties

We do not sell data. Infrastructure vendors (hosting, DNS, email transit) may see metadata required to deliver the service — choose providers aligned with your threat model.

08Tor

Checkout and API are intended to work without JavaScript. Hidden-service deployment is supported in our architecture; whether a specific deployment exposes an onion is an operator choice.

09Logs and audit

Security-sensitive events are written to an audit log (timestamps, optional API key id, success flag, coarse detail). IP and user-agent may be stored for recent rows and are scrubbed on a shorter schedule than the row itself. You can run in a mode that drops noisy successful API-key audit events (AUDIT_LOG_FAILURES_ONLY=true) while keeping failures and account-security events.

10Data retention (enforced in software)

The API deletes or scrubs rows on a timer. Defaults are configurable via environment variables on the Go host (examples below); paid orders can follow a per-merchant day count when set.

data typepolicy
Merchant profile (email, keys, webhook configuration)Until you delete the account (not yet self-serve in all builds — contact support)
Paid ordersDeleted after paid_at + default 90 days (override: merchant setting or ORDER_RETENTION_PAID_DAYS)
Unpaid / non-final ordersDeleted after created_at + ORDER_RETENTION_UNPAID_DAYS (default 90)
Webhook delivery attemptsDeleted after WEBHOOK_DELIVERY_RETENTION_DAYS (default 90), and cascade when parent order is removed
Audit log rowsDeleted after AUDIT_RETENTION_DAYS (default 90); IP and user-agent scrubbed earlier (AUDIT_IP_RETENTION_HOURS, default 24)
Magic link tokensShort-lived; used tokens cleaned periodically

Purged rows are removed from SQLite; restore from encrypted backups only if you keep them.

11Your rights (GDPR)

If you are in the EU, you may have the right to access, correct, delete, object, or export data we hold.

Contact gm@lolipop.cash. We aim to respond within 30 days.

12Data breaches

If a breach materially affects merchant account data, we will notify affected merchants without undue delay and follow applicable reporting rules.

13Changes

We may update this page when behavior changes. The current version always lives at /privacy. Material changes for active merchants will be announced by reasonable means (for example email).

14Contact

Privacy questions: gm@lolipop.cash

lolipop

stack: monerod · debian · buyvm · njalla

product

  • docs
  • faq
  • embed widget
  • WooCommerce
  • get xmr
  • contact

company

  • terms
  • privacy

© 2026 lolipop — payment infrastructure, not a marketplace.