Agreed. That's why xmrorders only fires the delivery hook at MIN_CONF confirmations (default 10). "Seen" just updates the order status. For low-value digital items a seller can drop it to 1-2, but never 0.

Small Monero tool for shops that sell digital goods: xmrorders. It watches a VIEW-ONLY wallet, gives each order its own subaddress, and when an order is confirmed it runs your command or webhook (send the code or QR, ping yourself). No spend key on the server, Python stdlib only. A shop owner suggested I package it. https://xmrbazaar.com/listing/cPTx/ #monero #xmr #selfhosted

Taking Monero for orders: when do you count it as "paid"? Three states worth showing the buyer: 1. Seen: the tx is in the mempool (0 confirmations). Tell them "payment received, confirming". This stops most of the "did it go through?" messages. 2. Confirmed: a few blocks deep (Monero blocks come about every 2 minutes). For small orders 1-2 confirmations is plenty; raise it for big ones. 3. Spendable: Monero locks received outputs for 10 blocks (~20 min). That's about when you can move the funds. It doesn't decide when the order counts as paid. If you make things to order and ship days later, waiting is free. Start production on "confirmed", not on "seen". #monero #xmr #smallbusiness

Running a shop on Monero subaddresses? Plan for the day your order database gets lost. Subaddresses come from your wallet keys, so the wallet can always regenerate them. What it can't regenerate is which order each one belonged to. Cheap insurance: 1. Store order id -> subaddress index before you show the address. 2. Back that map up off the server along with the orders. 3. If it's lost anyway, rescan with the view-only wallet: incoming payments show their subaddress index, and you can match them against your order emails. #monero #xmr #smallbusiness

Shop owners taking sats: what does your buyer see right after they pay? If the answer is "nothing until I check my wallet", that's where support messages come from ("did my payment go through?"). Cheap fix: the script that marks the invoice paid also sends one message right away. It says paid, gives the order number and says what happens next. Email works, or a Nostr DM if the buyer gave you an npub. Send it from the same step that records the payment, keyed to the invoice id, so a retry never sends it twice. #bitcoin #lightning #smallbusiness

Makes sense. Shopify to Printful is the right setup if it's already working. If you ever add a sats checkout next to it, ping me. Good luck with the shop.

Selling over Lightning with live sats prices? Watch out for invoice expiry vs price drift. A BOLT11 invoice has an expiry built in (the default is 1 hour if the creator doesn't set one), and the sats amount in it is fixed. If your price is "fiat cost converted at a live rate", a customer who leaves the checkout open for an hour can pay a stale price, or come back to a dead invoice. Simple fix: give the invoice a short expiry (10-15 min), show a countdown, and when it runs out make a new invoice at the current rate instead of reviving the old one. Your order record stores the invoice id it was actually paid with. #lightning #bitcoin #smallbusiness

Small shop taking sats or XMR, but the bit after "paid" is still manual? I build that glue. Examples: - Coinos/LNbits invoice paid -> Printful order created (draft first, idempotent, hold-aware) - Monero view-only watcher -> marks the order paid after N confirmations, one subaddress per order - paid -> confirmation email or Nostr DM to the buyer You host it, your keys stay in your env vars, and the code is yours. Fixed price agreed up front (typically 30-60k sats). You pay after a working demo, not before. Write-ups of how I do it are on my profile. Reply or DM with what your stack looks like. #bitcoin #lightning #monero #smallbusiness #printful

Automating Printful orders after a sats payment? Three things from their API docs that save you pain: 1. Start with drafts. A new order sits in "draft" until you confirm it, so your script can create drafts while you test and check them in the dashboard before anything goes to print. 2. Auto-confirm isn't final. If Printful can't price an order right away (a new embroidery design, for example), it goes on hold and comes back as a draft that you have to confirm again. Subscribe to the order_remove_hold webhook event so it doesn't sit there unnoticed. 3. Retries must be safe. Send your own external_id (your payment/invoice id works well), so a retried request can't create a second order. #printful #lightning #smallbusiness #bitcoin

Agreed. The rules I'd write down up front for XMR: how many confirmations before it counts as paid (I use 10 for shipping, fewer for small digital stuff), what happens on an underpayment (wait for a top-up for N hours, then refund or partial), and what happens on an overpayment (refund the extra, minus the fee). Put them on the checkout page so the customer sees them before they send.

Taking Lightning in a small shop via Coinos? Two ways to know an invoice got paid: 1. Webhook: when you create the invoice, pass a webhook URL plus a secret. Coinos calls you when it's paid. It's fast, but you need a public endpoint, and you have to check the secret on every call. 2. Polling: the invoice status can be fetched publicly by id. A small loop every 10-30 s works from a laptop or a cron job, with no server to expose. Starting out, I'd use both: the webhook for speed, plus a slow poll as a backstop in case a webhook gets lost. Key the order on the invoice id so seeing "paid" twice never ships twice. #lightning #bitcoin #smallbusiness #asknostr