Gemini 3.6 Flash چند سیکنڈوں میں چیک آؤٹ اسکرین کا خاکہ تیار کر سکتا ہے۔ اصل ادائیگی قبول کرنے سے پہلے کن چیزوں کا درست ہونا ضروری ہے؟

تیزی کبھی بھی غائب عنصر نہیں تھی۔ اس سے پہلے کہ کوئی بھی AI کا تیار کردہ چیک آؤٹ براہِ راست ادائیگی قبول کرے، پانچ چیزوں کا درست ہونا ضروری ہے: انوینٹری جو اس وقت بھی درست رہے جب دو اسٹیشن ایک ہی وقت میں فروخت کر رہے ہوں، رپورٹس جو مطابقت رکھتی ہوں (واقعی منتقل ہونے والے پیسوں سے میل کھاتی ہوں)، وہ ٹیکس جو دائرہ اختیار کے مطابق ہو، PCI سے مطابق ادائیگی کی ہینڈلنگ، اور تصدیق شدہ کارڈ پریزنٹ ہارڈ ویئر۔ Gemini 3.6 Flash چیک آؤٹ اسکرین کے پہلے ڈرافٹ کو پہلے سے کہیں زیادہ تیز اور سستا بناتا ہے۔ یہ باقی پانچ چیزوں میں سے کسی کو تبدیل نہیں کرتا۔ Gemini 3.6 Flash POS پروٹو ٹائپ ایک حقیقی شروعاتی فائدہ ہے؛ ایک قابلِ تعینات (deployable) پوائنٹ آف سیل ایک الگ منزل ہے۔

ماڈل کے نام، قیمتیں اور بینچ مارکس تیزی سے بدلتے ہیں۔ ذیل کی تفصیلات اشاعت کے وقت تک درست ہیں؛ انہیں ایک عارضی خاکہ (snapshot) سمجھیں۔

Gemini 3.6 Flash نے درحقیقت کیا بدلا؟

اس نے تیز اور سستے کوڈ کی جنریشن کو مزید سستا اور زیادہ درست بنا دیا۔ گوگل نے 21 جولائی 2026 کو Gemini 3.5 Flash-Lite کے ساتھ Gemini 3.6 Flash جاری کیا¹۔ اس کی لاگت $1.50 فی ملین ان پٹ ٹوکن اور $7.50 فی ملین آؤٹ پٹ ٹوکن ہے، یہ اپنے پیشرو کے مقابلے میں تقریباً 17 فیصد کم آؤٹ پٹ ٹوکن استعمال کرتا ہے، اور کوڈنگ کی درستگی میں ایک حقیقی اضافہ دکھاتا ہے، جس نے DeepSWE بینچ مارک پر 3.5 Flash کے 37 فیصد کے مقابلے میں 49 فیصد اسکور کیا²۔

AI بلڈرز کے ساتھ تجربات کرنے والے تاجر کے لیے، اس کا ایک واضح مطلب ہے: چیک آؤٹ اسکرین کا خاکہ تیار کرنے میں اب چند سیکنڈ اور چند پیسے لگتے ہیں۔ اس پر بار بار کام (iterating) کرنے پر بھی چند پیسے ہی خرچ ہوتے ہیں۔ ایک کسٹم پوائنٹ آف سیل حاصل کرنے کی رکاوٹ بدل گئی ہے۔ اب مسئلہ یہ نہیں ہے کہ آیا ماڈل اسکرینیں بنا سکتا ہے یا نہیں۔ بلکہ مسئلہ وہ تمام چیزیں ہیں جن پر یہ اسکرینیں مبنی ہیں۔

چیک آؤٹ اسکرین ایک پوائنٹ آف سیل کیوں نہیں ہے؟

کیونکہ چیک آؤٹ اسکرین ایک آؤٹ پٹ ہے، اور ایک پوائنٹ آف سیل ریکارڈ کا نظام (system of record) ہے (وہ واحد جگہ جہاں آپ کی فروخت کے اعداد و شمار کو درست مانا جاتا ہے)۔ اسکرین ظاہر ہونے والا دس فیصد حصہ ہے۔ اس کے نیچے وہ کیفیت (state) موجود ہے جسے ہر اسٹیشن، ہر ریفنڈ اور نیٹ ورک کی ہر تھوڑی سی خرابی کے باوجود درست رہنا ہوتا ہے، نیز رقم کی منتقلی ہے جو منظم (regulated) ہوتی ہے چاہے کوڈ ہاتھ سے لکھا گیا ہو یا جنریٹ کیا گیا ہو۔ ہم نے اسی فرق کو تفصیل سے بیان کیا تھا جب GPT-5.6 جاری ہوا، اور اس کے بعد سے ہر تیز ماڈل کے لیے یہی بات قائم ہے۔

بظاہر اعتراض یہ ہوتا ہے: یہ ماڈل اب پروڈکشن گریڈ کوڈ لکھتے ہیں، تو پھر Gemini 3.6 Flash کو انوینٹری اور ٹیکس کا لاجک بھی کیوں نہ لکھنے دیا جائے؟ وہ لکھ سکتا ہے۔ مسئلہ کوڈ لکھنا نہیں ہے۔ مسئلہ ایسی حالات میں اس کوڈ کو درست ثابت کرنا ہے جو آپ ڈیمو میں کبھی نہیں دیکھیں گے، اور یہ محسوس کرنا ہے کہ جب وہ خاموشی سے غلط ہو رہا ہو۔ ایک چیک آؤٹ اسکرین جو غلط رینڈر ہوتی ہے وہ چند سیکنڈ میں پکڑی جاتی ہے۔ ایک لیجر جو آہستہ آہستہ غلط ہو رہا ہو وہ مہینے کے اختتام پر، آپ کے اکاؤنٹنٹ کے ذریعے پکڑا جاتا ہے، اور تب تک ہر رپورٹ ٹھیک نظر آتی ہے۔

پہلی اصل ادائیگی سے پہلے کس چیز کا درست ہونا ضروری ہے؟

پانچ چیزیں، اور ان میں سے کوئی بھی پریویو ونڈو میں نظر نہیں آتی۔

انوینٹری جو ہم وقت سازی (concurrency) کا مقابلہ کر سکے

ہم وقت سازی یا کنکرنسی (دو چیک آؤٹ کا ایک ہی لمحے میں ایک ہی اسٹاک کو ہٹ کرنا) وہ جگہ ہے جہاں تیار کردہ انوینٹری کوڈ سب سے پہلے ناکام ہوتا ہے۔ دو اسٹیشن ایک ہی سیکنڈ میں کسی ائٹم کے آخری یونٹ کو فروخت کرتے ہیں۔ سادہ کوڈ تعداد چیک کرتا ہے، ایک دستیاب دیکھتا ہے، اور دونوں فروخت کی اجازت دے دیتا ہے۔ اب آپ نے وہ چیز بیچ دی ہے جو آپ کے پاس نہیں ہے، اور یہ غلطی ہر مصروف گھنٹے کے ساتھ خاموشی سے بڑھتی جاتی ہے۔ ایک درست سسٹم ان رائٹس کو ترتیبی (serialize) بناتا ہے تاکہ ایک فروخت کامیاب ہو اور دوسرے کو خالی شیلف نظر آئے۔ یہ انفراسٹرکچر کا رویہ ہے، اسکرین کا رویہ نہیں، اور کوئی بھی پریویو اسے کبھی نہیں دکھائے گا۔

مطابقت رکھنے والی رپورٹس (Reports that reconcile)

مطابقت پذیری (آپ کی رپورٹس کا واقعی منتقل ہونے والی رقم سے میل کھانا) بقیہ صورتوں (edge cases) پر ٹوٹ جاتی ہے: سیشن بند ہونے کے بعد جاری کیا گیا ریفنڈ، دراز کی گنتی کے بعد کا منسوخی (void)، رعایت یافتہ آئٹم پر جزوی ریفنڈ، نیٹ ورک منقطع ہونے کے بعد دوبارہ کوشش کی گئی ادائیگی۔ تیار کردہ رپورٹ جس ہر ایج کیس کو نظر انداز کرتی ہے، وہ اس کے درمیان ایک چھوٹا سا سوراخ بن جاتا ہے جو رپورٹ کہتی ہے اور جو بینک میں جمع ہوا ہے۔ تاجروں کو ٹیسٹنگ میں ان سوراخوں کا پتہ نہیں چلتا۔ وہ ٹیکس کے وقت ان کا انکشاف کرتے ہیں۔

ٹیکس جو دائرہ اختیار سے مطابقت رکھتا ہو

سیلز ٹیکس میں تہیں ہوتی ہیں: علاقائی شرح کے اوپر ایک قومی شرح، فی پروڈکٹ چھوٹ، وہ شرحیں جو آپ کے ریلیز کے شیڈول کے بجائے قانون ساز ادارے کی مقرر کردہ تاریخ پر بدلتی ہیں۔ اسے غلط کرنا کوئی بگ ٹکٹ نہیں ہے، یہ ایک قانونی ذمہ داری (liability) ہے۔ ایک حقیقی سسٹم ٹیکسوں کو ایک بار مرتب کرتا ہے اور انہیں ہر جگہ یکساں طور پر لاگو کرتا ہے، جس طرح Merchant Hub میں ٹیکس گروپس کام کرتے ہیں۔

ادائیگی کی ہینڈلنگ جو PCI کے معیارات پر پورا اترے

PCI DSS (کارڈ انڈسٹری کا سیکیورٹی اسٹینڈرڈ) اس لیے موجود ہے تاکہ کارڈ کے ڈیٹا کو صرف آڈٹ شدہ سسٹمز کے ذریعے ہی ہینڈل کیا جائے۔ تیار کردہ کوڈ کو کبھی بھی کارڈ نمبر نہیں دیکھنا چاہیے۔ عملی طور پر اس کا مطلب ہے کہ ادائیگیاں کسی پیمنٹ پروسیسر کے تصدیق شدہ اسٹیک کے ذریعے چلتی ہیں، جس میں آپ کے سافٹ ویئر کے چھونے سے پہلے کارڈ ڈیٹا کو ٹوکنائز (ایک متبادل ٹوکن سے تبدیل) کر دیا جاتا ہے۔ یہ اس فہرست کا سب سے غیر قابلِ سمجھوتہ عنصر ہے، اور یہ مکمل طور پر اس سے باہر ہے جو کوئی بھی ماڈل آؤٹ پٹ کرتا ہے۔

تصدیق شدہ کارڈ پریزنٹ ہارڈ ویئر

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

ایک تیز ماڈل دراصل کہاں مدد کرتا ہے؟

ٹھیک اسی جگہ جہاں اس ریلیز نے اپنی توجہ مرکوز کی: بیان کرنے، خاکہ بنانے، اور بار بار بہتری لانے میں۔ ایک سستا، تیز ماڈل اسکرینوں اور فلو لاجک کو شکل دینے، دوپہر کے کھانے سے پہلے پانچ لے آؤٹ آزمانے، اور چیک آؤٹ کو اس وقت تک بہتر بنانے کے لیے ایک صحیح ٹول ہے جب تک کہ وہ اس انداز سے مماثل نہ ہو جائے جیسا کہ آپ کا کاؤنٹر واقعی چلتا ہے۔ جو تقسیم کام کرتی ہے وہ یہ ہے کہ ماڈل کو یہ کام ایسے کامرس انفراسٹرکچر کے اوپر کرنے دیا جائے جو پہلے سے انوینٹری، آڈٹ کی مطابقت (reconciliation)، ٹیکس، اور ادائیگیوں کا مالک ہے۔

Final کا Build ماڈلز کے ساتھ اسی طرح کا سلوک کرتا ہے: آپ Gemini یا کسی بھی MCP کلائنٹ کو منسلک کر سکتے ہیں اور اسے لائیو پریویو کے ساتھ اپنا فلو بنانے دے سکتے ہیں، جبکہ Final Pay نیچے کسی پیمنٹ پروسیسر اور تصدیق شدہ ٹرمینل ہارڈویئر کے ذریعے ادائیگیوں کو نپٹاتا ہے۔ مرحلہ وار رہنمائی کے لیے، دیکھیں Gemini 3.6 Flash کے ساتھ کیسے تعمیر کریں، یا POS کی تعمیرات پر تین بڑے ماڈلز کا موازنہ کیسے کیا جاتا ہے۔

تو، Gemini 3.6 Flash کے اصل ادائیگی قبول کرنے سے پہلے کس چیز کا درست ہونا ضروری ہے؟

ہم وقت سازی (concurrency) کے تحت انوینٹری، مطابقت رکھنے والی رپورٹس، دائرہ اختیار سے مطابقت رکھنے والا ٹیکس، PCI کے مطابق ادائیگی کی ہینڈلنگ، اور تصدیق شدہ ہارڈ ویئر۔ Gemini 3.6 Flash نے ابھی چیک آؤٹ اسکرین کو پروجیکٹ کا سب سے سستا حصہ بنا دیا ہے، اور اس نے اس فہرست میں سے کسی چیز کو نہیں چھوا۔ عام اصول: اگر کوئی ناکامی آپ کی اسکرین کے بجائے آپ کے بینک اکاؤنٹ میں ظاہر ہوگی، تو تیار کردہ کوڈ کو اکیلے اس کا ذمہ دار نہ بننے دیں۔ آپ کو ملنے والے تیز ترین ماڈل کے ساتھ خاکہ تیار کریں، پھر ایسے انفراسٹرکچر پر تعینات کریں جو آڈٹ کے لیے بنایا گیا ہو۔ اگر آپ آج اس تقسیم کو آزمانا چاہتے ہیں، تو Build کے ساتھ شروعات کریں۔