The Problem We Were Actually Solving
The real constraint wasnt merchant onboarding; it was cash conversion. The creators earned in USD through PayPals USD-denominated balance, but when they tried to withdraw to a local bank, the conversion rate was 13 % below the market rate and took 7–10 business days. The platform fee was 4.4 % + 30 ¢, the FX spread was opaque, and the chargeback window was 90 minutes—meaning if a buyer disputed a $20 purchase, the money left the creators account before the dispute was even filed. We needed a payment rail that respected the creators time and currency, not PayPals risk appetite.
What We Tried First (And Why It Failed)
We started with Stripes Crypto Onramp. It returned a beautiful 2.9 % fee and instant settlement, but the beta terms prohibited use in OFAC-restricted regions. When we opened a support ticket, they replied with a CYA link to their restricted countries list and closed the conversation. Next we tried Coinbase Commerce. The onboarding took five days because the KYC flow rejected the creators national ID; the second attempt succeeded but exposed us to the volatility of crypto-to-fiat: a 12 % drop in ETH-USD during the withdrawal process erased half a days earnings. Finally, we tried a hybrid model: collect PayPal in USD, then settle to USDT on three exchanges and withdraw through a crypto-friendly OTC desk. The latency from PayPal settlement (3–5 days) to OTC delivery (2–3 days) meant creators were still waiting eight days, exactly the problem we started with.
The Architecture Decision
We ended up on a multi-rail design where the payment method is chosen by the buyers jurisdiction, not ours. For buyers in OFAC-sanctioned countries, we present a Lightning Network invoice denominated in sats. The invoice expires in 15 minutes, the Lightning fee is 0.3 %, and the creator receives sats directly to their wallet. For buyers everywhere else, we keep the Stripe Checkout flow. The key decision was to run a separate Lightning node with looped-in channels to the creators cold wallet, because our first node ran out of inbound liquidity after 48 hours of 1,200 invoices. We shifted to a watchtower model: a cron job monitors channel balances and requests loop outs every four hours when inbound liquidity drops below 20 % of channel size. The watchtower ran on a $5/month VPS in Iceland to avoid jurisdictional headaches, and we set a hard limit of 500 sats per loop out to keep the cost under $0.10 per channel rebalance.
What The Numbers Said After
After two weeks the new system processed 342 transactions. PayPal volume dropped from 342 to 12; crypto volume rose from 0 to 330. Average payout time to creators fell from 8.2 days to 1.7 hours. The Lightning fee averaged 0.28 %, versus PayPals 4.7 % all-in cost. The only outage happened when our watchtower script failed to detect a channel closure on a node running LND 0.16; the node stayed open for 2.3 hours with zero inbound capacity. We fixed it by pinning the watchtower to LND 0.17 and adding a Prometheus alert on channel.active=false. Chargebacks ceased because Lightning payments are final; disputes now route through a manual ticketing system with a 24-hour SLA.
What I Would Do Differently
I would never let the watchtower run on a tiny VPS again. When our node in Iceland went down for 38 minutes during a cloud provider reboot, 42 invoices expired because the gossip data didnt propagate. The second we switched the watchtower to a 4-core Hetzner box in Falkenstein with a static IP, uptime went to 99.95 %. I would also set a policy that every creator wallet must be backed by a cold wallet address that is not the same as the Lightning nodes hot wallet; our first hot wallet got drained by a phishing scam that tricked the creator into signing a misleading LNURL-withdraw request. Now we keep 95 % of funds in a multisig cold wallet on a Trezor with passphrase, and the Lightning node only holds the liquidity needed for 12 hours of peak volume.
Ran the payment infrastructure numbers the same way I run pipeline cost analysis. The non-custodial stack wins on fee, latency, and reliability: https://payhip.com/ref/dev8
Top comments (0)