लाइव जाने से पहले की चेकलिस्ट
लाइव जाने से पहले इसे पूरा करें। प्रत्येक आइटम नीचे दिए गए संबंधित सेक्शन से लिंक करता है।1
मल्टी-इंस्टेंस के लिए Replay protection कॉन्फ़िगर किया गया
डिफ़ॉल्ट adapter केवल in-memory है। यदि आप एक से अधिक process चलाते हैं (Gunicorn workers, PM2 cluster, Kubernetes), तो
SUPABASE_URL + SUPABASE_ANON_KEY सेट करें या RedisReplayAdapter उपयोग करें। विवरण →2
Environment variables secrets manager में
API keys को कभी hardcode न करें। locally
.env उपयोग करें, prod में secrets manager। विवरण →3
Health check endpoint मौजूद है
Monitoring pings से invoice creation trigger नहीं होनी चाहिए। अपने paid routes से पहले एक
/health route जोड़ें। विवरण →4
Error responses आंतरिक जानकारी leak नहीं करते
Provider errors को catch करें और एक clean 503 return करें — stack trace नहीं। विवरण →
5
Price सोच-समझकर तय किया गया है
priceSats वास्तविक मूल्य को दर्शाना चाहिए। 1 sat ≈ 0.06 उचित है। इसे गलती से 0 न सेट करें।6
Invoice endpoint पर Uptime monitoring
402 response को monitor करें (यह एक सामान्य response है, error नहीं)। UptimeRobot जैसे tools custom status code expectations को support करते हैं।
7
Invoice creation पर Rate limiting
हर unauthenticated request एक Lightning invoice बनाती है। Rate limiting के बिना, कोई हमलावर आपके provider के invoice quota को मुफ्त में खत्म कर सकता है। publicly deploy करने से पहले
express-rate-limit जोड़ें। विवरण →महत्वपूर्ण: प्रोडक्शन में replay protection
Environment variables
Keys को कभी hardcode न करें। हमेशा environment variables उपयोग करें:Payment logging (Supabase)
VS Code extension dashboard और analytics के लिए हर payment को Supabase में log करें:Cloudflare Workers deployment
l402-kit API Cloudflare Workers (V8 isolates, zero cold start) पर चलती है। In-memory replay store प्रति isolate reset होता है — high-traffic APIs के लिए, replay protection हेतु Cloudflare KV या Durable Objects उपयोग करें।Docker
उपयोगकर्ता डेटा हटाना
एक deletion endpoint expose करें ताकि उपयोगकर्ता अपना डेटा स्थायी रूप से हटा सकें। l402-kit backend में/api/delete-data पहले से शामिल है:
Error handling
Provider errors को unformatted 500 के रूप में सामने आने से पहले catch करें:- Clients को कभी stack traces न return करें — उन्हें server-side log करें।
- Provider timeouts (503) अस्थायी हैं — backoff के साथ retry करना सुरक्षित है।
- Token errors (401) कभी अस्थायी नहीं होते — auto-retry न करें, नया invoice मांगें।
- Rate limit errors (429) — caller को
retryAfterfield दिखाएं।
Rate limiting
हर unauthenticated request आपके Lightning provider परcreateInvoice() trigger करती है। Rate limiting के बिना, कोई भी आपके endpoint को flood कर सकता है और आपके provider का API quota मुफ्त में खत्म कर सकता है — बिना एक भी sat चुकाए।
अपने L402 routes से पहले express-rate-limit जोड़ें:
पहले से भुगतान करने वाले clients
skip function द्वारा छोड़ दिए जाते हैं — यह सीमा केवल उन unauthenticated calls पर लागू होती है जो नया invoice trigger करती हैं। वैध payers कभी throttle नहीं होते।Health check endpoint
Monitoring tools से invoice creation trigger न हो, इसके लिए हमेशा एक मुफ्त health check जोड़ें:Monitoring
ट्रैक करने के लिए मुख्य metrics:- 402 response rate — स्वस्थ baseline उच्च होता है (अधिकांश callers को भुगतान करना होगा)
- Payment verification rate — paid vs unpaid calls का अनुपात
- Provider latency —
blink.createInvoice()< 500ms होनी चाहिए - Replay attempts — spike token reuse attacks का संकेत देता है
परफॉर्मेंस
- Token verification O(1) है — pure crypto, कोई DB नहीं, कोई network नहीं
- Invoice creation (402 path) आपके Lightning provider API को call करती है — यदि आप उम्मीद करते हैं कि payment से पहले एक ही endpoint बार-बार hit होगा तो cache जोड़ें
- Replay store in-memory
Setहै — multi-instance deployments के लिए Redis से swap करें