२०२४-१०-३१ लेखक: ZCS
POS टर्मिनलमा वफादारी कार्यक्रम असफल हुनुको एउटा कारण अरू कुनै पनि भन्दा बढी हो: हार्डवेयर कहिल्यै बाहिरी सफ्टवेयर भित्र जान दिनको लागि बनाइएको थिएन। खुद्रा विक्रेताहरूले वफादारी प्लेटफर्म किन्छन्, सम्झौतामा हस्ताक्षर गर्छन्, रोलआउटको बजेट बनाउँछन् — त्यसपछि टर्मिनलको अपरेटिङ सिस्टम, SDK, वा भुक्तानी प्रमाणीकरणले एकीकरणलाई पूर्ण रूपमा रोक्छ भनेर पत्ता लगाउँछन्। यो सफ्टवेयर समस्या होइन। यो हार्डवेयर वास्तुकला समस्या हो, र यो लगभग हरेक पटक देखा पर्दछ जब व्यापारीले वफादारी कार्यक्रम कार्यक्षमता भएको pos प्रणालीलाई टर्मिनलमा बोल्ट गर्ने प्रयास गर्दछ जुन खुला कम्प्युटिङ उपकरणको सट्टा बन्द भुक्तानी उपकरणको रूपमा डिजाइन गरिएको थियो।
कुनै पनि प्लेटफर्मको मूल्याङ्कन गर्नु अघि, यसले समाधान गर्न मद्दत गर्दछ पुरस्कार डेटासँग POS टर्मिनलले के गर्न सक्छ र के गर्न सक्दैन भन्ने आधारभूत प्रश्न — किनभने उत्तर पूर्णतया यसको मुनि रहेको हार्डवेयरमा निर्भर गर्दछ, लोयल्टी सफ्टवेयरको सुविधा सूचीमा होइन।
यस लेखले लक-डाउन हार्डवेयरमा वफादारी-एकीकृत पोस प्रणालीहरू असफल हुनुका विशिष्ट प्राविधिक कारणहरू, ओएस र प्रमाणीकरण स्तरमा "लक-डाउन" को अर्थ के हो, र उत्पादनमा वास्तवमा काम गर्ने ग्राहक वफादारी पोस प्रणाली चाहिने व्यापारीहरूको लागि मूल्याङ्कन चेकलिस्ट कस्तो देखिन्छ भन्ने कुराहरू वर्णन गर्दछ।
लक-डाउन POS हार्डवेयर एउटा टर्मिनल हो जहाँ निर्माताले कुन अनुप्रयोगहरू चलाउन सक्छन्, कुन प्रणाली स्रोतहरू ती अनुप्रयोगहरूले पहुँच गर्न सक्छन्, वा दुवैलाई प्रतिबन्धित गर्दछ। यो जानाजानी डिजाइन गरिएको छनोट हो, दोष होइन। परम्परागत कार्ड-प्रस्तुत टर्मिनलहरू - मुख्यतया EMV र PIN लेनदेनको लागि निर्मित काउन्टरटप एकाइहरू - PCI PTS POI मापदण्डहरूमा प्रमाणित छन् जसले सम्पूर्ण उपकरणलाई एकल विश्वसनीय भुक्तानी वातावरणको रूपमा व्यवहार गर्दछ। त्यो वातावरणमा वफादारी एप थप्नुको अर्थ ऐतिहासिक रूपमा कार्डधारक डेटाको छेउमा एक अप्रमाणित कोड मार्ग थप्नु हो, जुन भुक्तानी ब्रान्डहरू र प्राप्तकर्ताहरूले अनुमति दिँदैनन्।
तीन हार्डवेयर विशेषताहरूले लक-डाउन टर्मिनललाई परिभाषित गर्छन्:
यी कुनै पनि विशेषताहरू स्वाभाविक रूपमा गलत छैनन्। लिगेसी विक्रेताहरूबाट समर्पित कार्ड-प्रस्तुत टर्मिनलहरू PCI DSS अडिट स्कोपलाई कम गर्न विशेष रूपमा यस तरिकाले इन्जिनियर गरिएका छन्। समस्या तब मात्र देखा पर्दछ जब व्यापारीले त्यही टर्मिनलले वफादारी कार्यक्रम मोड्युल, CRM सिंक, वा मार्केटिङ एपको साथ पोज पनि चलाउने अपेक्षा गर्दछ - ती क्षमताहरू जुन हार्डवेयरलाई समर्थन गर्न कहिल्यै प्रमाणित वा आर्किटेक्ट गरिएको थिएन।
तीन आवर्ती प्राविधिक कारणहरूले गर्दा बन्द आर्किटेक्चरहरूमा वफादारी एकीकरण असफल हुन्छ: स्यान्डबक्सिङ नियमहरूले डेटा पहुँचलाई प्रतिबन्धित गर्दछ, स्वामित्व SDK हरू स्थापनालाई रोक्छ, र फर्मवेयर अपडेट चक्रहरू सुविधा रोलआउटहरू रोक्छ।
PCI सुरक्षा मानक परिषद् द्वारा प्रकाशित PCI PTS POI संस्करण ७.० ले अब प्रमाणित POI उपकरणहरूमा एप-स्टोर एपहरू जस्ता तेस्रो-पक्ष अनुप्रयोगहरू चलाउन अनुमति दिन्छ। तर मानकले ती अनुप्रयोगहरूलाई संवेदनशील भुक्तानी कार्यहरूबाट सुरक्षित रूपमा अलग गरिएको र क्रिप्टोग्राफिक नियन्त्रणहरू प्रयोग गरेर प्रमाणित गरिएको। उही संस्करणमा रहेको नयाँ आवश्यकताले तेस्रो-पक्ष अनुप्रयोगहरूलाई स्वीकृत श्वेतसूचीमा हुँदा पनि स्पष्ट टेक्स्ट PAN वा PIN डेटा पढ्नबाट रोक्छ। लोयल्टी इन्जिनको लागि, यो सीधै महत्त्वपूर्ण छ: कुनै पनि एकीकरण ढाँचा जसले लोयल्टी एपलाई लेनदेनको कुल, कार्ड टोकन, वा ग्राहक पहिचानकर्तालाई भुक्तानी प्रक्रियाबाट सिधै पढ्न सक्छ भन्ने मान्दछ, v7.0-प्रमाणित उपकरणमा अनुरूप छैन। लोयल्टी एपले त्यो डेटा स्वीकृत, पृथक च्यानल मार्फत प्राप्त गर्नुपर्छ — र धेरै लक गरिएका टर्मिनलहरूमा, त्यस्तो कुनै च्यानल अवस्थित छैन।
एउटा वफादारी प्लेटफर्मले ग्राहकहरूलाई भर्ना गर्न, पोइन्ट ब्यालेन्स हेर्न, रिडेम्पसन लागू गर्न, र बिक्री बिन्दुमा पुरस्कारहरू छाप्न वा प्रदर्शन गर्न आवश्यक छ। ती प्रत्येक कार्यलाई SDK हुक चाहिन्छ। बन्द, विक्रेता-स्वामित्व OS भएका टर्मिनलहरूले सामान्यतया यी कुनै पनि हुकहरू बाहिरी विकासकर्ताहरूलाई खुलासा गर्दैनन् - लेनदेन पहिले नै बन्द भइसकेपछि वफादारी विक्रेतालाई भुक्तानी गेटवे वेबहुक मार्फत एकीकृत गर्न छोडिन्छ, जुन वास्तविक-समय छुट लागू गर्न वा सत्र-सत्र पुरस्कार ट्रिगर गर्न धेरै ढिलो हुन्छ। यो व्यापारीहरूले लिगेसी काउन्टरटप टर्मिनलहरूबाट pos वफादारी कार्यक्रम तैनातीहरूमा सर्ने रिपोर्ट गरेको सबैभन्दा सामान्य असफलता ढाँचा हो: एकीकरणले प्राविधिक रूपमा लेनदेन पछिको सिङ्कको रूपमा "काम गर्दछ", तर अन्तरक्रियाको बिन्दुमा आफैंमा केही गर्न सक्दैन।
लक गरिएको टर्मिनलले सीमित SDK लाई उजागर गर्ने ठाउँमा पनि, एकल-उद्देश्य भुक्तानी उपकरणहरूमा फर्मवेयर सामान्यतया ढिलो, प्रमाणीकरण-संचालित तालिकामा अद्यावधिक गरिन्छ, किनकि प्रत्येक फर्मवेयर परिवर्तनले PCI पुन: प्रमाणीकरण ट्रिगर गर्न सक्छ। नयाँ रिडेम्पसन नियम, नयाँ नामांकन प्रवाह, वा नयाँ पुरस्कार तह पठाउन चाहने वफादारी विक्रेताले हार्डवेयर विक्रेताको रिलीज चक्रको लागि पर्खनु पर्छ - तिनीहरूको आफ्नै होइन। खुला एन्ड्रोइड POS टर्मिनलमा, वफादारी एपले आफ्नै एप प्याकेज मार्फत स्वतन्त्र रूपमा अपडेट गर्छ, टर्मिनल फर्मवेयरमा कुनै निर्भरता बिना।
असफल एकीकरणको प्रत्यक्ष लागत रोकिएको वा उल्टो रोलआउट हो, तर ठूलो लागत रणनीतिक छ: खुद्रा विक्रेताहरूले बढ्दो दरमा वफादारी सफ्टवेयर किन्न जारी राख्छन् जबकि हार्डवेयर अनुकूलता पछिको विचारमा रहन्छ। विश्वव्यापी वफादारी व्यवस्थापन बजार २०२६ मा अनुमानित $१७.३८ बिलियन पुगेको थियो, र २०३४ सम्म १४% भन्दा माथिको चक्रवृद्धि वार्षिक दरमा बढ्ने अनुमान गरिएको छ। चेकआउट हार्डवेयरमा वास्तवमा चल्न नसक्ने वफादारी प्लेटफर्ममा खर्च गरिएको प्रत्येक डलर दुई पटक खर्च गरिएको डलर हो - एक पटक सफ्टवेयरमा, एक पटक फेरि पहिले हुनु पर्ने हार्डवेयर रिफ्रेसमा।
अनुपालन लागत पनि छ। वफादारी कार्यक्रमहरूले व्यक्तिगत ग्राहक डेटा सङ्कलन र प्रशोधन गर्छन् — नाम, फोन नम्बर, खरिद इतिहास, कहिलेकाहीँ ट्याप-टु-पहिचान कार्यक्रमहरूको लागि बायोमेट्रिक नामांकन डेटा। EU नियमन अन्तर्गत। २०१६/६७९ (जीडीपीआर), त्यो प्रशोधनको लागि एक दस्तावेजीकृत कानूनी आधार र नामांकनमा अनुपालन सहमति प्रवाह आवश्यक पर्दछ। एक अनौपचारिक समाधान - एक जेलब्रोकन टर्मिनल, एक असमर्थित साइडलोडेड APK, एक स्क्रिन-स्क्र्यापिंग ब्रिज - मार्फत बाध्य पारिएको वफादारी एकीकरणले लेखा परीक्षणको क्रममा त्यो अनुपालन कागजात उत्पादन गर्न धेरै गाह्रो बनाउँछ, किनकि डेटा मार्ग आफैं कहिल्यै समीक्षा गर्न डिजाइन गरिएको थिएन।
वफादारीलाई समर्थन गर्ने वास्तुकलाले भरपर्दो रूपमा तीन विशेषताहरू साझा गर्दछ: खुला SDK, एप-स्टोर-स्तर सफ्टवेयर वितरण, र कार्ड स्वाइपभन्दा बाहिर जाने हार्डवेयर पहिचान सुविधाहरू।
प्रकाशित SDK भएको एन्ड्रोइड-आधारित POS टर्मिनलहरूले एक वफादार विक्रेतालाई प्रिन्टर, स्क्यानर, ग्राहक-मुखी प्रदर्शन, र भुक्तानी कर्नेलको लागि दस्तावेज गरिएका API हरू विरुद्ध सिधै निर्माण गर्न दिन्छ - प्रत्येक नयाँ सुविधाको लागि हार्डवेयर निर्मातालाई पर्खनु पर्दैन। यो उही खुला-प्लेटफर्म मोडेल हो जुन स्क्वायरको टर्मिनल API ले आफ्नै हार्डवेयरको लागि प्रस्तुत गरेको थियो, र यो अब धेरैजसो एन्ड्रोइड POS निर्माताहरूमा मानक अभ्यास हो जसले बन्द एकल-एप किओस्कहरूको सट्टा बहु-विक्रेता खुद्रा वातावरणमा बेच्छन्। व्यापारीहरूले आपूर्ति आधारबाट सिधै हार्डवेयर सोर्स गर्दै - सहित चिनियाँ POS टर्मिनल निर्माताहरूको B2B परिदृश्य — SDK खुलापनलाई खरिद फिल्टरको रूपमा व्यवहार गर्नुपर्छ, सम्झौतामा हस्ताक्षर भएपछि मात्र छलफल गरिने विचारको रूपमा होइन।
गुगल मोबाइल सेवाहरू (GMS) प्रमाणीकरणले टर्मिनललाई फर्मवेयर-बन्डल गरिएको सफ्टवेयरमा सीमित गर्नुको सट्टा प्ले स्टोर वा समकक्ष व्यवस्थित एप स्टोर मार्फत मानक एन्ड्रोइड एप प्याकेजहरू चलाउन अनुमति दिन्छ। GMS-प्रमाणित टर्मिनलले फोनले अन्य कुनै पनि एप स्थापना गरे जस्तै लोयल्टी एप स्थापना गर्न सक्छ: स्वतन्त्र रूपमा, विक्रेताको आफ्नै रिलीज तालिकामा, फर्मवेयर-स्तर पुन: प्रमाणीकरण चक्र बिना।
सानो तर बढ्दो टर्मिनलहरूको सेटले कार्ड र फोन नम्बरहरू भन्दा पहिले वफादारी पहिचानलाई बायोमेट्रिक नामांकनमा विस्तार गर्दछ। पाम नसा पहिचान पहिले नै व्यावसायिक तैनातीमा रहेको एउटा उदाहरण हो — ZCS एन्ड्रोइड POS निर्माताहरू मध्ये एक हो जसले हाल खुला SDK सहित पाम-शिरा-सक्षम टर्मिनलहरू ढुवानी गर्दछ, जसले लोयल्टी प्लेटफर्मलाई कार्ड, एप, वा फोन नम्बर लुकअपको आवश्यकता पर्नुको सट्टा चेकआउटमा ग्राहकको पाम शिरा ढाँचालाई वैकल्पिक पहिचानकर्ताको रूपमा दर्ता गर्न अनुमति दिन्छ। यस प्रकारको हार्डवेयर-स्तर पहिचान सुविधा केवल लोयल्टी प्लेटफर्म द्वारा मात्र प्रयोग गर्न सकिन्छ जब टर्मिनलको SDK ले यसलाई दस्तावेजीकृत API को रूपमा उजागर गर्दछ - जुन माथि वर्णन गरिएको खुला-वास्तुकला आवश्यकता हो, कुनै एक ब्रान्डको लागि अद्वितीय सुविधा होइन।
लोयल्टी सफ्टवेयर सम्झौतामा हस्ताक्षर गर्नु अघि, टर्मिनल पक्षमा निम्न कुराहरू पुष्टि गर्नुहोस्:
टर्मिनल छनोट मापदण्ड — OS खुलापन, प्रमाणीकरण दायरा, SDK गहिराई — मा थप विवरणमा समेटिएका छन् एन्ड्रोइड POS प्लेटफर्म छनौट गर्ने हाम्रो पूर्ण रूपरेखा, जुन वफादारी प्रयोगका केसहरूभन्दा बाहिर उही मूल्याङ्कन तर्क मार्फत हिंड्छ।
Q1: के कुनै पनि POS टर्मिनलले वफादारी कार्यक्रम चलाउन सक्छ?
होइन। टर्मिनललाई तेस्रो-पक्ष अनुप्रयोगहरूको लागि खुला SDK, एप-स्टोर-स्तर सफ्टवेयर वितरण, र PCI PTS-अनुरूप स्यान्डबक्सिङ चाहिन्छ। बन्द, एकल-अनुप्रयोग टर्मिनलहरूले वफादारी सफ्टवेयरलाई पूर्ण रूपमा प्रतिबन्धित वा ब्लक गर्छन्, कागजमा वफादारी विक्रेताको प्लेटफर्मले के समर्थन गर्छ भन्ने कुराको पर्वाह नगरी।
Q2: POS टर्मिनललाई "लक-डाउन" किन बनाउँछ?
लक गरिएको टर्मिनलले स्थापना गर्न सकिने अनुप्रयोगहरूलाई प्रतिबन्धित गर्छ, कुनै सार्वजनिक SDK लाई खुलासा गर्दैन, र एकल भुक्तानी अनुप्रयोग वरिपरि निर्मित फर्मवेयर चलाउँछ। यी विशेषताहरूले PCI अडिट स्कोप घटाउँछन् तर डिजाइनद्वारा वफादारी एपहरू, CRM सिंकहरू, र अन्य तेस्रो-पक्ष एकीकरणहरूलाई पनि रोक्छन्।
Q3: के PCI अनुपालनले लोयल्टी एपहरूलाई POS हार्डवेयरमा चल्नबाट रोक्छ?
पूर्वनिर्धारित रूपमा होइन। PCI PTS POI v7.0 ले तेस्रो-पक्ष अनुप्रयोगहरूलाई अनुमति दिन्छ, जसमा वफादारी अनुप्रयोगहरू पनि समावेश छन्, यदि तिनीहरू क्लियरटेक्स्ट भुक्तानी कार्ड र PIN डेटाबाट स्यान्डबक्समा छन् भने। अनुपालनलाई बहिष्कार होइन, अलगाव आवश्यक छ, र टर्मिनलको वास्तुकलाले त्यो अलगाव प्राविधिक रूपमा सम्भव छ कि छैन भनेर निर्धारण गर्दछ।
Q4: लेनदेन पछिको वफादारी सिङ्क र वास्तविक-समय एकीकरण बीच के भिन्नता छ?
बिक्री बन्द भएपछि, भुक्तानी गेटवे वेबहुक मार्फत, लेनदेन पछिको सिङ्कले पुरस्कारहरू लागू गर्दछ। वास्तविक-समय एकीकरणले चेकआउटको समयमा, SDK हुक मार्फत पुरस्कारहरू लागू गर्दछ। लक गरिएका टर्मिनलहरूले सामान्यतया पहिलेलाई मात्र समर्थन गर्दछ, जसले सत्रमा छुट र रिडेम्पसनहरूलाई रोक्छ।
प्रश्न ५: के पाम भेन जस्ता बायोमेट्रिक पहिचान, वफादारी दर्ताको लागि प्रयोग गर्न सकिन्छ?
हो, टर्मिनलहरूमा जहाँ निर्माताले कागजात गरिएको SDK मार्फत बायोमेट्रिक क्याप्चरलाई उजागर गर्दछ। पाम भेन र समान बायोमेट्रिक पहिचानकर्ताहरूले कार्ड, फोन नम्बर, वा एप लुकअप बिना फर्कने ग्राहकलाई वफादारी प्लेटफर्मले पहिचान गर्न दिन्छ, यदि हार्डवेयर आर्किटेक्चरले त्यो डेटामा तेस्रो-पक्ष पहुँचलाई समर्थन गर्दछ भने।
गृहपृष्ठ 
सदस्यता र वफादारी कार्यक्रमहरूको लागि पाम भेन पहिचानले कसरी काम गर्छ? 
