BillingMeld: کیوں خریداری سرور کو چیک کرنا چاہئے، نہ کہ ایپلیکیشن

موبائل ایپ میں اندرونی خریداری عام طور پر صارف کے لئے آسان لگتی ہے۔ وہ بٹن پر کلک کرتا ہے، ادائیگی کی تصدیق کرتا ہے، فنکشن یا سبسکرپشن تک رسائی حاصل کرتا ہے — اور امید کرتا ہے کہ آگے سب خود بخود چلتا رہے گا۔

لیکن اس بٹن کے پیچھے ڈویلپر کے لیے بہت زیادہ پیچیدہ عمل شروع ہوتا ہے۔ اسے خود خریداری کی تصدیق کرنی ہوتی ہے، تجدیدات کا حساب رکھنا ہوتا ہے، سبسکرپشن کے خاتمے، واپس لینے، عمل کی رائے، آلہ کی تبدیلی اور Apple اور Google کے درمیان فرق کو نظر میں رکھنا ہوتا ہے۔

اہم مسئلہ اس وقت پیدا ہوتا ہے جب سرور کلائنٹ ایپ کو سچائی کا ماخذ سمجھنا شروع کر دیتا ہے۔

اگر ایپلیکیشن نے اطلاع دی: «خریداری مکمل ہو گئی»، تو سرور رسائی دے دیتا ہے اور ایک بار موصولہ حالت پر منحصر رہتا ہے۔ لیکن خریداری کا زندگی کا چکر یہاں ختم نہیں ہوتا ہے۔

سبسکرپشن کو بڑھایا جا سکتا ہے، خودکار تجدید بند کی جا سکتی ہے، ادائیگی واپس لی جا سکتی ہے، یا آپریشن کو دکان واپس لے سکتی ہے۔

اسی لیے BillingMeld میں خریداری تصدیق سرور کرتا ہے، نہ کہ ایپلیکیشن۔

کلائنٹ اطلاع دیتا ہے، لیکن فیصلہ نہیں کرتا

BillingMeld کے آرکیٹیکچر میں موبائل ایپ مرکزی معلومات کا ماخذ نہیں ہے۔

کلائنٹ ممکنہ طور پر مکمل عمل کی معلومات فراہم کر سکتا ہے، لیکن یہ صرف تصدیق کا بنیاد ہوتا ہے۔ حتمی فیصلہ BillingMeld کا سرور حصہ کرتا ہے، جو Apple یا Google کے ذریعے معلومات کی تصدیق کرتا ہے۔

یہ بنیادی فرق ہے۔

موبائل پر ایپ پرانا حالت کے ساتھ کام کر سکتی ہے، تازہ ترین تبدیلیاں وقت پر حاصل نہیں کر سکتی، یا ایسی معلومات فراہم کر سکتی ہے جو موجودہ خریداری کی حالت سے میل نہیں کھاتیں۔

اس کے علاوہ، صارف کو یہ خود سے طے کرنے کا حق نہیں ہونا چاہئے کہ آیا اسے ادائیگی والا رسائی حاصل ہے یا نہیں۔

BillingMeld یہ تصدیق کرتا ہے کہ:

• کیا کوئی ایسی خریداری واقعی موجود ہے؛
• کیا یہ مطلوبہ ایپ اور پروڈکٹ سے متعلق ہے؛
• کیا ادائی شدہ مدت فی الحال فعال ہے؛
• کیا کوئی تجدید ہوئی؛
• کیا باقی خودکار تجدید بند کی گئی؛
• کیا واپس لیا گیا؛
• کیا آپریشن واپس لیا گیا؛
• کیا ادائیگی شدہ مدت ختم ہو گئی ہے۔

اس طرح، کلائنٹ کی اطلاع خریداری کا ثبوت نہیں رہتی بلکہ اس کی اصل حالت کی تصدیق کا سبب بنتی ہے۔

سرورز کے لیے واحد سچائی کا ماخذ

منسلک خدمات کو مکمل انٹیگریشنز کو بیک وقت Apple اور Google کے ساتھ انجام دینے کی ضرورت نہیں ہے۔

وہ BillingMeld سے رجوع کرتے ہیں اور خریداری کی ایک نیم المعیاری حالت حاصل کرتے ہیں۔

مثال کے طور پر: رسائی فعال ہے، ادائی شدہ مدت ختم ہو چکی ہے، تجدید کی تصدیق ہوئی ہے، خودکار تجدید بند ہے یا خریداری رد کر دی گئی ہے۔

یہ ذمہ داری کو واضح طور پر تقسیم کرنے کی اجازت دیتا ہے۔

Apple اور Google مرچنٹ کے عمل کی حالت کے ماخذ ہیں۔ BillingMeld ان ڈیٹا کی تصدیق کرتا ہے، انہیں ایک عام ماڈل میں لاتا ہے اور موجودہ حالت کو محفوظ کرتا ہے۔ اور حتمی فیصلے رسائی کے بارے میں اس حالت کے بنیاد پر لیے جاتے ہیں۔

پروڈکٹس کے سرورز کے لیے، اس کا مطلب ایک ہی معاہدہ ہوتا ہے بجائے کہ کئی آزاد انٹیگریشنز۔

ہر سروس میں App Store، Google Play کے قواعد کو الگ سے نافذ کرنے کی ضرورت نہیں، اور مختلف فارمیٹس، ایونٹس اور حالتوں کو ایک مشترکہ منطقی شکل میں لانے کی بھی نہیں۔

کلائنٹ پر مکمل اعتماد کیوں نہیں کرنا چاہئے

کلائنٹ ایپ صارف کے آلے پر کام کرتی ہے۔

اسے بند کیا جا سکتا ہے، دوبارہ شروع کیا جا سکتا ہے، بیک اپ سے بحال کیا جا سکتا ہے، بعد میں اپڈیٹ کیا جا سکتا ہے یا دوسرے آلے پر چلایا جا سکتا ہے۔ یہ کچھ وقت پر پرانی حالت کے ساتھ بھی کام کر سکتی ہے، یا وہ واقعہ نہیں لے سکتی جو پہلی خریداری کے بعد ہوا۔

بغیر صارف کے کسی مداخلت کے، یہ کلائنٹ کو حتمی حالت کا بدصورت ماخذ بننے سے روکتا ہے۔

مثلاً، صارف نے سبسکرپشن لی اور رسائی حاصل کی۔ پھر واپس لے لیا گیا یا Operation کو رد کیا گیا۔

اگر سرور صرف کلائنٹ کے پہلے پیغام کو جانتا ہے، تو وہ خریداری کو فعال سمجھنا جاری رکھے گا۔

دوسری صورت میں، صارف خودکار تجدید بند کر سکتا ہے۔ اس صورت میں، ادا شدہ مدت ابھی بھی فعال رہنی چاہیے، جب تک کہ وہ ختم نہ ہو جائے۔

اگر نظام صرف سادہ حالت یعنی «سبسکرپشن موجود ہے / نہیں» پر عمل کرے، تو یہ بہت جلد رسائی بند کر سکتا ہے یا استعمال کے حق کے ختم ہونے کے بعد بھی اسے برقرار رکھ سکتا ہے۔

BillingMeld اس طرح تیار کیا گیا ہے کہ صارف اپنے حقوق کی تصدیق نہیں کرتا بلکہ سافٹ ویئر اس کی افعال کے مطابق اصل حالت کی تصدیق کرتا ہے۔

خریداری ایک واحد واقعہ نہیں

بلنگ آرکیٹیکچر کی ایک بنیادی غلط فہمی ہے کہ خریداری ایک واحد واقعہ سمجھا جائے۔

درحقیقت، اس کا ایک زندہ رہنے والا چکر ہوتا ہے۔

سب سے پہلے ایک آپریشن ہوتا ہے۔ پھر اسے مرچنٹ تصدیق کرتا ہے۔ ایک فعال ادائیگی کی مدت شروع ہوتی ہے۔ پھر، ممکن ہے کہ تجدید ہو۔

اگر صارف خودکار تجدید بند کرتا ہے، تب بھی وہ ادائی شدہ مدت کے ختم ہونے تک سبسکرپشن استعمال کرتا رہے گا۔

Next renewal might fail, or a refund may be issued, or operation may be revoked.

اس لیے، یہ کسی بھی ایک واقعہ «یہ خریداری کبھی بھی موجود تھی» کو کافی نہیں بناتا۔

سرور کو سمجھنا ضروری ہے کہ اس وقت اس کے ساتھ کیا ہو رہا ہے۔

ری فنڈ کی اطلاع غفلت میں نہیں رہتی

یہ بات خاص طور پر واضح ہوتی ہے جب واپس لینے یا آپریشن کو رد کرنے کی بات آتی ہے۔

شروع میں، خریداری بالکل درست ہو سکتی ہے۔ صارف نے واقعی پروڈکٹ کی ادائیگی کی اور رسائی حاصل کی۔

لیکن پھر اس آپریشن کی حالت بدل سکتی ہے۔

اگر BillingMeld کو تبدیلی کا علم ہوتا ہے، تو وہ اپنی حالت کو اپ ڈیٹ کرتا ہے، اور ضرورت پڑنے پر مرچنٹ سے مزید تصدیق کرتا ہے۔

اس کے بعد منسلک سروس نئے سٹیٹس کے ساتھ کام کرتی ہے۔

اس طرح، ایپ جاری رکھتی ہے کہ یہ ثابت کرتی رہے کہ بہت ہفتے یا مہینے پہلے، کلائنٹ نے کامیابی سے خریداری کی اطلاع دی تھی۔

اگر مرچنٹ ویسا ہی حق ماننا بند کر دیتا ہے، تو BillingMeld اسے اپنے سٹیٹس میں ظاہر کرتا ہے۔

سبسکرپشن منسوخ اور رسائی کا خاتمہ ایک جیسا نہیں

یہاں ایک اہم فرق ہے۔

اگر صارف نے سبسکرپشن کی خودکار تجدید بند کر دی ہے، تو اس کا مطلب یہ نہیں کہ رسائی فوری طور پر بند ہو جائے۔

موجودہ ادا شدہ مدت جاری رہ سکتی ہے۔

اس صورت میں، BillingMeld کو یہ معلومات رکھنی چاہئے کہ آگے کی تجدید بند ہے، اور یہ بھی کہ پہلے سے ادا شدہ مدت کی آخری تاریخ کیا ہے۔

اور صرف اس کے خاتمے کے بعد، رسائی فعال رہنا بند ہو جائے گی، جب تک کہ کوئی نیا تصدیق شدہ تجدید نہیں ہو جاتی۔

یہ ایک مثال ہے کہ کیوں ایک سادہ boolean، جیسے subscription = true، مکمل بیلینک کے لیے کافی نہیں ہوتا۔

سبسکرپشن کی حالت ہمیشہ وقت اور اس کے زندگی کے چکر سے جُڑی ہوتی ہے۔

توسیع بھی ایک علیحدہ چیک ہے

سبسکرپشن پہلے ادائیگی پر ختم نہیں ہوتی۔

سرور کو یہ سمجھنا چاہئے کہ آیا کوئی اور تجدید ہوئی ہے اور کیا اگلی ادا شدہ مدت واقعی مرچنٹ سے تصدیق شدہ ہے۔

BillingMeld ایسے تبدیلیوں کو ٹریک کرتا ہے اور سبسکرپشن کی حالت کو اپ ڈیٹ کرتا ہے۔

اگر تجدید تصدیق شدہ ہے، تو رسائی کا حق جاری رہتا ہے۔

اگر اگلی ادائیگی نہیں ہوئی یا مرچنٹ مزید تصدیق نہیں کرتا، تو نظام کو خود بخود رسائی کو جاری نہیں رکھنا چاہئے۔

یاد رکھیں، یہ تفصیلات صارف کو ایک حقیقی، معقول رسائی فراہم کرتی ہیں۔

اس سے یہ بھی ہوتا ہے کہ آپ کے لیے ایک ہی تجدید منطقی عمل کو ہر ایپ میں دوبارہ نافذ کرنے کی ضرورت نہیں ہوتی۔

عام منظر نامہ کیسا لگتا ہے؟

صارف موبائل ایپ میں سبسکرپشن حاصل کرتا ہے۔

کلائنٹ خریداری کی معلومات وصول کرتا ہے اور ضروری ڈیٹا BillingMeld کو بھیج دیتا ہے۔ لیکن خود یہ پیغام حتمی تصدیق کرنے کا سبب نہیں ہے کہ خریداری تصدیق شدہ ہے۔

BillingMeld متعلقہ مرچنٹ کے ذریعے آپریشن کی تصدیق کرتا ہے۔

اگر App Store یا Google Play خریداری کی تصدیق کرتا ہے اور اس کا سٹیٹس پروڈکٹ کے قواعد کے مطابق ہے، تو BillingMeld فعال حق ادا کرتا ہے۔

اس کے بعد، منسلک سروس صارف کو ادائیگی شدہ فوائد فراہم کرتی ہے۔

اس کا سٹیٹس خود بخود پہلے پیغام سے آزاد ہو جاتا ہے۔

اگر سبسکرپشن بڑھتی ہے، تو BillingMeld نئے ادائی شدہ مدت کو مدنظر رکھتا ہے۔

اگر صارف خودکار تجدید بند کرتا ہے، تو موجودہ مدت اپنی آخری تاریخ تک جاری رہتی ہے۔

اگر آپریشن کو واپس لے لیا جاتا ہے یا رد کیا جاتا ہے، تو سٹیٹ دوبارہ بدل جاتا ہے۔

اس سسٹم میں، ایپ اپنی کوئی الگ «سچائی»، یعنی حقیقت، نہیں رکھتی۔ یہ صرف اس حالت سے کام کرتی ہے جو BillingMeld نے تصدیق اور محفوظ کی ہے۔

جب آلہ تبدیل کیا جاتا ہے تو کیا ہوتا ہے

سرور ماڈل خاص طور پر مددگار ہے جب صارف اپنا فون بدلتا ہے یا ایپ دوبارہ انسٹال کرتا ہے۔

ادائیگی کا حق صرف اس لیے موجود نہیں رہنا چاہئے کہ کوئی مخصوص ایپ کچھ عرصہ پہلے کامیابی سے عمل دیکھ چکی ہے۔

ایپ دوبارہ انسٹال کرنے سے تصدیق شدہ حق غائب نہیں ہونا چاہئے۔

اگر خریداری کی حالت سرور پر ہے اور مرچنٹ آپریشن سے منسلک ہے، تو نیا آلہ سرور کے ذریعے حالیہ حالت حاصل کر سکتا ہے۔

یہ بھی ایک وجہ ہے کہ رسائی کی منطق کو صرف موبائل کلائنٹ کے اندر نہیں رکھنا چاہئے۔

پروگرامرز کے لئے یہ کیا معنی رکھتا ہے

وہ ٹیم جو کئی موبائل ایپلیکیشنز جاری کرتی ہے یا iOS اور Android کے ساتھ ایک ساتھ کام کرتی ہے، بیلنگ ایک علیحدہ انفراسٹرکچر کا کام بن جاتی ہے۔

آپ کو اس چیز کا خیال رکھنا ہوتا ہے:

• Apple اور Google کے مختلف فارمیٹس؛
• پہلی خریداری کی تصدیق؛
• سبسکرپشن کی توسیع؛
• ادائی شدہ مدت کا خاتمہ؛
• خودکار تجدید کو غیر فعال کرنا؛
• واپسی؛
• عمل کو رد کرنا؛
• ایپ دوبارہ انسٹال کرنا؛
• آلہ کی تبدیلی؛
• خریداری کی بحالی؛
• اسٹیٹس میں تبدیلی جو صارف کی شمولیت کے بغیر واقع ہوئی ہو۔

BillingMeld اس تمام منطقے کو ایک خاص سطر میں لے آتا ہے۔

پروڈکٹ سرورز اسے ایک معاہدے کے تحت استعمال کرتے ہیں اور ہر مرچنٹ کی خاصیت کو خود سے سمجھنے کی اجازت نہیں دیتے۔

اس سے نقل کو کم کرنا اور کمپنی کے مختلف ایپلیکیشنز کے ایک ہی پیغام کی مختلف سمجھ سے بچنا آسان ہوتا ہے۔

اہم چیز: چیک نہیں بلکہ حالیہ حقوق

مجھے اس آرکیٹیکچر میں سب سے زیادہ دلچسپی اس بات سے ہے کہ ایک علیحدہ خریداری چیک کرنے کی بجائے، فعال حالت کی طرف منتقل ہو رہا ہے۔

ادائیگی کا تاریخی ثبوت خود میں اس اہم سوال کا جواب نہیں دیتا:

کیا صارف کو اب بھی ادا شدہ فنکشن کا حق حاصل ہے؟

آپریشن کا کامیاب آغاز ہو سکتا ہے، لیکن مدت ختم ہو چکی ہو۔

سبسکرپشن کا خودکار تجدید بند ہو سکتا ہے، لیکن ادا شدہ مدت ابھی بھی جاری ہے۔

تصدیق شدہ تجدید ہو سکتی ہے۔

واپسی کی جا سکتی ہے۔

مارچنٹ آپریشن واپس لے سکتا ہے۔

لہذا، چیک اور صارف کے پہلے جواب کے بجائے، اہم چیز وہ فعال حق ہے جس کا اندازہ تصدیق شدہ حالت سے لگایا جاتا ہے۔

یہی حالت دوسرے سروسز کو بھی فراہم کرتا ہے۔

BillingMeld اور مرچنٹس اور پروڈکٹس کے درمیان حد بندی

اس نتیجے پر ایک واضح آرکیٹیکچرل دیوار کھڑی ہوتی ہے۔

ایک طرف App Store اور Google Play ہیں، جن کے فارمیٹس، ایونٹس، قواعد اور زندگی کے چکر مختلف ہیں۔

دوسری طرف، ایپلیکیشنز اور اندرونی خدمات ہیں، جن کے لیے عموماً ایک بہت سادہ جواب درکار ہوتا ہے: صارف کے پاس اس وقت کونسے حقوق ہیں۔

ان کے درمیان BillingMeld ہوتا ہے۔

یہ مرچنٹ کے ڈیٹا کو لیتا ہے، اس کی تصدیق کرتا ہے، اسے اپنی ماڈل میں لاتا ہے اور باقی انفراسٹرکچر کو ایک نیم آمیز نتیجہ فراہم کرتا ہے۔

اس سے پروڈکٹس کو ہر مرچنٹ کی اندرونی پہلوؤں سے آگاہ ہونے کی ضرورت نہیں رہتی۔

یہ صارف کے لیے کیوں اہم ہے

صارف کے لیے صحیح بیلنگ آرکیٹیکچر بنیادی طور پر غیر مرئی رہنا چاہئے۔

اگر خریداری تصدیق شدہ ہے اور ادائی شدہ مدت فعال ہے، تو رسائی کام کرنی چاہئے۔

اگر صارف نے خودکار تجدید بند کی، تو پہلے سے ادا شدہ مدت وقت سے پہلے ختم نہیں ہونی چاہیے۔

اگر کوئی کامیاب تجدید ہوتی ہے، تو رسائی جاری رہنی چاہئے۔

اگر مرچنٹ واپسی یا رد کرنے کی تصدیق کرتا ہے، تو نظام کو حقوق میں تبدیلی کو صحیح طور پر ظاہر کرنا چاہئے۔

آلہ کی تبدیلی یا دوبارہ انسٹالیشن پر، صارف کو دستی طور پر ہر انفرایئکچر سے ثابت کرنے کی ضرورت نہیں ہونی چاہئے کہ خریداری واقعی ہے۔

آخری بات یہ ہے کہ، ایک بنیادی اصول یہ ہے:

کلائنٹ خریداری کی اطلاع دیتا ہے، مرچنٹ اس کی حالت کا بیرونی ماخذ ہے، BillingMeld تصدیق کرتا ہے اور اسے معمولی بناتا ہے، اور باقی سروسز تصدیق شدہ معلومات کی بنیاد پر فیصلے لیتی ہیں۔

اسی لیے، BillingMeld صرف ایک ادائیگی کا ماڈیول نہیں ہے۔

یہ موبائل ایپ، Apple اور Google کے مارکیٹ پلیس اور پروڈکٹس کے درمیان ایک سرور اعتماد کا پرت ہے، جو ہمیں یہ جاننے کے لیے کہ صارف فی الحال کون سے مالی حقوق کا حامل ہے، مشکل سے سمجھنا آسان بناتا ہے۔

مزید معلومات کے لیے: billingmeld.de.