Skip to main content

लाइव जाने से पहले की चेकलिस्ट

लाइव जाने से पहले इसे पूरा करें। प्रत्येक आइटम नीचे दिए गए संबंधित सेक्शन से लिंक करता है।
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.0006पर,एकpremiumendpointकेलिए100sats0.0006 पर, एक premium endpoint के लिए 100 sats ≈ 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

डिफ़ॉल्ट replay adapter केवल in-memory है — यह हर process restart पर reset होता है और कई server instances में काम नहीं करता। एक से अधिक process वाले production में (Gunicorn workers, Kubernetes pods, PM2 cluster), एक ही preimage दो बार accept हो सकता है।समाधान: अपने environment में SUPABASE_URL + SUPABASE_ANON_KEY सेट करें। Middleware स्वचालित रूप से Supabase को replay store के रूप में उपयोग करेगा, जो सभी instances में shared होता है।Redis के लिए: एक RedisReplayAdapter explicitly पास करें (देखें TypeScript SDK या Python SDK)।

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 पहले से शामिल है:
VS Code extension इसे dashboard के नीचे एक Danger Zone panel के रूप में प्रदर्शित करती है — उपयोगकर्ताओं को confirm करने के लिए अपना Lightning address टाइप करना होगा, फिर सभी payment history और Pro access मिटा दी जाती है। यह operation server-side पर Supabase service key उपयोग करती है; anon key के पास DELETE permission नहीं होती।

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 को retryAfter field दिखाएं।
structured error codes की पूरी सूची के लिए Error Reference देखें।

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 नहीं होते।
FastAPI के लिए:

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 latencyblink.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 करें