२०२५-०२-११ लेखक : झेडसीएस
POS टर्मिनलवर लॉयल्टी प्रोग्राम अयशस्वी होण्यामागे एक प्रमुख कारण आहे: ते हार्डवेअर बाहेरील सॉफ्टवेअरला आत येऊ देण्यासाठी मुळातच बनवलेले नसते. किरकोळ विक्रेते एक लॉयल्टी प्लॅटफॉर्म विकत घेतात, करारावर सही करतात, त्याच्या अंमलबजावणीसाठी बजेट ठरवतात — आणि मग त्यांच्या लक्षात येते की टर्मिनलची ऑपरेटिंग सिस्टीम, SDK किंवा पेमेंट सर्टिफिकेशन हे इंटिग्रेशन पूर्णपणे रोखून धरते. ही सॉफ्टवेअरची समस्या नाही. ही हार्डवेअर आर्किटेक्चरची समस्या आहे, आणि ती जवळजवळ प्रत्येक वेळी दिसून येते जेव्हा एखादा व्यापारी, ओपन कॉम्प्युटिंग डिव्हाइसऐवजी एक क्लोज्ड पेमेंट अप्लायन्स म्हणून डिझाइन केलेल्या टर्मिनलवर लॉयल्टी प्रोग्रामच्या कार्यक्षमतेसह POS सिस्टीम बसवण्याचा प्रयत्न करतो.
कोणत्याही प्लॅटफॉर्मचे मूल्यांकन करण्यापूर्वी, काही गोष्टी निश्चित करणे उपयुक्त ठरते. POS टर्मिनल रिवॉर्ड्स डेटासह काय करू शकते आणि काय करू शकत नाही, हा मूलभूत प्रश्न. कारण उत्तर हे लॉयल्टी सॉफ्टवेअरच्या वैशिष्ट्यांच्या यादीवर नव्हे, तर त्याखालील हार्डवेअरवर पूर्णपणे अवलंबून असते.
हा लेख, लॉक-डाउन हार्डवेअरवर लॉयल्टी-इंटिग्रेटेड पीओएस सिस्टीम अयशस्वी होण्याची विशिष्ट तांत्रिक कारणे, ओएस आणि सर्टिफिकेशन स्तरावर "लॉक-डाउन" चा नेमका अर्थ काय आहे, आणि ज्या व्यापाऱ्यांना प्रत्यक्ष वापरात काम करणाऱ्या कस्टमर लॉयल्टी पीओएस सिस्टीमची आवश्यकता आहे त्यांच्यासाठी मूल्यांकन चेकलिस्ट कशी असते, याचे सविस्तर विश्लेषण करतो.
लॉक-डाउन POS हार्डवेअर म्हणजे असे टर्मिनल, जिथे उत्पादक कोणते ॲप्लिकेशन्स चालू शकतात, ते ॲप्लिकेशन्स कोणत्या सिस्टम रिसोर्सेसचा वापर करू शकतात किंवा दोन्हीवर निर्बंध घालतो. ही एक हेतुपुरस्सर केलेली डिझाइनची निवड आहे, दोष नाही. पारंपरिक कार्ड-प्रेझेंट टर्मिनल्स — म्हणजे प्रामुख्याने EMV आणि PIN व्यवहारांसाठी बनवलेली काउंटरटॉप युनिट्स — PCI PTS POI मानकांनुसार प्रमाणित असतात, जे संपूर्ण डिव्हाइसला एकच विश्वसनीय पेमेंट वातावरण मानतात. पूर्वी, त्या वातावरणात लॉयल्टी ॲप जोडण्याचा अर्थ कार्डधारकाच्या डेटाशेजारी एक अप्रमाणित कोड पाथ जोडणे असा होता, ज्याला पेमेंट ब्रँड्स आणि ॲक्वायरर्स परवानगी देत नाहीत.
तीन हार्डवेअर वैशिष्ट्ये लॉक-डाउन टर्मिनलची व्याख्या करतात:
यापैकी कोणतेही वैशिष्ट्य मूळतः चुकीचे नाही. जुन्या विक्रेत्यांचे समर्पित कार्ड-प्रेझेंट टर्मिनल्स विशेषतः PCI DSS ऑडिटची व्याप्ती कमी करण्यासाठी अशा प्रकारे तयार केलेले असतात. समस्या तेव्हाच निर्माण होते, जेव्हा एखादा व्यापारी त्याच टर्मिनलकडून लॉयल्टी प्रोग्राम मॉड्यूलसह POS, CRM सिंक किंवा मार्केटिंग ॲप चालवण्याची अपेक्षा करतो — अशा क्षमतांना समर्थन देण्यासाठी हार्डवेअरला कधीही प्रमाणित किंवा तयार केलेले नव्हते.
बंद आर्किटेक्चरवर लॉयल्टी इंटिग्रेशन तीन वारंवार आढळणाऱ्या तांत्रिक कारणांमुळे अयशस्वी होतात: सँडबॉक्सिंग नियम डेटा ॲक्सेसवर निर्बंध घालतात, मालकीचे SDKs इन्स्टॉलेशनला अवरोधित करतात आणि फर्मवेअर अपडेट सायकलमुळे फीचर रोलआउटमध्ये अडथळा येतो.
पीसीआय सुरक्षा मानक परिषदेने प्रकाशित केलेले पीसीआय पीटीएस पीओआय आवृत्ती ७.०, आता ॲप-स्टोअर ॲप्ससारख्या तृतीय-पक्ष ॲप्लिकेशन्सना प्रमाणित पीओआय उपकरणांवर चालवण्याची परवानगी देते. परंतु या मानकानुसार, ती ॲप्लिकेशन्स असणे आवश्यक आहे. संवेदनशील पेमेंट कार्यांपासून सुरक्षितपणे वेगळे केलेले आणि क्रिप्टोग्राफिक नियंत्रणांचा वापर करून प्रमाणीकृत केलेले.त्याच आवृत्तीमधील एक नवीन आवश्यकता, तृतीय-पक्ष ॲप्लिकेशन्सना, ते ॲप्लिकेशन मंजूर व्हाईटलिस्टवर असले तरीही, स्पष्ट मजकुरातील (cleartext) पॅन किंवा पिन डेटा वाचण्यापासून प्रतिबंधित करते. लॉयल्टी इंजिनसाठी हे थेट महत्त्वाचे आहे: कोणताही इंटिग्रेशन पॅटर्न जो असे गृहीत धरतो की लॉयल्टी ॲप पेमेंट प्रक्रियेतून थेट व्यवहाराची एकूण रक्कम, कार्ड टोकन किंवा ग्राहक ओळखकर्ता वाचू शकते, तो v7.0-प्रमाणित डिव्हाइसवर अनुरूप नाही. लॉयल्टी ॲपला तो डेटा एका मंजूर, वेगळ्या चॅनेलद्वारे प्राप्त करणे आवश्यक आहे — आणि अनेक लॉक केलेल्या टर्मिनल्सवर असे कोणतेही चॅनेल अस्तित्वात नसते.
एका लॉयल्टी प्लॅटफॉर्मला ग्राहकांची नोंदणी करणे, पॉईंट बॅलन्स तपासणे, रिडेम्पशन्स लागू करणे आणि विक्रीच्या ठिकाणी (पॉइंट ऑफ सेल) रिवॉर्ड्स प्रिंट करणे किंवा प्रदर्शित करणे आवश्यक असते. या प्रत्येक कृतीसाठी एका SDK हुकची आवश्यकता असते. बंद, विक्रेत्याच्या मालकीच्या OS असलेले टर्मिनल्स सहसा बाहेरील डेव्हलपर्ससाठी हे हुक्स उपलब्ध करून देत नाहीत — व्यवहार पूर्ण झाल्यानंतर लॉयल्टी विक्रेत्याला पेमेंट गेटवे वेबहुकद्वारे इंटिग्रेट करावे लागते, आणि तोपर्यंत रिअल-टाइम डिस्काउंट लागू करण्यासाठी किंवा इन-सेशन रिवॉर्ड ट्रिगर करण्यासाठी खूप उशीर झालेला असतो. जुन्या काउंटरटॉप टर्मिनल्सवरून POS लॉयल्टी प्रोग्रामच्या वापराकडे वळणाऱ्या व्यापाऱ्यांकडून नोंदवलेला हा सर्वात सामान्य अपयशाचा प्रकार आहे: इंटिग्रेशन तांत्रिकदृष्ट्या व्यवहारानंतरच्या सिंक (post-transaction sync) म्हणून "काम करते", परंतु प्रत्यक्ष व्यवहाराच्या ठिकाणी काहीही करू शकत नाही.
जरी लॉक केलेल्या टर्मिनलवर मर्यादित SDK उपलब्ध असले तरी, एकल-उद्देशीय पेमेंट डिव्हाइसेसवरील फर्मवेअर सामान्यतः हळू, प्रमाणीकरण-आधारित वेळापत्रकानुसार अपडेट केले जाते, कारण प्रत्येक फर्मवेअर बदलामुळे PCI पुन:प्रमाणीकरण सुरू होऊ शकते. ज्या लॉयल्टी विक्रेत्याला नवीन रिडेम्प्शन नियम, नवीन एनरोलमेंट फ्लो किंवा नवीन रिवॉर्ड्स टियर सादर करायचा आहे, त्याला स्वतःच्या नव्हे, तर हार्डवेअर विक्रेत्याच्या रिलीज सायकलची वाट पाहावी लागते. ओपन अँड्रॉइड POS टर्मिनलवर, लॉयल्टी ॲप स्वतःच्या ॲप पॅकेजद्वारे स्वतंत्रपणे अपडेट होते आणि ते टर्मिनल फर्मवेअरवर अजिबात अवलंबून नसते.
अयशस्वी एकीकरणाचा थेट खर्च म्हणजे अंमलबजावणी थांबणे किंवा मागे घेतली जाणे, परंतु मोठा खर्च धोरणात्मक असतो: किरकोळ विक्रेते वाढत्या दराने लॉयल्टी सॉफ्टवेअर खरेदी करत राहतात, तर हार्डवेअर सुसंगततेचा विचार मात्र नंतर केला जातो. जागतिक लॉयल्टी व्यवस्थापन बाजारपेठ २०२६ मध्ये अंदाजे १७.३८ अब्ज डॉलर्सवर पोहोचली होती आणि २०३४ पर्यंत १४% पेक्षा जास्त चक्रवाढ वार्षिक दराने वाढण्याचा अंदाज आहे. चेकआउट हार्डवेअरवर प्रत्यक्षात चालू न शकणाऱ्या लॉयल्टी प्लॅटफॉर्मवर खर्च केलेला प्रत्येक डॉलर हा दोनदा खर्च होतो — एकदा सॉफ्टवेअरवर आणि पुन्हा एकदा हार्डवेअरच्या नूतनीकरणावर, जे आधी व्हायला हवे होते.
अनुपालनाचा खर्चही येतो. लॉयल्टी प्रोग्राम्स ग्राहकांचा वैयक्तिक डेटा गोळा करतात आणि त्यावर प्रक्रिया करतात — जसे की नावे, फोन नंबर, खरेदीचा इतिहास, आणि काहीवेळा 'टॅप-टू-आयडेंटिफाय' प्रोग्राम्ससाठी बायोमेट्रिक नोंदणी डेटा. युरोपियन युनियनच्या नियमांनुसार २०१६/६७९ (जीडीपीआर)त्या प्रक्रियेसाठी नोंदणीच्या वेळी एक दस्तऐवजीकृत कायदेशीर आधार आणि अनुरूप संमती प्रवाह आवश्यक असतो. अनधिकृत पर्यायी मार्गाने — जसे की जेलब्रेक केलेले टर्मिनल, असमर्थित साइडलोडेड APK, किंवा स्क्रीन-स्क्रॅपिंग ब्रिज — जबरदस्तीने केलेले लॉयल्टी इंटिग्रेशन ऑडिट दरम्यान ते अनुपालन दस्तऐवज सादर करणे अधिक कठीण बनवते, कारण डेटा पाथची रचनाच मुळात पुनरावलोकनासाठी केलेली नव्हती.
विश्वसनीयपणे लॉयल्टीला समर्थन देणाऱ्या आर्किटेक्चरमध्ये तीन वैशिष्ट्ये सामायिक असतात: एक ओपन SDK, ॲप-स्टोअर-स्तरीय सॉफ्टवेअर वितरण आणि कार्ड स्वाइपच्या पलीकडे जाणारी हार्डवेअर ओळख वैशिष्ट्ये.
प्रकाशित SDK असलेले अँड्रॉइड-आधारित POS टर्मिनल्स लॉयल्टी विक्रेत्याला प्रत्येक नवीन वैशिष्ट्यासाठी हार्डवेअर निर्मात्याची वाट न पाहता, प्रिंटर, स्कॅनर, ग्राहकाभिमुख डिस्प्ले आणि पेमेंट कर्नलसाठी दस्तऐवजीकृत API वापरून थेट बिल्ड करण्याची परवानगी देतात. हे तेच ओपन-प्लॅटफॉर्म मॉडेल आहे जे स्क्वेअरच्या टर्मिनल API ने स्वतःच्या हार्डवेअरसाठी सादर केले होते, आणि आता बंद सिंगल-ॲप किऑस्कऐवजी मल्टी-व्हेंडर रिटेल वातावरणात विक्री करणाऱ्या बहुतेक अँड्रॉइड POS उत्पादकांमध्ये ही एक मानक पद्धत बनली आहे. पुरवठादारांकडून थेट हार्डवेअर मिळवणारे व्यापारी — ज्यामध्ये यांचा समावेश आहे चीनी POS टर्मिनल उत्पादकांचे B2B स्वरूप — SDK च्या खुलेपणाला खरेदी प्रक्रियेतील एक चाळणी म्हणून पाहिले पाहिजे, करारावर स्वाक्षरी झाल्यानंतर चर्चा केली जाणारी एक गौण बाब म्हणून नव्हे.
गुगल मोबाईल सर्व्हिसेस (GMS) प्रमाणीकरणामुळे, डिव्हाइसला फर्मवेअर-बंडल केलेल्या सॉफ्टवेअरपुरते मर्यादित न ठेवता, प्ले स्टोअर किंवा तत्सम व्यवस्थापित ॲप स्टोअरद्वारे मानक अँड्रॉइड ॲप पॅकेजेस चालवता येतात. GMS-प्रमाणित टर्मिनल, फोन ज्याप्रमाणे इतर कोणतेही ॲप इन्स्टॉल करतो, त्याचप्रमाणे लॉयल्टी ॲप इन्स्टॉल करू शकते: स्वतंत्रपणे, विक्रेत्याच्या स्वतःच्या रिलीज शेड्यूलनुसार आणि फर्मवेअर-स्तरीय पुन:प्रमाणन चक्राशिवाय.
टर्मिनल्सचा एक लहान पण वाढता संच लॉयल्टी ओळख कार्ड आणि फोन नंबरच्या पलीकडे बायोमेट्रिक नोंदणीपर्यंत विस्तारित करत आहे. तळहाताच्या शिरा ओळखणे हे त्याचे एक उदाहरण आहे, जे आधीच व्यावसायिक वापरामध्ये आहे. ZCS सध्या ओपन SDK सह पाम-व्हेन-सक्षम टर्मिनल्स पाठवणाऱ्या अँड्रॉइड POS उत्पादकांपैकी एक आहे, ज्यामुळे लॉयल्टी प्लॅटफॉर्मला कार्ड, ॲप किंवा फोन नंबर शोधण्याची आवश्यकता न ठेवता, चेकआउटच्या वेळी ग्राहकाच्या तळहाताच्या शिरांचा नमुना एक पर्यायी ओळखकर्ता म्हणून नोंदवता येतो. या प्रकारचे हार्डवेअर-स्तरीय ओळख वैशिष्ट्य लॉयल्टी प्लॅटफॉर्मद्वारे तेव्हाच वापरता येते, जेव्हा टर्मिनलचा SDK ते एक डॉक्युमेंटेड API म्हणून उपलब्ध करून देतो — जी नेमकी वर वर्णन केलेली ओपन-आर्किटेक्चरची आवश्यकता आहे, आणि हे कोणत्याही एका ब्रँडचे वैशिष्ट्य नाही.
लॉयल्टी सॉफ्टवेअर करारावर स्वाक्षरी करण्यापूर्वी, टर्मिनलवर खालील गोष्टींची खात्री करा:
टर्मिनल निवडीचे निकष — ओएसची खुलेपणा, प्रमाणीकरणाची व्याप्ती, एसडीकेची सखोलता — यांचा अधिक तपशीलवार आढावा यात घेतला आहे अँड्रॉइड POS प्लॅटफॉर्म निवडण्यासाठी आमची संपूर्ण चौकटजे केवळ लॉयल्टीच्या वापरापुरते मर्यादित न राहता, त्याच मूल्यांकन तर्काचे स्पष्टीकरण देते.
प्रश्न १: कोणत्याही POS टर्मिनलवर लॉयल्टी प्रोग्राम चालवता येतो का?
नाही. टर्मिनलला ओपन SDK, ॲप-स्टोअर-स्तरीय सॉफ्टवेअर वितरण आणि थर्ड-पार्टी ॲप्लिकेशन्ससाठी PCI PTS-अनुरूप सँडबॉक्सिंगची आवश्यकता असते. बंद, एकल-ॲप्लिकेशन टर्मिनल्स, लॉयल्टी विक्रेत्याचे प्लॅटफॉर्म कागदोपत्री कशाला समर्थन देते याची पर्वा न करता, लॉयल्टी सॉफ्टवेअरला प्रतिबंधित करतात किंवा पूर्णपणे ब्लॉक करतात.
प्रश्न २: POS टर्मिनल कशामुळे "लॉक-डाउन" होते?
एक लॉक-डाउन टर्मिनल इन्स्टॉल करण्यायोग्य ॲप्लिकेशन्सवर निर्बंध घालतो, कोणताही सार्वजनिक SDK उपलब्ध करून देत नाही आणि एकाच पेमेंट ॲप्लिकेशनवर आधारित फर्मवेअर चालवतो. ही वैशिष्ट्ये PCI ऑडिटची व्याप्ती कमी करतात, पण त्याचबरोबर मुळातच लॉयल्टी ॲप्स, CRM सिंक आणि इतर थर्ड-पार्टी इंटिग्रेशन्सना अवरोधित करतात.
प्रश्न ३: PCI अनुपालनामुळे लॉयल्टी ॲप्स POS हार्डवेअरवर चालवण्यास प्रतिबंध होतो का?
डीफॉल्टनुसार नाही. PCI PTS POI v7.0 तृतीय-पक्ष ॲप्लिकेशन्सना, लॉयल्टी ॲप्ससह, परवानगी देते, परंतु अट अशी आहे की त्यांना क्लिअरटेक्स्ट पेमेंट कार्ड आणि पिन डेटापासून सँडबॉक्समध्ये वेगळे ठेवले पाहिजे. अनुपालनासाठी विलगीकरण आवश्यक आहे, वगळणे नव्हे, आणि ते विलगीकरण तांत्रिकदृष्ट्या शक्य आहे की नाही हे टर्मिनलच्या आर्किटेक्चरवर अवलंबून असते.
प्रश्न ४: व्यवहारानंतरचे लॉयल्टी सिंक आणि रिअल-टाइम इंटिग्रेशन यामध्ये काय फरक आहे?
व्यवहारानंतरचे सिंक (post-transaction sync) हे पेमेंट गेटवे वेबहुकद्वारे, विक्री पूर्ण झाल्यावर रिवॉर्ड्स लागू करते. रिअल-टाइम इंटिग्रेशन (real-time integration) हे SDK हुकद्वारे, चेकआउटच्या वेळी रिवॉर्ड्स लागू करते. लॉक केलेले टर्मिनल्स सामान्यतः फक्त पहिल्या पद्धतीलाच सपोर्ट करतात, ज्यामुळे सत्रादरम्यान मिळणारी सूट आणि रिडेम्पशन्स प्रतिबंधित होतात.
प्रश्न ५: लॉयल्टी नोंदणीसाठी तळहाताच्या शिरांसारख्या बायोमेट्रिक ओळखीचा वापर केला जाऊ शकतो का?
होय, अशा टर्मिनल्सवर जिथे उत्पादक एका दस्तऐवजीकृत SDK द्वारे बायोमेट्रिक कॅप्चर उपलब्ध करून देतो. तळहाताच्या शिरा आणि तत्सम बायोमेट्रिक ओळखचिन्हे लॉयल्टी प्लॅटफॉर्मला कार्ड, फोन नंबर किंवा ॲप शोधल्याशिवाय परत येणाऱ्या ग्राहकाला ओळखू देतात, मात्र यासाठी हार्डवेअर आर्किटेक्चरने त्या डेटावर तृतीय-पक्षाच्या प्रवेशास समर्थन देणे आवश्यक आहे.
होम पेज 
सदस्यत्व आणि लॉयल्टी कार्यक्रमांसाठी तळहाताच्या शिरा ओळखण्याची प्रणाली कशी काम करते? 
