Refund मिलेगा या नहीं, यह Apple तय करता है। Policy आपके ऊपर जो छोड़ती है, वह है उस फैसले के आसपास होने वाली हर चीज़, और ज़्यादातर टाला जा सकने वाला नुकसान वहीं छिपा होता है।
यह कहानी हम किसी न किसी रूप में अक्सर सुनते हैं। एक यूज़र मार्च में Apple से refund मांगता है। Apple हां कह देता है। डेवलपर के server को इसकी खबर कभी नहीं लगती। जून तक वही यूज़र ऐप का paid वर्ज़न इस्तेमाल कर रहा होता है। किसी को तब तक पता नहीं चलता जब तक finance टीम तिमाही के अंत में जांच नहीं करती, और तब भी यह समझने में समय लगता है कि हुआ क्या था। Refund payout report में दर्ज है। Access का रिकॉर्ड ऐप के अपने database में पड़ा है। दोनों कभी एक-दूसरे से बात नहीं करते।
ज़्यादातर डेवलपर्स App Store refund policy के बारे में ऐसे ही सीखते हैं। उसे पढ़कर नहीं, बल्कि महीनों बाद यह पता चलने पर कि उसमें क्या कभी शामिल था ही नहीं।
यहां वह हिस्सा है जो policy साफ़ नहीं बताती। Apple का payment को reverse करना और आपके ऐप का access हटाना, ये दो अलग-अलग घटनाएं हैं। पहली Apple संभालता है। दूसरी आप संभालते हैं। इन दोनों के बीच का अंतर ही वह जगह है जहां डेवलपर्स चुपचाप, महीने-दर-महीने पैसा गंवाते हैं। इस लेख का ज़्यादातर हिस्सा इसी अंतर को बंद करने के बारे में है।
तो यह पोस्ट policy को डेवलपर की नज़र से देखती है: Apple क्या नियंत्रित करता है, क्या आपके हिस्से आता है, और refund हो जाने के बाद आपके systems को क्या करना चाहिए। अगर आप policy के बजाय व्यावहारिक पक्ष पढ़ना चाहते हैं, तो हमारी गाइड मोबाइल ऐप revenue गंवाए बिना App Store refunds को manage करें उसे कवर करती है।
मुख्य बातें
● Apple हर refund का फैसला करता है। App Store Connect में refund को approve या reject करने का कोई बटन नहीं है, क्योंकि यह चुनाव कभी डेवलपर का था ही नहीं।
● ग्राहक कहां रहता है, इससे नतीजा बदल सकता है। Apple की Media Services Terms and Conditions के तहत eligibility और प्रक्रिया देश या क्षेत्र के हिसाब से अलग होती है।
● Apple आपके server को refund से जुड़ी notifications भेज सकता है, और request की समीक्षा करते समय यह पूछ सकता है कि खरीदारी का इस्तेमाल कैसे हुआ।
● जवाब देने के लिए आपके पास 12 घंटे होते हैं, और वह भी सिर्फ़ तब जब ग्राहक ने वह जानकारी साझा करने की अनुमति दी हो।
● Apple जिस refund को approve करता है और आपका database जिस refund को दर्ज करता है, ये दो अलग घटनाएं हैं। इनके बीच की जगह से ही पैसा रिसता है।
● Automation आपकी तरफ़ की प्रक्रिया को तेज़ और ज़्यादा consistent बना सकता है। Apple के फैसले पर इसका कोई असर नहीं पड़ता।
App Store refund policy क्या है?
संक्षेप में, यह उन नियमों का समूह है जो तय करते हैं कि Apple ग्राहक की refund request को कैसे संभालता है, साथ ही तकनीकी कामों की एक सूची जो डेवलपर के हिस्से आती है।
Refund approve होगा या नहीं, यह Apple तय करता है। इसमें आपकी कोई राय नहीं चलती। आप न किसी request को approve कर सकते हैं, न रोक सकते हैं। App Store Connect में ऐसी कोई स्क्रीन नहीं है जहां डेवलपर इस पर वोट करे। आप ज़्यादा से ज़्यादा प्रक्रिया के दौरान कुछ बिंदुओं पर Apple को कुछ जानकारी भेज सकते हैं, और इस पर हम थोड़ी देर में आएंगे। अगर आप देखना चाहते हैं कि ग्राहक असल में request कैसे भेजते हैं, तो वह Apple की ऐप्स या कंटेंट के लिए refund request करने की गाइड में बताया गया है।
हम आमतौर पर टीमों के लिए policy को चार हिस्सों में बांटते हैं, क्योंकि चार में से सिर्फ़ दो ही असल में आपकी समस्या हैं।
पहला हिस्सा है eligibility। Requests सीधे Apple के पास जाती हैं, आपके पास कभी नहीं। ग्राहक के देश या क्षेत्र के हिसाब से eligibility बदल सकती है, और नियम Apple Media Services Terms and Conditions के अंदर मौजूद हैं। तो अगर कोई यूज़र पूछे कि उसका refund क्यों मिल गया लेकिन उसके दोस्त का नहीं, तो इसका कोई सीधा जवाब नहीं है। यह इस पर निर्भर करता है कि दोनों कहां रहते हैं।
दूसरा हिस्सा है खुद फैसला। यह पूरी तरह Apple का काम है। आपको इसका पता फैसला हो जाने के बाद ही चलता है।
तीसरा हिस्सा है आपकी ज़िम्मेदारियां, और ये तकनीकी हैं, कानूनी नहीं, एक ऐसी बात जो लगभग हर बार लोगों को चौंका देती है। ऐसा server चलाएं जो notifications receive कर सके। Apple मांगे तो जानकारी दें। साफ़-सुथरे रिकॉर्ड रखें। बस, यही पूरा काम है।
चौथा हिस्सा है फैसले के बाद entitlements का क्या होता है, और यही वह हिस्सा है जिसमें असल में पैसा जाता है। Apple के payment reverse करने से आपके अपने database में अपने आप कुछ नहीं बदलता। जिस ग्राहक को refund मिल गया लेकिन paid access हमेशा के लिए बना रहा, वह Apple की policy की विफलता नहीं है। वह आपके system की बनावट में एक कमी है।
आप शायद अंदाज़ा लगा सकते हैं कि हमारे लिए कौन सा हिस्सा सबसे ज़्यादा मायने रखता है।
डेवलपर्स के लिए Apple App Store की refund प्रक्रिया कैसे काम करती है?
ग्राहक इसे शुरू करता है। Apple इसे खत्म करता है। आप कहीं बीच में होते हैं।
ग्राहक Apple के ज़रिए refund request करता है
↓
Apple request की समीक्षा करता है
↓
आपके server को refund से जुड़ी notification मिल सकती है
↓
लागू हो तो आप सहायक जानकारी देते हैं
↓
Apple अपना फैसला करता है
↓
आपको नतीजा notification के रूप में मिलता है
↓
Entitlement और access अपडेट होते हैं
यहां दो बातों पर ध्यान देना ज़रूरी है। Apple ग्राहकों से कहता है कि जवाब लगभग 24 से 48 घंटे में मिलेगा, और इस timeline का आपकी timeline से कोई लेना-देना नहीं है, इसलिए request pending रहते हुए आपकी support टीम क्या वादा करती है, इस पर सावधान रहें। और ऊपर का हर कदम तभी काम करता है जब आपका server वाकई सेट अप और reachable हो। बहुत सी टीमों को बाद में पता चलता है कि उनका नहीं था। अगर आपका endpoint डाउन है, तो refund फिर भी होता है। बस आपको इसकी खबर कभी नहीं मिलती।
App Store refund नियमों का डेवलपर्स के लिए क्या मतलब है?
Policy की भाषा हटा दें, तो ये नियम आपकी engineering टीम के लिए एक छोटी, काफ़ी साधारण checklist बन जाते हैं।
● ऐसे transaction रिकॉर्ड जिन्हें आप वाकई खोज सकें। Refund notifications में Apple के transaction identifiers का हवाला होता है। अगर आपने खरीदारी के समय उन्हें सेव नहीं किया, तो notification लगभग बेकार है। आपको हर transaction और user account के बीच एक भरोसेमंद लिंक भी चाहिए, क्योंकि Apple का payload खरीदारी की पहचान करता है, खरीदने वाले व्यक्ति की नहीं।
● ऐसा notifications endpoint जो काम करे और signatures की जांच करे। Refund events App Store Server Notifications के ज़रिए आते हैं, और payloads signed होते हैं। हर बार उन signatures की जांच करें। जो endpoint उसे भेजी गई हर चीज़ पर भरोसा कर लेता है, वह एक URL वाला security risk है।
● पहले से तैयार किया गया consent flow। अगर Apple consumption information मांगता है, तो आप सिर्फ़ वहीं जवाब दे सकते हैं जहां ग्राहक ने पहले ही वह data साझा करने की सहमति दी हो। यह ज़िम्मेदारी आपकी है। Apple का Send Consumption Information documentation इस बारे में स्पष्ट है, और consent के बिना भेजा गया कोई भी response reject कर दिया जाता है। Request आ जाने के बाद आप पीछे जाकर consent इकट्ठा भी नहीं कर सकते। या तो खरीदारी के समय आपके पास consent था, या फिर उस request में आप हिस्सा नहीं ले पाते।
● ऐसा entitlement logic जो दोनों दिशाओं में काम करे। Refunds कभी-कभी reverse भी हो जाते हैं। Apple partial refunds की भी अनुमति देता है, जिसमें खरीदारी का सिर्फ़ एक हिस्सा लौटाया जाता है। Full, partial या reversed, आपके code को तीनों संभालने होंगे।
● नतीजों के लिए ऐसी जगह जिसे finance टीम वाकई इस्तेमाल कर सके। जो refund सिर्फ़ ऐप के database में मौजूद है, वह payout report से कभी मेल नहीं खाएगा। ज़्यादातर टीमों को यह तिमाही बंद होते समय पता चलता है, और वह दिन शायद ही कभी अच्छा होता है।
Apple की refund policy डेवलपर्स को कैसे प्रभावित करती है?
सब refund की रकम पर ध्यान देते हैं। यह आमतौर पर इस पूरी कहानी का सबसे छोटा आंकड़ा होता है।
Refund हुई subscription अवधि वह revenue वापस ले लेती है जिसे आप पहले ही गिन चुके थे, और ज़्यादातर मामलों में रिश्ता भी वहीं खत्म हो जाता है। जिन renewals की आप उम्मीद कर रहे थे, वे चुपचाप आना बंद कर देते हैं। One-time purchases सरल हैं, लेकिन वे भी बिक्री के बाद आते हैं, इसलिए gross आंकड़ों पर बनी कोई भी reporting तब तक बढ़ा-चढ़ाकर दिखाएगी जब तक refunds घटाए न जाएं।
इस पूरे लेख में याद रखने लायक फ़र्क यह है। Apple जिस refund को approve करता है और आपका system जिस refund को असल में दर्ज करता है, ये दो अलग घटनाएं हैं। Apple का हिस्सा अपने schedule पर होता है, चाहे कोई देख रहा हो या नहीं। आपका हिस्सा सिर्फ़ तब होता है जब notification handler चला, transaction मैच हुआ, account मिला और access अपडेट हुआ। इनमें से कोई एक कड़ी छूटी और काम आधा ही हुआ, और बाहर से कोई नहीं बता सकता कि कौन सा आधा।
इस अंतर का एक नाम है: refund leakage। ये वे ग्राहक हैं जिन्हें पैसा वापस मिल गया और जिन्होंने वह सब भी रख लिया जिसके लिए उन्होंने भुगतान किया था। वे इसकी शिकायत नहीं करेंगे, क्योंकि उनकी नज़र में कुछ गलत है ही नहीं। यह महीनों बाद reconciliation के दौरान सामने आता है, अगर कभी सामने आता भी है तो।
बाकी सब कुछ इसी अंतर से निकलता है। Support agents ऐसे tickets का जवाब दे रहे हैं जिनके लिए जांचने को कोई refund रिकॉर्ड नहीं है। Analytics जो lifetime value को बढ़ा-चढ़ाकर दिखाते हैं क्योंकि reversals कभी आंकड़ों तक पहुंचे ही नहीं। पीछे मुड़कर देखने के लिए कोई refund history नहीं, इसलिए किसी को पता नहीं चलता कि कोई एक product बाकियों से कहीं ज़्यादा refunds ला रहा है।
Apple refund request आने पर डेवलपर्स को क्या करना चाहिए?
सात कदम। ज़्यादातर काम किसी भी request के आने से काफ़ी पहले होता है।
1. Notification receive करें और जांचें
Refund events आपके endpoint पर signed JWS payloads के रूप में आते हैं। Apple की certificate chain के आधार पर signature की जांच करें। Bundle ID की पुष्टि करें। उसके बाद ही अंदर की जानकारी पर कार्रवाई करें। यह बुनियादी hygiene है, और टीमें फिर भी इसे छोड़ देती हैं। जो endpoint उसे दी गई हर चीज़ स्वीकार कर लेता है, उसका फ़ायदा कोई और भी उठा सकता है।
2. Transaction और account खोजें
Payload से transaction identifiers लें और उन्हें अपने purchase रिकॉर्ड से मिलाएं। अगर आपने खरीदारी के समय एक stable account token जोड़ा था, तो यह एक lookup का काम है। अगर नहीं, तो आप समय के दबाव में अंदाज़ा लगा रहे हैं।
3. खरीदारी के बारे में जो आप पहले से जानते हैं, उसे जांचें
जब तक आपको यह पता न हो कि आपके अपने systems ने क्या दर्ज किया, आप Apple को कुछ भी उपयोगी नहीं बता सकते। क्या content deliver हुआ? क्या उसने उम्मीद के मुताबिक काम किया? ग्राहक ने असल में उसका कितना इस्तेमाल किया? अगर आप अपने रिकॉर्ड से इनके जवाब नहीं दे सकते, तो यही आपकी पहली असली समस्या है, refund नहीं।
4. Apple के मांगने और consent मौजूद होने पर consumption information भेजें
Apple की CONSUMPTION_REQUEST notification का मतलब है कि आप खरीदारी के इस्तेमाल के बारे में जानकारी के साथ जवाब दे सकते हैं, लेकिन सिर्फ़ तब जब दो बातें सच हों: ग्राहक ने वैध consent दिया हो, और आप Apple की तय की गई 12 घंटे की window के अंदर हों। Apple का मौजूदा documentation इस notification को सभी product types की refund requests से जोड़ता है, इसलिए अपना handler यह मानकर न बनाएं कि यह हमेशा आएगी ही। आप जो भी भेजें, वह सीधे आपके रिकॉर्ड से आना चाहिए, मोटा-मोटी अंदाज़ा नहीं।
5. अंतिम नतीजे को track करें
नतीजा notification के रूप में आता है। REFUND का मतलब है कि refund मंज़ूर हुआ। REFUND_DECLINED का मतलब है कि नहीं हुआ। REFUND_REVERSED का मतलब है कि Apple ने पहले से मंज़ूर किया गया refund reverse कर दिया। तीनों नतीजे सेव करें। Reversal वाला मामला टीमें सबसे ज़्यादा भूलती हैं, और एक छूटा हुआ reversal किसी paying ग्राहक को उस चीज़ से बाहर कर सकता है जो असल में उसकी है।
6. Entitlement और access अपडेट करें
Refund मंज़ूर होने पर access हटाएं। Refund reverse होने पर उसे बहाल करें। Partial मामले को संभालें, जहां सिर्फ़ एक प्रतिशत हिस्सा वापस आता है। और इसे server-side events से चलाएं, ताकि ग्राहक का access सही बना रहे, चाहे वह दोबारा ऐप खोले या नहीं।
7. Revenue और subscription reporting से reconcile करें
Refund को सही अवधि और सही product से मिलाएं। यह कदम छोड़ दें, तो finance और engineering एक ही महीने के दो अलग-अलग संस्करण देख रहे होते हैं। जो कोई भी उस मीटिंग में बैठ चुका है, वह जानता है कि इससे बचना ही बेहतर है।
Manual App Store refund management मुश्किल क्यों हो जाता है
यह लापरवाही की बात नहीं है। बस ये constraints ऐसी प्रक्रिया के लिए ठीक नहीं बैठतीं जो इस पर निर्भर हो कि कोई चौबीसों घंटे जागकर ध्यान दे रहा हो।
Refund requests तब आती हैं जब ग्राहक भेजते हैं। रविवार की सुबह। रात के दो बजे। छुट्टियों में। Response window किसी के schedule के लिए नहीं रुकती। हर request के लिए एक transaction lookup, एक account match, एक consent check, एक usage number और एक entitlement update चाहिए। अच्छे दिन में यह करीब पांच मिनट का काम है। लेकिन यह समय-संवेदनशील है, दोहराव वाला है, और सही होने पर पूरी तरह अदृश्य है। सुबह 4 बजे सही ढंग से संभाले गए refund के लिए किसी को धन्यवाद नहीं मिलता।
Volume इसे और मुश्किल बनाता है। एक से ज़्यादा ऐप चलाना भी, जहां transaction data एक system में है और account data दूसरे में। फिर जो engineer handler को समझता था, वह टीम बदल लेता है। Tracking spreadsheet को refunds_OLD_final_v2 जैसा नाम मिल जाता है और वह चुपचाप खुलनी बंद हो जाती है। Finance टीम को यह अंतर तिमाही बंद होते समय मिलता है, उस समय से करीब तीन महीने बाद जब कोई अब भी कुछ कर सकता था।
डेवलपर्स App Store refunds को ज़्यादा भरोसेमंद तरीके से कैसे manage कर सकते हैं?
Manual monitoring कुछ ऐसी दिखती है: कोई dashboard खोलता है, एक transaction देखता है, एक रिकॉर्ड अपडेट करता है और आगे बढ़ जाता है। कम volume पर यह ठीक काम करती है, और यही जाल है, क्योंकि यह किसी धमाके के साथ नहीं टूटती। यह धीरे-धीरे फीकी पड़ती है। ऐसा कोई एक पल नहीं होता जब यह काम करना बंद कर दे, इसलिए कोई इसे समय रहते पकड़ नहीं पाता।
Automation यांत्रिक कदमों को लोगों के ज़िम्मे से हटा देता है: notifications receive और verify करना, transactions को accounts से मिलाना, response data तैयार करना, response windows track करना, नतीजे दर्ज करना और entitlements को sync रखना।
जो यह नहीं कर सकता, वह है Apple का फैसला बदलना। Automation से refunds की संभावना कम नहीं होती, और यह किसी फैसले को प्रभावित नहीं कर सकता, चाहे कुछ tools कुछ भी दावा करें। यह सिर्फ़ इतना बदलता है कि आपकी तरफ़ की प्रक्रिया लगातार और समय पर होती है या नहीं, और अपने आप में यह ठीक करने लायक एक अहम चीज़ है।
App Store refund management वह श्रेणी है जिसके तहत यह काम आता है, और यह साफ़ कहना ज़रूरी है कि इस क्षेत्र के किसी tool को क्या कवर करना चाहिए: notification handling, transactions को users से मिलाना, consent और timing का सम्मान करने वाले response workflows, बाद में देखने लायक refund history, और full, partial और reversed refunds को संभालने वाले entitlement updates।
RefundSensor काम के इसी हिस्से को कवर करता है। यह App Store और Google Play के refund events को एक automated workflow से जोड़ता है, ताकि responses store की window के अंदर चले जाएं और किसी को हाथ से notifications देखने न पड़ें, और volume बढ़ने पर भी refund रिकॉर्ड सटीक बने रहें। यह Apple के फैसले को नहीं बदलेगा, क्योंकि कुछ भी नहीं बदल सकता। यह बदलता है कि हर refund के बाद आपकी टीम के लिए कितना काम बचता है।
ये नियम कहां documented हैं
ऊपर की हर बात के पीछे Apple के तीन स्रोत हैं। कुछ भी बनाने से पहले उन्हें खुद पढ़ें, और समय-समय पर दोबारा देखते रहें, क्योंकि यह क्षेत्र पहले ही एक से ज़्यादा बार बदल चुका है।
ऐप्स या कंटेंट के लिए refund request करें — वह policy जो ग्राहक देखते हैं। इसमें requests कैसे भेजी जाती हैं, 24 से 48 घंटे की update window और क्षेत्रीय eligibility पर Apple की टिप्पणी शामिल है।
Send Consumption Information — डेवलपर के लिए response workflow। इसमें consent की शर्त, 12 घंटे की window और request fields शामिल हैं। Consumption handling को छूने से पहले इसे पूरा पढ़ना ज़रूरी है।
App Store Server Notifications — refund events आपके backend तक कैसे पहुंचते हैं। इसमें signed payload format और notification types शामिल हैं, जिनमें CONSUMPTION_REQUEST, REFUND, REFUND_DECLINED और REFUND_REVERSED भी हैं।
अगर refund events अब भी हाथ से जांचे जा रहे हैं
Manual monitoring ठीक काम करती है, ठीक तब तक जब तक करना बंद न कर दे, और यह विफलता आमतौर पर चुपचाप होती है। एक notification जो किसी ने नहीं देखी। एक window जो रात 3 बजे बंद हो गई। एक refund पा चुका ग्राहक जिसका access पूरी तिमाही बना रहा।
अगर यह जाना-पहचाना लगता है, तो RefundSensor refund workflow को manual tracking से हटा सकता है: store events, response windows, और यह सुनिश्चित करना कि नतीजे आपके रिकॉर्ड और आपके entitlement logic दोनों तक पहुंचें।
अक्सर पूछे जाने वाले प्रश्न
यह उन नियमों का समूह है जो तय करते हैं कि Apple ग्राहकों की refund requests को कैसे संभालता है, साथ ही वह तकनीकी काम जो इनके आसपास डेवलपर्स के हिस्से आता है। नतीजा Apple तय करता है। डेवलपर्स उसके आसपास का ढांचा संभालते हैं: notifications receive करना, मांगे जाने और consent होने पर consumption information भेजना, और फैसला आने के बाद access और रिकॉर्ड अपडेट करना।
नहीं, और चाहें तो भी ऐसा करने का कोई तरीका नहीं है। हर एक request पर अंतिम फैसला Apple करता है। मौजूदा consumption endpoint आपको एक पसंदीदा नतीजा संकेत करने देता है, लेकिन वह कई inputs में से एक है, कोई निर्देश नहीं। Apple फिर भी अलग फैसला कर सकता है।
ग्राहक Apple को request भेजता है। Apple उसकी समीक्षा करता है और consumption information के लिए आपके server से संपर्क कर सकता है। जहां consent मौजूद है, वहां आप Apple की तय window के अंदर जवाब देते हैं। Apple फैसला करता है, नतीजे को अपनी अलग notification के रूप में भेजता है, और आपके systems ग्राहक के entitlement और आपके रिकॉर्ड को उस फैसले के अनुरूप कर देते हैं।
हां, लेकिन सिर्फ़ एक सीमित तरीके से। जब CONSUMPTION_REQUEST notification आती है, तो Apple यह जानकारी चाहता है कि खरीदारी का इस्तेमाल कैसे हुआ। आपके response के लिए ग्राहक का वैध consent होना चाहिए, वह सटीक होना चाहिए, और Apple की window के अंदर जाना चाहिए। यह समीक्षा को जानकारी देता है। फैसला नहीं करता।
यह एक App Store Server Notification है जो refund request की समीक्षा के दौरान आपके server से खरीदारी के बारे में जानकारी मांगती है। यह खुद refund नहीं है, और न ही कोई फैसला है। जवाब देने के लिए आपके पास 12 घंटे होते हैं, और वह भी सिर्फ़ तब जब ग्राहक ने वह data साझा करने की सहमति दी हो।
दो तरह से। सीधे तौर पर, refund हुई अवधि का revenue reverse हो जाता है। परोक्ष रूप से, रिश्ता आमतौर पर वहीं खत्म हो जाता है, इसलिए जिन renewals पर आप भरोसा कर रहे थे, वे कभी नहीं आते। Gross renewals पर आधारित reporting तब तक revenue को बढ़ा-चढ़ाकर दिखाती है जब तक refunds घटाए न जाएं, और lifetime value में भी वही गलती आगे बढ़ती जाती है।
तीन काम, फिर दो बातों पर नज़र। नतीजे को transaction और ग्राहक के रिकॉर्ड में दर्ज करें। संबंधित entitlement हटाएं। Refund को सही अवधि की revenue reporting में शामिल करें। फिर partial मामले को संभालें, जहां transaction का सिर्फ़ एक हिस्सा लौटाया जाता है, और restore path तैयार रखें, क्योंकि Apple बाद में refund को reverse भी कर सकता है।
यांत्रिक हिस्सों को, हां, पूरी तरह। Notifications verify करना, transactions को accounts से मिलाना, response windows track करना, entitlements अपडेट करना, refund history रखना। यह सब automate करने लायक पर्याप्त predictable है। जो इंसानों के हाथ में रहना चाहिए, वह है consent flow को design करना और अपने refund patterns को वाकई पढ़ना, क्योंकि वे product के बारे में कुछ असली बताते हैं।
