Telegram Mini App (TMA) विकास की गलतियाँ और उन्हें कैसे टालें

TL;DR

• Telegram Mini App डेवलपमेंट की ज़्यादातर गलतियाँ तब होती हैं जब Mini App को आम वेबसाइट मान लिया जाता है। असल में यह अलग-अलग Telegram clients के अंदर चलने वाला WebView है।
• सबसे ज़रूरी सुधार: initData को अपने सर्वर पर वेरिफ़ाई करें और पुराने auth_date वाले payload रिजेक्ट करें। Authorization के लिए initDataUnsafe पर कभी भरोसा न करें।
• लेआउट बग आम तौर पर CSS फ़्रेमवर्क से नहीं, बल्कि 100vh और safe area insets को नज़रअंदाज़ करने से आते हैं।
• Bot API 10.2 (14 जुलाई 2026) से Mini App methods सिर्फ़ Mini App के अपने डोमेन से कॉल हो सकते हैं। iframe और कई डोमेन वाले सेटअप तब तक टूटे रहेंगे, जब तक फ़्लो दोबारा डिज़ाइन न किया जाए।
• Monetization की गलतियाँ कोड की गलतियों जितनी ही महँगी हैं: प्रोडक्ट की वैल्यू दिखने से पहले विज्ञापन, production में छोड़ा गया debug: true और सिर्फ़ client पर चलने वाला रिवॉर्ड लॉजिक कमाई घटाते हैं या फ़्रॉड को न्योता देते हैं।

इस लेख में Telegram Mini App डेवलपमेंट की वे गलतियाँ हैं जो production में सबसे ज़्यादा दिखती हैं: authorization, viewport, storage, वर्ज़न, लॉन्च पैरामीटर और monetization। हर गलती के लिए ठोस हल है, साथ में सही method के नाम और Bot API वर्ज़न। आख़िर में डायग्नोसिस टेबल और प्री-रिलीज़ चेकलिस्ट है, जिसे हर deploy से पहले चलाया जा सकता है।

Telegram Mini App डेवलपमेंट में गलतियाँ क्यों होती हैं

Mini App ऐसे ऐप के अंदर चलता है जिस पर आपका कंट्रोल नहीं है। इससे तीन सीमाएँ बनती हैं, और नीचे के लगभग सभी बग इन्हीं में से किसी एक से आते हैं।

• Client ब्राउज़र नहीं है। iOS पर Telegram का WebView Android से अलग बर्ताव करता है, और दोनों Telegram Desktop से अलग हैं। सबसे ज़्यादा फ़र्क़ storage, कीबोर्ड हैंडलिंग और gestures में है।
• हर client अलग API वर्ज़न सपोर्ट करता है। पुराने Telegram बिल्ड वाले यूज़र के पास वह method होता ही नहीं जिसे आपने कॉल किया, और इसका कोई polyfill नहीं है।
• आपके आस-पास का इंटरफ़ेस Telegram का है। हेडर, नीचे का बार, swipe-to-close gesture और safe area Telegram के हैं, इसलिए आपके लेआउट को इनके हिसाब से चलना होगा।

Telegram Mini Apps का ऑफ़िशियल डॉक्यूमेंटेशन एक बार पढ़ लेना काफ़ी नहीं है। Breaking changes Bot API changelog में आते हैं, और 2026 में ही अब तक सात नए Bot API वर्ज़न (9.4 से 10.3 तक) आ चुके हैं।

भारत के लिए एक बात और: StatCounter के अनुसार सितंबर 2026 में भारत में मोबाइल पर Android का हिस्सा लगभग 94% और iOS का लगभग 6% था। यानी ज़्यादातर भारतीय यूज़र्स Android WebView पर होंगे, अक्सर मिड-रेंज या बजट फ़ोन और मोबाइल डेटा पर। फिर भी iOS को अलग से टेस्ट करना होगा, क्योंकि storage से जुड़े ज़्यादातर बग वहीं आते हैं।

Security और init data की गलतियाँ

सबसे आम security गलती है client से आए डेटा को पहचान का सबूत मान लेना। Telegram आपको signed payload देता है, और उसे वेरिफ़ाई करना आपका काम है।

1. Signature जाँचे बिना initDataUnsafe पर भरोसा करना

initData वह raw, signed लॉन्च payload है जो Telegram Mini App को देता है। initDataUnsafe वही डेटा है, जो सुविधा के लिए पहले से parse किया हुआ है। नाम में Unsafe शब्द चेतावनी है, सजावट नहीं। Telegram के डॉक्यूमेंटेशन में साफ़ लिखा है कि बॉट के सर्वर पर इस्तेमाल से पहले डेटा को वेरिफ़ाई करना ज़रूरी है।

कैसे बचें: raw initData स्ट्रिंग अपने backend पर भेजें और वहीं वेरिफ़ाई करें। hash को छोड़कर सभी key-value जोड़ों से data-check string बनाएँ: उन्हें alphabetically sort करें और newline से जोड़ें। HMAC-SHA256(bot_token, "WebAppData") से secret key निकालें, HMAC-SHA256(data_check_string, secret_key) कैलकुलेट करें और नतीजे की hash से constant-time तुलना करें। बॉट टोकन कभी client को न भेजें, और request पैरामीटर में सीधे आए user ID को कभी स्वीकार न करें।

अगर किसी third party को आपका बॉट टोकन रखे बिना लॉन्च वेरिफ़ाई करना है, तो Telegram Mini Apps init data reference में बताया गया Ed25519 signature वाला तरीका इस्तेमाल करें। यहाँ एक जाल बार-बार सामने आता है: signature base64url में बिना padding के एन्कोड होता है, इसलिए कई भाषाओं में decode करने से पहले = कैरेक्टर वापस जोड़ने पड़ते हैं।

2. auth_date कितना पुराना है, यह न जाँचना

वैध signature सिर्फ़ यह साबित करता है कि payload Telegram से आया है, यह नहीं कि वह अभी-अभी आया है। Expiry जाँच के बिना पकड़ी गई initData स्ट्रिंग हमेशा काम करती रहेगी।

कैसे बचें: जिस payload का auth_date तय विंडो से पुराना हो, उसे रिजेक्ट करें। 24 घंटे आम डिफ़ॉल्ट है; जो ऐप पैसे या इन-ऐप करेंसी से जुड़े हैं, उनके लिए छोटी विंडो रखें। वेरिफ़ाई किए गए payload के बदले एक बार अपना session टोकन जारी करें, और आगे की हर request उसी टोकन से authenticate करें।

3. Session टोकन localStorage में रखना

Telegram के WebView में localStorage भरोसेमंद नहीं है। Production Mini Apps पर लिखने वाले डेवलपर्स बताते हैं कि iOS और कुछ Linux डेस्कटॉप बिल्ड पर यह persist नहीं होता, यानी restart होते ही साफ़ हो सकता है और session भी चला जाता है।

कैसे बचें: storage आदत से नहीं, ज़रूरत से चुनें।

जो भी चीज़ तय करती है कि यूज़र के पास क्या है या वह क्या कमाता है, वह आपके सर्वर पर होनी चाहिए।

अगर आप सर्वर पर Telegram ID, बैलेंस या दूसरा निजी डेटा रखते हैं और भारतीय यूज़र्स को सर्विस देते हैं, तो Digital Personal Data Protection (DPDP) Act, 2023 को ध्यान में रखें। इसके Rules नवंबर 2025 में notify हुए। Consent, security safeguards और data breach की रिपोर्टिंग (Data Protection Board को 72 घंटे में विस्तृत रिपोर्ट) जैसी मुख्य ज़िम्मेदारियाँ नोटिफ़िकेशन के 18 महीने बाद, यानी मई 2027 से लागू होंगी। इसके अलावा CERT-In के अप्रैल 2022 के directions के तहत service providers और कंपनियों को तय तरह की cyber incidents की रिपोर्ट 6 घंटे के अंदर CERT-In को करनी होती है। सीधे शब्दों में कहें तो उतना ही डेटा रखें जितना ज़रूरी हो, और leak होने पर क्या करना है, यह पहले से तय रखें। यह कानूनी सलाह नहीं है।

4. किसी दूसरे डोमेन से Mini App methods कॉल करना

यह गलती नई है, और इसने चलते हुए ऐप्स तोड़े हैं। 14 जुलाई 2026 को जारी Bot API 10.2 ने Mini App security सख़्त की: अब Mini App के मूल डोमेन से अलग किसी origin से Mini App methods इस्तेमाल नहीं किए जा सकते। Changelog के अनुसार यह सुरक्षा 20 जुलाई 2026 से लागू हुई, और बॉट @BotFather के Mini App से इससे opt out कर सकते हैं। Opt out सिर्फ़ अस्थायी रास्ता है, हल नहीं।

कैसे बचें: Telegram.WebApp methods कॉल करने वाली हर स्क्रीन को Mini App के लिए रजिस्टर्ड डोमेन पर रखें। अगर फ़्लो का कोई हिस्सा पेमेंट प्रोवाइडर, पार्टनर के पेज या embedded iframe पर है, तो Telegram API कॉल्स अपने origin पर वापस लाएँ और अलग-अलग contexts के बीच नतीजे अपने backend से भेजें। यह मानने से पहले कि सब अब भी काम करता है, पूरे फ़्लो को अपडेटेड client पर टेस्ट करें।

लेआउट और viewport की गलतियाँ

Viewport बग सबसे ज़्यादा नज़र आने वाली कैटेगरी है (कटा हुआ CTA तुरंत दिखता है), और इन्हें रोकना सबसे आसान भी है।

1. Telegram की viewport height की जगह 100vh इस्तेमाल करना

मोबाइल पर Mini App bottom sheet की तरह खुलता है, जिसे यूज़र ऊपर-नीचे खींच सकता है। 100vh ब्राउज़र viewport दिखाता है, जो दिखने वाले हिस्से से मेल नहीं खाता, इसलिए कंटेंट स्क्रीन के नीचे या Telegram के अपने UI के नीचे चला जाता है।

कैसे बचें: शुरुआत में expand() कॉल करें, फिर लेआउट का साइज़ viewportHeight और viewportStableHeight से तय करें। जो चीज़ उछलनी नहीं चाहिए, उसके लिए viewportStableHeight लें: यह drag और कीबोर्ड एनिमेशन के बीच की स्थितियों को नज़रअंदाज़ करता है, जबकि viewportHeight लगातार बदलता रहता है। Viewport change event को subscribe करें और सिर्फ़ stable वैल्यू पर दोबारा render करें।

2. Safe area insets को नज़रअंदाज़ करना

Bot API 8.0 में दो अलग inset objects आए, और इन्हें आपस में मिला देना आम है। safeAreaInset सिस्टम वाले हिस्सों के बारे में है, जैसे notch और home indicator। contentSafeAreaInset उस जगह के बारे में है जो Telegram के अपने इंटरफ़ेस एलिमेंट घेरते हैं।

कैसे बचें: दोनों लगाएँ। System insets हार्डवेयर cutouts से बचाते हैं, content insets आपके हेडर को Telegram के हेडर से दूर रखते हैं। Fullscreen मोड में (जो उसी Mini Apps 2.0 रिलीज़ में आया) insets और भी ज़रूरी हो जाते हैं, क्योंकि Telegram अब आपके लिए वह जगह रिज़र्व नहीं करता।

3. गेम्स में vertical swipes चालू छोड़ना

ऐप के अंदर नीचे की ओर swipe करने पर कंटेंट स्क्रॉल होने के बजाय Mini App बंद हो सकता है। गेम्स और drag वाले इंटरफ़ेस में यूज़र सोचते हैं कि ऐप crash हो गया।

कैसे बचें: कस्टम gestures वाली स्क्रीन पर disableVerticalSwipes() (Bot API 7.7+) कॉल करें और जहाँ सामान्य स्क्रॉलिंग चाहिए, वहाँ इसे फिर चालू करें। जिस स्क्रीन पर बिना सेव किया इनपुट हो, वहाँ साथ में enableClosingConfirmation() (Bot API 6.2+) लगाएँ।

4. अपना कस्टम back बटन बनाना

आपका अपना back तीर Telegram नेविगेशन और Android के system back बटन से टकराता है। यूज़र को दो back कंट्रोल मिलते हैं जो अलग-अलग बर्ताव करते हैं।

कैसे बचें: BackButton (Bot API 6.1+) इस्तेमाल करें, उसे अपने router से जोड़ें और route बदलने पर उसे दिखाएँ या छिपाएँ। नेविगेशन stack एक रखें, दो नहीं।

असली डिवाइस पर performance की गलतियाँ

Mini App का ज़्यादातर ट्रैफ़िक मिड-रेंज और बजट Android फ़ोन से आता है, और भारत में यह बात और भी ज़्यादा लागू होती है। Session चैट में एक टैप से शुरू होता है, इसलिए यूज़र उम्मीद करते हैं कि ऐप मैसेज जितनी तेज़ी से खुले।

• भारी पहला bundle। Routes को split करें, पहली स्क्रीन के लिए ग़ैरज़रूरी हर चीज़ बाद में लोड (defer) करें, और शुरुआती payload को performance का मुख्य मीट्रिक मानें। Chrome DevTools में धीमे 4G throttling पर पहली स्क्रीन ज़रूर टेस्ट करें।
• SSR पर निर्भर रहना। Telegram APIs को window चाहिए, इसलिए server-side rendering उन तक नहीं पहुँच सकती। Next.js प्रोजेक्ट्स में यह समस्या server component के अंदर पहले Telegram कॉल पर ही आ जाती है। Telegram पर निर्भर लॉजिक client components में रखें और SDK तैयार होने तक skeleton दिखाएँ।
• ऐसे एनिमेशन जो बजट डिवाइस नहीं चला पाते। WebView के अंदर कमज़ोर हार्डवेयर पर भारी एनिमेशन अटकने लगते हैं। सिर्फ़ transform और opacity को animate करें, और frame drops दिखें तो इफ़ेक्ट कम करें।
• लोडिंग स्टेट न होना। सफ़ेद स्क्रीन की जगह skeleton वाला पहला paint दिखाएँ। इससे शुरुआती exits साफ़ तौर पर घटते हैं।

वर्ज़न और प्लेटफ़ॉर्म की गलतियाँ

ऐसा method कॉल करना जिसे यूज़र का Telegram बिल्ड सपोर्ट नहीं करता, या तो चुपचाप fail होता है या error देता है, और दोनों में ऐप टूटा हुआ लगता है। इसका हल है न्यूनतम वर्ज़न (version floor) और साफ़ gating।

कैसे बचें: तय करें कि आपका ऐप कम से कम कौन-सा Bot API वर्ज़न सपोर्ट करेगा, उससे ऊपर की हर चीज़ को isVersionAtLeast() (Bot API 6.1+) से gate करें, और हर gated फ़ीचर के लिए काम करने वाला fallback रखें।

सिर्फ़ Telegram Web पर टेस्ट करने से इनमें से ज़्यादातर समस्याएँ छिप जाती हैं। Release candidate को iOS, Android और कम से कम एक डेस्कटॉप client पर चलाएँ। डिवाइस पर debugging के लिए Android में Chrome DevTools और iOS में Safari Web Inspector काम आते हैं। जब दोनों न हों, तो Eruda जैसा इन-ऐप कंसोल बिना केबल के runtime errors दिखा देता है।

startapp और deep link की गलतियाँ

Mini App को सिर्फ़ एक लॉन्च पैरामीटर, startapp, मिलता है, और टीमें अक्सर ऐसी deep link स्कीम बना लेती हैं जो इससे ज़्यादा मानकर चलती है।

कैसे बचें: कई वैल्यू को अपने चुने delimiter से एक ही startapp स्ट्रिंग में एन्कोड करें (ref__campaign__level आम पैटर्न है) और वेरिफ़िकेशन के बाद parse करें। Referral का क्रेडिट या बोनस देने से पहले पैरामीटर को सर्वर पर वेरिफ़ाई किए गए initData से पढ़ें, क्योंकि अकेला लॉन्च पैरामीटर आसानी से नक़ली बनाया जा सकता है। जो deep link हैंडलिंग यह स्टेप छोड़ देती है, वह Telegram Mini Apps में referral फ़्रॉड का आम कारण है। नक़ली अकाउंट और bot ट्रैफ़िक को पहचानने के तरीके Telegram में बॉट से नक़ली ट्रैफ़िक से बचाव वाले लेख में हैं।

विज्ञापन इंटीग्रेशन की गलतियाँ

विज्ञापन इंटीग्रेशन में अक्सर मज़बूत कोड कमज़ोर प्रोडक्ट फ़ैसलों से मिलता है। ये गलतियाँ ऐप crash नहीं करतीं, लेकिन eCPM घटाती हैं, रिवॉर्ड तोड़ती हैं या मॉडरेशन में फ़ेल कराती हैं। अगर आप अभी तरीका चुन रहे हैं, तो इंटीग्रेशन कोड लिखने से पहले Telegram Mini App monetization की रणनीतियाँ पढ़ें, और eCPM कैसे गिनते हैं, यह eCPM फ़ॉर्मूला और Telegram Mini Apps के benchmarks में देखें।

1. विज्ञापन बहुत जल्दी दिखाना

पहली स्क्रीन पर interstitial उस यूज़र को खोने का सबसे तेज़ तरीका है जिसे लाने के लिए आपने अभी पैसे खर्च किए हैं। उसने प्रोडक्ट देखा ही नहीं, तो उसे रोकने लायक कुछ है ही नहीं।

कैसे बचें: वे पल चिह्नित करें जब यूज़र ने कुछ पूरा किया हो (लेवल, टास्क, claim) और विज्ञापन इन्हीं पड़ावों पर लगाएँ। Rewarded फ़ॉर्मेट तब सबसे अच्छे चलते हैं जब रिवॉर्ड ऐसी चीज़ हो जो यूज़र पहले से चाहता है: एक्स्ट्रा लाइफ़, speed-up, बोनस बैलेंस।

2. Production में debug मोड चालू छोड़ना

AdsGram SDK एक debug फ़्लैग लेता है, जो टेस्ट विज्ञापन दिखाता है और logs प्रिंट करता है। AdsGram डॉक्यूमेंटेशन में साफ़ लिखा है कि रिलीज़ से पहले इसे हटाना या false करना ज़रूरी है। Debug व्यू असली ad view नहीं गिना जाता, और Reward URL वाला postback भी debug मोड में नहीं भेजा जाता। इसलिए debug: true के साथ रिलीज़ किया गया ऐप ठीक दिखता है, पर कुछ नहीं कमाता। डीबगिंग के लिए अलग Test प्लेटफ़ॉर्म बनाएँ: वह बिना मॉडरेशन के Active हो जाता है और उसके events गिने नहीं जाते।

3. हर विज्ञापन दिखाने पर init() कॉल करना

window.Adsgram.init({ blockId }) एक AdController लौटाता है। AdsGram डॉक्यूमेंटेशन के अनुसार हर blockId के लिए एक बार initialize करना काफ़ी है, और बार-बार कॉल करने पर वही AdController मिलता है।

कैसे बचें: ऐप शुरू होते ही controller एक बार बनाएँ, उसका reference रखें और हर प्लेसमेंट पर show() कॉल करें। आम rewarded इंटीग्रेशन ऐसा दिखता है:

html

js const AdController = window.Adsgram.init({ blockId: "your-block-id" });

AdController.show() .then(() => { // विज्ञापन पूरा देखा गया: रिवॉर्ड देने के लिए अपने backend को request भेजें }) .catch((result) => { // विज्ञापन नहीं चला या जल्दी बंद कर दिया गया: रिवॉर्ड न दें console.warn(result); });

4. show() की errors हैंडल न करना

जब विज्ञापन चल नहीं पाता या यूज़र बीच में छोड़ देता है, तो show() reject होता है। जिस इंटीग्रेशन में catch() नहीं है, वह या तो ग़लत रिवॉर्ड दे देता है या यूज़र को लोडिंग स्क्रीन पर अटका देता है।

कैसे बचें: reject वाले रास्ते को साफ़ तौर पर हैंडल करें और SDK events को subscribe करें: onStart, onSkip, onReward, onComplete, onError, onBannerNotFound, onNonStopShow, onTooLongSession। लॉन्च के समय onBannerNotFound पर ख़ास नज़र रखें: इसका मतलब है कि उस समय दिखाने के लिए कोई विज्ञापन नहीं मिला, और अक्सर वजह उस geo या ब्लॉक के लिए कम fill होती है, कोड नहीं। रिवॉर्ड या अगली स्क्रीन तक पहुँचने का बिना विज्ञापन वाला रास्ता हमेशा रखें, ताकि विज्ञापन न मिलने पर यूज़र फँसे नहीं।

5. रिवॉर्ड सिर्फ़ client पर देना

अगर रिवॉर्ड client कोड देता है, तो उसे replay किया जा सकता है। यह initDataUnsafe पर भरोसा करने जैसी ही गलती है।

कैसे बचें: रिवॉर्ड अपने backend से दें। बड़े publishers के लिए AdsGram server-to-server postback भी देता है: डॉक्यूमेंटेशन के अनुसार यह 50,000 से ज़्यादा daily average users वाले ऐप्स के लिए सही है। आप ad unit में Reward URL सेट करते हैं, और client-side रिवॉर्ड के बाद AdsGram यूज़र के telegramId के साथ उस URL पर GET request भेजता है। Endpoint को HTTPS (पोर्ट 443) पर GET स्वीकार करना चाहिए और उसमें [userId] placeholder होना चाहिए, जैसे https://example.com/reward?userid=[userId]। Debug मोड में postback नहीं भेजा जाता।

6. विज्ञापन ऐसी जगह लगाना जहाँ यूज़र उसे देख न सके

प्लेसमेंट के नियम डिज़ाइन के नहीं, visibility के हैं। AdsGram पर impression तब गिना जाता है जब ब्लॉक कम से कम 50% दिख रहा हो और लगातार 2 सेकंड तक देखा गया हो।

कैसे बचें: विज्ञापन ब्लॉक को collapsed, स्क्रीन से बाहर या ज़ीरो-height कंटेनर में कभी render न करें, एक ही हिस्से में कई ब्लॉक एक के ऊपर एक न रखें, और Mini App minimize होने पर show ट्रिगर न करें। AdsGram एक ऐप में 10 ad units तक बनाने देता है। यह context के हिसाब से प्लेसमेंट अलग करने के लिए काफ़ी है: एक लेवल पूरा होने पर, एक डेली बोनस के लिए, एक टास्क लिस्ट के लिए, हर जगह एक ही ब्लॉक चलाने के बजाय।

लॉन्च और मॉडरेशन की गलतियाँ

ज़्यादातर रिजेक्शन इसलिए होते हैं कि ऐप अधूरा है, इसलिए नहीं कि वह कोई नियम तोड़ता है। AdsGram पर मॉडरेशन के दौरान Mini App का लिंक और बॉट काम करने चाहिए। मॉडरेशन आम तौर पर वर्किंग डे पर 4–6 घंटे और वीकेंड पर 6–10 घंटे लेता है, और मॉडरेटर 08:00 से 22:00 UTC (भारत में 13:30 से 03:30 IST) के बीच काम करते हैं।

लॉन्च के समय की आम गलतियाँ:

• ऐसा बिल्ड भेजना जो लॉगिन या whitelist के पीछे है, जिससे मॉडरेटर को error स्क्रीन दिखती है।
• यह साफ़ न बताना कि विज्ञापन ऐप में कहाँ दिखेगा (कौन-सी स्क्रीन, कौन-सा ब्लॉक, किस पल)। AdsGram के मॉडरेशन नियमों के अनुसार ऐसा प्लेटफ़ॉर्म तब तक decline रहता है, जब तक प्लेसमेंट की जगह साफ़ न हो।
• ऐसा ऐप भेजना जो सिर्फ़ टेम्पलेट है (open-source रिपॉज़िटरी से कॉपी किया गया भी) या जिसमें विज्ञापन के अलावा कोई काम नहीं है। ऐसे ऐप पास नहीं होते।
• ऐप की बुनियादी सुविधाएँ विज्ञापन देखने की शर्त पर रखना। Rewarded ब्लॉक के लिए नियम है: बेसिक फ़ंक्शन बिना विज्ञापन के चलें, और यह साफ़ दिखे कि बोनस के लिए विज्ञापन देखना है।
• यूज़र्स को असली पेआउट का भरोसेमंद सबूत न देना (pinned मैसेज, पब्लिक leaderboard या पेआउट वाला चैनल), या बहुत ज़्यादा, अवास्तविक रिवॉर्ड का वादा करना।
• सिर्फ़ एक प्लेटफ़ॉर्म पर टूटा फ़्लो, ज़्यादातर iOS कीबोर्ड हैंडलिंग या डेस्कटॉप लेआउट।
• नियम पढ़े बिना पेआउट की उम्मीदें। AdsGram डिफ़ॉल्ट रूप से TON नेटवर्क पर USDT में पेआउट देता है; USDT TRC20 और फ़िएट ट्रांसफ़र सपोर्ट से बात करके मिल सकते हैं। निकासी 10 USDT से शुरू होती है: 10–99.99 USDT महीने में एक बार, 1 से 5 तारीख के बीच, और 100 USDT या ज़्यादा किसी भी दिन। रिक्वेस्ट 1–3 वर्किंग डे में प्रोसेस होती है।
• टैक्स का हिसाब न रखना। भारत में USDT एक Virtual Digital Asset (VDA) है: इसकी बिक्री या ट्रांसफ़र से हुई आय पर 30% फ़्लैट टैक्स लगता है और ट्रांसफ़र पर 1% TDS कटता है (Budget 2026 में यह नियम नहीं बदला)। हिसाब पहले से अपने CA के साथ तय करें। यह कानूनी या टैक्स सलाह नहीं है।
• विज्ञापन funnel पर analytics न होना, जिससे यह समझना असंभव हो जाता है कि समस्या कम fill है या टूटा प्लेसमेंट। अगर आप इंटीग्रेशन से पहले नेटवर्क की तुलना कर रहे हैं, तो AdsGram vs Monetag तुलना में बताया गया है कि क्या मापना है।

लक्षण और कारण: डायग्नोसिस टेबल

रिलीज़ से पहले की चेकलिस्ट

हर deploy से पहले ये 10 पॉइंट जाँचें:

1. initData सर्वर पर वेरिफ़ाई होता है, और auth_date की freshness विंडो तय है।
2. Session, बैलेंस और रिवॉर्ड backend पर हैं, localStorage में नहीं।
3. Telegram.WebApp की सभी कॉल्स Mini App के रजिस्टर्ड डोमेन से होती हैं।
4. लेआउट viewportStableHeight, safeAreaInset और contentSafeAreaInset पर बना है, 100vh पर नहीं।
5. न्यूनतम Bot API वर्ज़न तय है, और नए फ़ीचर isVersionAtLeast() के पीछे हैं।
6. बिल्ड को असली Android (बजट फ़ोन समेत), iOS और डेस्कटॉप client पर चलाया गया है।
7. startapp पैरामीटर से referral या बोनस सिर्फ़ वेरिफ़ाई किए गए initData के बाद मिलता है।
8. AdsGram SDK में debug: false है, और हर blockId के लिए init() एक बार कॉल होता है।
9. show() का catch() और onBannerNotFound हैंडल हैं, और बिना विज्ञापन वाला रास्ता मौजूद है।
10. मॉडरेशन के लिए ऐप खुला है, विज्ञापन की जगह साफ़ बताई गई है, और पेआउट का सबूत दिखता है।

इन्हें लॉन्च से पहले ठीक करना सपोर्ट टिकटों के ज़रिए ढूँढने से सस्ता है। यही फ़र्क़ है "बस चलने वाले" Mini App और यूज़र्स को रोकने और कमाने वाले Mini App में। जब तकनीकी आधार स्थिर हो जाता है, तो Telegram Mini Apps monetization बचाव अभियान नहीं, बल्कि सिर्फ़ कॉन्फ़िगरेशन का काम रह जाता है। Mini Apps में विज्ञापन कैसे काम करता है और उसे कैसे बेचा जाता है, यह Telegram Mini Apps में विज्ञापन: यह कैसे काम करता है में विस्तार से पढ़ें। अगर आप Mini App पहली बार लॉन्च कर रहे हैं, तो Telegram Web App लॉन्च करने की पूरी गाइड से शुरुआत करें।

FAQ

मेरा Telegram Mini App क्यों नहीं खुल रहा?
आम कारण हैं: fail हुआ init, पहले render से पहले बिना हैंडल की गई error, या client storage के साथ session खो जाना। जाँचें कि ऐप का URL HTTPS पर खुलता है, कोई भी Telegram API कॉल SDK तैयार होने के बाद ही होती है, और कोई कोड इस भरोसे पर नहीं चलता कि localStorage restart के बाद बचा रहेगा। अगर ऐप Android पर खुलता है पर iOS पर नहीं, तो उसी बिल्ड को Safari Web Inspector से टेस्ट करें।

Telegram Mini App को ब्राउज़र में कैसे खोलें और टेस्ट करें?
Telegram के बाहर लॉन्च पैरामीटर नहीं होते, इसलिए SDK बताता है कि वह उन्हें प्राप्त नहीं कर पा रहा। लोकल काम के लिए environment check चलाएँ और Telegram environment को mock करें, ताकि ऐप आम ब्राउज़र में render हो। अपने dev सर्वर को VS Code dev tunnel या ngrok जैसे tunnel से बाहर खोलें, उस HTTPS URL को BotFather में सेट करें और ऐप को बॉट से खोलें।

Telegram Mini App में init data कैसे वेरिफ़ाई करें? raw initData स्ट्रिंग अपने backend पर भेजें। hash को छोड़कर सभी key-value जोड़ों से data-check string बनाएँ (alphabetically sort करके, newline से जोड़कर), HMAC-SHA256(bot_token, "WebAppData") से secret निकालें, HMAC-SHA256(data_check_string, secret) कैलकुलेट करें और उसकी hash से तुलना करें। जिन payloads का auth_date आपकी freshness विंडो से बाहर है, उन्हें रिजेक्ट करें, फिर अपना session टोकन जारी करें।

iOS और Android पर Telegram Mini App को debug कैसे करें?
Android के लिए USB remote debugging के साथ Chrome DevTools और iOS के लिए Safari Web Inspector इस्तेमाल करें। जब दोनों उपलब्ध न हों (टेस्टर का फ़ोन, किसी और के डिवाइस पर बिल्ड), तो Eruda जैसा इन-ऐप कंसोल जोड़ें, ताकि runtime errors बिना केबल के दिखें। हर बग को असली Telegram client पर दोहराकर देखें, क्योंकि Telegram Web ज़्यादातर WebView-specific बर्ताव छिपा देता है।

क्या Telegram Mini App में localStorage इस्तेमाल कर सकते हैं?
Telegram के WebView में iOS और कुछ डेस्कटॉप बिल्ड पर localStorage persist नहीं होता, इसलिए restart से वह साफ़ हो सकता है। अकाउंट के साथ चलने वाली यूज़र सेटिंग्स के लिए CloudStorage, लोकल स्टोरेज के लिए Bot API 9.0 से DeviceStorage या SecureStorage, और sessions, बैलेंस और किसी भी entitlement के लिए अपना backend इस्तेमाल करें।

क्या Bot API 10.2 मौजूदा Mini Apps को तोड़ता है?
तोड़ सकता है। 14 जुलाई 2026 को जारी Bot API 10.2 Mini App के मूल डोमेन के अलावा किसी दूसरे origin से Mini App methods इस्तेमाल करने की अनुमति नहीं देता; सुरक्षा 20 जुलाई 2026 से लागू है। जो ऐप Telegram.WebApp methods को embedded iframe, पार्टनर पेज या दूसरे डोमेन से कॉल करते हैं, अपडेटेड clients पर उनकी ये कॉल्स fail होंगी। @BotFather से अस्थायी opt out संभव है, लेकिन सही हल यह है कि सभी Telegram API कॉल्स रजिस्टर्ड डोमेन पर रखें और third parties के साथ डेटा अपने backend के ज़रिए भेजें।