Gemini 3.6 Flash कुछ ही सेकंड में चेकआउट स्क्रीन का ड्राफ्ट तैयार कर सकता है। वास्तविक भुगतान लेने से पहले क्या सही होना ज़रूरी है?
Gemini 3.6 Flash चेकआउट स्क्रीन का ड्राफ्ट बनाना लगभग मुफ़्त कर देता है। लाइव चार्ज लेने के लिए अभी भी पाँच चीज़ों पर निर्भर रहना पड़ता है जिन्हें मॉडल जनरेट नहीं करता: कनकूरेंसी के तहत इन्वेंट्री, रिकंसाइल होने वाली रिपोर्ट, सही टैक्स, PCI-अनुपालन भुगतान और प्रमाणित हार्डवेयर।
Mathias NielsenCEO, Final POS
गति कभी भी गायब रहने वाला टुकड़ा नहीं थी। कोई भी AI-जनरेटेड चेकआउट लाइव चार्ज लेने से पहले, पाँच चीज़ों का सही होना आवश्यक है: इन्वेंट्री जो तब भी सही रहे जब दो स्टेशन एक साथ बिक्री करें, रिपोर्ट जो रिकंसाइल हों (वास्तव में ट्रांसफ़र हुए पैसे से मेल खाती हों), टैक्स जो क्षेत्राधिकार के अनुकूल हो, PCI-अनुपालन भुगतान हैंडलिंग, और प्रमाणित कार्ड-प्रेजेंट हार्डवेयर। Gemini 3.6 Flash चेकआउट स्क्रीन के पहले ड्राफ्ट को पहले से कहीं अधिक तेज़ और किफ़ायती बनाता है। यह अन्य पाँच चीज़ों में कोई बदलाव नहीं करता। Gemini 3.6 Flash POS प्रोटोटाइप एक वास्तविक शुरुआती बढ़त है; एक तैनात करने योग्य पॉइंट ऑफ़ सेल एक अलग फिनिश लाइन है।
मॉडल के नाम, कीमतें और बेंचमार्क तेज़ी से बदलते हैं। नीचे दी गई जानकारी प्रकाशन के समय सटीक है; इसे एक स्नैपशॉट के रूप में देखें।
Gemini 3.6 Flash ने वास्तव में क्या बदला?
इसमें तेज़ और सस्ते कोड जनरेशन को और भी किफ़ायती तथा अधिक सटीक बना दिया। Google ने 21 जुलाई, 2026 को Gemini 3.5 Flash-Lite के साथ Gemini 3.6 Flash रिलीज़ किया¹। इसकी लागत प्रति मिलियन इनपुट टोकन $1.50 और प्रति मिलियन आउटपुट टोकन $7.50 है, यह अपने पूर्ववर्ती की तुलना में लगभग 17 प्रतिशत कम आउटपुट टोकन का उपयोग करता है, और कोडिंग सटीकता में वास्तविक उछाल दिखाता है, DeepSWE बेंचमार्क पर 3.5 Flash के 37 प्रतिशत की तुलना में 49 प्रतिशत स्कोर करता है²।
AI बिल्डरों के साथ प्रयोग करने वाले किसी व्यापारी के लिए, इसका मतलब कुछ ठोस है: चेकआउट स्क्रीन का ड्राफ्ट तैयार करने में अब कुछ सेकंड लगते हैं और मामूली पैसे ख़र्च होते हैं। इसमें सुधार करने में भी मामूली पैसे ख़र्च होते हैं। एक कस्टम पॉइंट ऑफ़ सेल प्राप्त करने में आने वाली बाधा अब बदल गई है। अब यह बात नहीं है कि मॉडल स्क्रीन तैयार कर सकता है या नहीं। मुद्दा वह सब कुछ है जिस पर वे स्क्रीन टिकी होती हैं।
एक चेकआउट स्क्रीन ही पॉइंट ऑफ़ सेल क्यों नहीं है?
क्योंकि एक चेकआउट स्क्रीन केवल आउटपुट है, और एक पॉइंट ऑफ़ सेल सिस्टम ऑफ़ रिकॉर्ड (वह एकमात्र स्थान जहाँ आपके बिक्री के आँकड़े सही माने जाते हैं) है। स्क्रीन दिखने वाला केवल दस प्रतिशत हिस्सा है। इसके नीचे वह स्थिति होती है जिसे हर स्टेशन, हर रिफ़ंड और हर नेटवर्क की खराबी के दौरान सही रहना पड़ता है, साथ ही धन की आवाजाही जो विनियमित होती है, चाहे कोड हाथ से लिखा गया हो या जनरेट किया गया हो। हमने यही अंतर तब भी समझाया था जब GPT-5.6 लॉन्च हुआ था, और तब से हर तेज़ मॉडल के लिए यह बात सही साबित हुई है।
ज़ाहिर सा तर्क: ये मॉडल अब प्रोडक्शन-ग्रेड कोड लिखते हैं, तो Gemini 3.6 Flash को इन्वेंट्री और टैक्स लॉजिक भी क्यों न लिखने दिया जाए? वह लिख सकता है। समस्या कोड लिखने की नहीं है। समस्या उस कोड को ऐसी स्थितियों में सही साबित करने की है जिन्हें आप कभी डेमो में नहीं देखेंगे, और यह ध्यान देने की है कि कब वह चुपचाप ग़लत हो जाता है। एक चेकआउट स्क्रीन जो ग़लत रेंडर होती है, कुछ ही सेकंड में पकड़ी जाती है। एक बहीखाता जो भटकता है, वह महीने के अंत में आपके अकाउंटेंट द्वारा पकड़ा जाता है, और तब तक हर रिपोर्ट ठीक दिखती है।
पहले वास्तविक चार्ज से पहले क्या सही होना ज़रूरी है?
पाँच चीज़ें, और उनमें से कोई भी पूर्वावलोकन विंडो में दिखाई नहीं देती।
कनकूरेंसी में टिकने वाली इन्वेंट्री
कनकूरेंसी (एक ही क्षण में दो चेकआउट का एक ही स्टॉक तक पहुँचना) वह जगह है जहाँ जनरेट किया गया इन्वेंट्री कोड सबसे पहले विफल होता है। दो स्टेशन एक ही सेकंड में किसी आइटम की आखिरी यूनिट बेचते हैं। साधारण कोड गिनती की जाँच करता है, एक उपलब्ध देखता है, और दोनों बिक्री की अनुमति दे देता है। अब आपने वह चीज़ बेच दी है जो आपके पास है ही नहीं, और यह त्रुटि हर व्यस्त घंटे के साथ चुपचाप बढ़ती जाती है। एक सही सिस्टम उन राइट्स को सीरियलाइज़ करता है ताकि एक बिक्री सफल हो और दूसरे को खाली शेल्फ़ दिखाई दे। यह इंफ्रास्ट्रक्चर का व्यवहार है, न कि स्क्रीन का, और कोई भी प्रीव्यू इसे कभी नहीं दिखाएगा।
रिकंसाइल होने वाली रिपोर्ट
रिकंसीलिएशन (आपकी रिपोर्ट का वास्तव में ट्रांसफ़र हुए पैसे से मेल खाना) कठिन स्थितियों पर आकर टूट जाता है: सेशन बंद होने के बाद जारी किया गया रिफ़ंड, दराज की गिनती के बाद किया गया वॉइड, डिस्काउंट वाली लाइन पर आंशिक रिफ़ंड, नेटवर्क कटने के बाद दोबारा प्रयास किया गया भुगतान। जनरेट की गई रिपोर्ट में छूट जाने वाला ऐसा हर एज़ केस उस अंतर को बढ़ाता है कि रिपोर्ट क्या कहती है और बैंक में क्या जमा हुआ है। व्यापारी टेस्टिंग के दौरान इन कमियों को नहीं खोज पाते। वे टैक्स के समय इनका पता लगाते हैं।
क्षेत्राधिकार से मेल खाने वाला टैक्स
बिक्री कर की कई परतें होती हैं: क्षेत्रीय दर के ऊपर एक राष्ट्रीय दर, प्रति-उत्पाद छूट, दरें जो आपके रिलीज़ शेड्यूल के बजाय विधायिका द्वारा निर्धारित तिथि पर बदलती हैं। इसे ग़लत करना कोई सामान्य बग नहीं है, यह एक कानूनी/वित्तीय देनदारी है। एक वास्तविक सिस्टम टैक्स को एक बार कॉन्फ़िगर करता है और उन्हें हर जगह लगातार लागू करता है, जिस तरह Merchant Hub में टैक्स ग्रुप काम करते हैं।
PCI पास करने वाली भुगतान हैंडलिंग
PCI DSS (कार्ड उद्योग का सुरक्षा मानक) इसलिए मौजूद है ताकि कार्ड डेटा को केवल ऑडिट किए गए सिस्टम द्वारा ही हैंडल किया जाए। जनरेट किए गए कोड को कभी भी कार्ड नंबर नहीं देखना चाहिए। व्यवहार में इसका मतलब यह है कि भुगतान किसी भुगतान प्रोसेसर के प्रमाणित स्टैक के माध्यम से चलते हैं, आपके सॉफ़्टवेयर द्वारा किसी भी चीज़ को छूने से पहले कार्ड डेटा को टोकनाइज़ कर दिया जाता है। यह सूची में सबसे गैर-समझौतावादी आइटम है, और यह किसी भी मॉडल द्वारा दिए जाने वाले आउटपुट से पूरी तरह बाहर है।
प्रमाणित कार्ड-प्रेजेंट हार्डवेयर
टैप और चिप भुगतान केवल कार्ड नेटवर्क द्वारा प्रमाणित टर्मिनलों पर ही चलते हैं, और लैब टेस्टिंग के माध्यम से प्रत्येक डिवाइस के लिए प्रमाणन प्राप्त किया जाता है। इसे बाद में जनरेट, प्रॉम्प्ट या पैच नहीं किया जा सकता। यदि आपके ग्राहक व्यक्तिगत रूप से भुगतान करते हैं, तो उनके कार्ड और आपके कोड के बीच एक प्रमाणित टर्मिनल होना ही चाहिए।
एक तेज़ मॉडल वास्तव में कहाँ मदद करता है?
ठीक वहीं जहाँ इस रिलीज़ ने अपना ज़ोर दिया है: विवरण देने, ड्राफ़्ट तैयार करने और सुधार करने में। एक किफ़ायती, तेज़ मॉडल स्क्रीन और फ़्लो लॉजिक को आकार देने, दोपहर के भोजन से पहले पाँच लेआउट आज़माने, और चेकआउट को तब तक परिष्कृत करने के लिए सही टूल है जब तक कि यह आपके काउंटर के वास्तविक संचालन के अनुकूल न हो जाए। जो तरीक़ा काम करता है वह यह है कि मॉडल को यह सब ऐसे कॉमर्स इंफ्रास्ट्रक्चर के ऊपर करने दिया जाए जो पहले से ही इन्वेंट्री, रिकंसीलिएशन, टैक्स और भुगतान को संभालता है।
Final का Build मॉडल के साथ इसी तरह व्यवहार करता है: आप Gemini या किसी भी MCP क्लाइंट को कनेक्ट कर सकते हैं और इसे लाइव प्रीव्यू के साथ अपना फ़्लो बनाने दे सकते हैं, जबकि Final Pay नीचे भुगतान प्रोसेसर और प्रमाणित टर्मिनल हार्डवेयर के माध्यम से भुगतानों का निपटान करता है। चरण-दर-चरण विवरण के लिए, देखें Gemini 3.6 Flash के साथ निर्माण कैसे करें, या POS निर्माण पर तीन बड़े मॉडल की तुलना कैसे की जाती है।
तो, Gemini 3.6 Flash द्वारा वास्तविक भुगतान लेने से पहले क्या सही होना चाहिए?
कनकूरेंसी के तहत इन्वेंट्री, रिकंसाइल होने वाली रिपोर्ट, क्षेत्राधिकार से मेल खाने वाला टैक्स, PCI-अनुपालन भुगतान हैंडलिंग और प्रमाणित हार्डवेयर। Gemini 3.6 Flash ने चेकआउट स्क्रीन को प्रोजेक्ट का सबसे सस्ता हिस्सा बना दिया है, और इसने उस सूची में से किसी को भी नहीं छुआ। एक व्यावहारिक नियम: यदि कोई विफलता आपकी स्क्रीन के बजाय आपके बैंक खाते में दिखाई देगी, तो जनरेट किए गए कोड को अकेले उसका ज़िम्मेदार न बनने दें। जितने तेज़ मॉडल से हो सके ड्राफ़्ट तैयार करें, फिर ऑडिट किए जाने के लिए बने इंफ्रास्ट्रक्चर पर तैनात करें। यदि आप आज इस विभाजन को आज़माना चाहते हैं, तो Build के साथ शुरुआत करें।
अक्सर पूछे जाने वाले प्रश्न
क्या Gemini 3.6 Flash अपने आप एक पॉइंट ऑफ़ सेल बना सकता है?
यह चेकआउट स्क्रीन और अधिकांश फ़्लो लॉजिक जल्दी से जनरेट कर सकता है। यह PCI-अनुपालन भुगतान हैंडलिंग, प्रमाणित कार्ड-प्रेजेंट हार्डवेयर, या रिकंसाइल होने वाला ट्रांजेक्शन बहीखाता प्रदान नहीं कर सकता। ये उस कॉमर्स इंफ्रास्ट्रक्चर से आते हैं जिस पर जनरेट किया गया फ़्लो चलता है।
चेकआउट UI और एक काम करने वाले POS में क्या अंतर है?
एक चेकआउट UI केवल दिखाई देने वाली स्क्रीन है। एक काम करने वाला POS एक सिस्टम ऑफ़ रिकॉर्ड है: यह स्टेशनों पर इन्वेंट्री को सही रखता है, वास्तव में ट्रांसफ़र हुए पैसे से मेल खाने वाली रिपोर्ट तैयार करता है, सही टैक्स लागू करता है, और प्रमाणित हार्डवेयर पर भुगतान प्रोसेसर के माध्यम से भुगतान का निपटान करता है।
वास्तविक दुकानों में AI-जनरेटेड इन्वेंट्री कोड क्यों विफल हो जाता है?
कनकूरेंसी। दो स्टेशन एक ही सेकंड में किसी आइटम की आखिरी यूनिट बेच सकते हैं, और साधारण जनरेट किया गया कोड दोनों बिक्रियों की अनुमति दे देता है। डेमो में यह कभी सामने नहीं आता क्योंकि डेमो में शायद ही कभी एक ही स्टॉक के खिलाफ़ एक साथ दो चेकआउट चलाए जाते हैं।
AI-निर्मित चेकआउट के लिए PCI अनुपालन का क्या अर्थ है?
PCI DSS कार्ड डेटा को संभालने के लिए कार्ड उद्योग का सुरक्षा मानक है। व्यवहार में, जनरेट किए गए कोड को कभी भी कार्ड नंबर नहीं देखना चाहिए: भुगतान किसी भुगतान प्रोसेसर के प्रमाणित स्टैक के माध्यम से चलने चाहिए, और आपके सॉफ़्टवेयर द्वारा किसी भी चीज़ को छूने से पहले कार्ड डेटा को टोकनाइज़ किया जाना चाहिए।
क्या मैं Final के साथ Gemini 3.6 Flash का उपयोग कर सकता हूँ?
हाँ। Build MCP के माध्यम से आपके स्वयं के AI को कनेक्ट करने का समर्थन करता है: Build एक एक-बार का सेटअप ब्लॉक जनरेट करता है जिसे आप अपने टूल में पेस्ट करते हैं, और मॉडल लाइव प्रीव्यू के साथ Final के इंफ्रास्ट्रक्चर पर आपका फ़्लो बनाता है, जिसमें भुगतानों को Final Pay द्वारा संभाला जाता है।