2026-08-10 લેખક : ZCS
POS ટર્મિનલ પર લોયલ્ટી પ્રોગ્રામ એક કારણસર નિષ્ફળ જાય છે: હાર્ડવેર ક્યારેય બહારના સોફ્ટવેરને અંદર આવવા દેવા માટે બનાવવામાં આવ્યું ન હતું. રિટેલર્સ લોયલ્ટી પ્લેટફોર્મ ખરીદે છે, કરાર પર હસ્તાક્ષર કરે છે, રોલઆઉટનું બજેટ બનાવે છે - પછી શોધે છે કે ટર્મિનલની ઓપરેટિંગ સિસ્ટમ, SDK અથવા ચુકવણી પ્રમાણપત્ર એકીકરણને સંપૂર્ણપણે અવરોધે છે. આ સોફ્ટવેર સમસ્યા નથી. તે હાર્ડવેર આર્કિટેક્ચર સમસ્યા છે, અને તે લગભગ દર વખતે દેખાય છે જ્યારે કોઈ વેપારી લોયલ્ટી પ્રોગ્રામ કાર્યક્ષમતા સાથે POS સિસ્ટમને ટર્મિનલ પર બોલ્ટ કરવાનો પ્રયાસ કરે છે જે ખુલ્લા કમ્પ્યુટિંગ ઉપકરણને બદલે બંધ ચુકવણી ઉપકરણ તરીકે ડિઝાઇન કરવામાં આવ્યું હતું.
કોઈપણ પ્લેટફોર્મનું મૂલ્યાંકન કરતા પહેલા, તે સમાધાન કરવામાં મદદ કરે છે POS ટર્મિનલ રિવોર્ડ ડેટા સાથે શું કરી શકે છે અને શું ન કરી શકે તે અંગેનો મૂળભૂત પ્રશ્ન — કારણ કે જવાબ સંપૂર્ણપણે તેની નીચે રહેલા હાર્ડવેર પર આધાર રાખે છે, લોયલ્ટી સોફ્ટવેરની ફીચર લિસ્ટ પર નહીં.
આ લેખ લોક-ડાઉન હાર્ડવેર પર લોયલ્ટી-ઇન્ટિગ્રેટેડ POS સિસ્ટમ નિષ્ફળ જવાના ચોક્કસ ટેકનિકલ કારણો, OS અને પ્રમાણપત્ર સ્તરે "લોક-ડાઉન" નો ખરેખર શું અર્થ થાય છે, અને ઉત્પાદનમાં ખરેખર કામ કરતી ગ્રાહક લોયલ્ટી POS સિસ્ટમની જરૂર હોય તેવા વેપારીઓ માટે મૂલ્યાંકન ચેકલિસ્ટ કેવું દેખાય છે તે વર્ણવે છે.
લૉક-ડાઉન POS હાર્ડવેર એ એક ટર્મિનલ છે જ્યાં ઉત્પાદક કઈ એપ્લિકેશનો ચલાવી શકે છે, તે એપ્લિકેશનો કયા સિસ્ટમ સંસાધનોને ઍક્સેસ કરી શકે છે, અથવા બંનેને પ્રતિબંધિત કરે છે. આ ઇરાદાપૂર્વકની ડિઝાઇન પસંદગી છે, ખામી નથી. પરંપરાગત કાર્ડ-પ્રેઝન્ટ ટર્મિનલ્સ - મુખ્યત્વે EMV અને PIN વ્યવહારો માટે બનાવવામાં આવેલા કાઉન્ટરટૉપ યુનિટ્સ - PCI PTS POI ધોરણો અનુસાર પ્રમાણિત છે જે સમગ્ર ઉપકરણને એક વિશ્વસનીય ચુકવણી વાતાવરણ તરીકે ગણે છે. તે વાતાવરણમાં લોયલ્ટી એપ્લિકેશન ઉમેરવાનો અર્થ ઐતિહાસિક રીતે કાર્ડધારક ડેટાની બાજુમાં એક વણચકાસાયેલ કોડ પાથ ઉમેરવાનો હતો, જેને ચુકવણી બ્રાન્ડ્સ અને ખરીદદારો મંજૂરી આપતા નથી.
ત્રણ હાર્ડવેર લક્ષણો લોક-ડાઉન ટર્મિનલને વ્યાખ્યાયિત કરે છે:
આમાંની કોઈપણ લાક્ષણિકતા સ્વાભાવિક રીતે ખોટી નથી. લેગસી વિક્રેતાઓ તરફથી સમર્પિત કાર્ડ-પ્રેઝન્ટ ટર્મિનલ્સ ખાસ કરીને PCI DSS ઓડિટ સ્કોપને ઘટાડવા માટે આ રીતે બનાવવામાં આવ્યા છે. સમસ્યા ત્યારે જ દેખાય છે જ્યારે કોઈ વેપારી અપેક્ષા રાખે છે કે તે જ ટર્મિનલ લોયલ્ટી પ્રોગ્રામ મોડ્યુલ, CRM સિંક અથવા માર્કેટિંગ એપ્લિકેશન સાથે POS પણ ચલાવશે - એવી ક્ષમતાઓ જે હાર્ડવેરને ક્યારેય પ્રમાણિત અથવા સપોર્ટ કરવા માટે આર્કિટેક્ટ કરવામાં આવી ન હતી.
ત્રણ વારંવાર થતા ટેકનિકલ કારણોસર ક્લોઝ્ડ આર્કિટેક્ચર પર લોયલ્ટી ઇન્ટિગ્રેશન નિષ્ફળ જાય છે: સેન્ડબોક્સિંગ નિયમો ડેટા એક્સેસને પ્રતિબંધિત કરે છે, માલિકીના SDKs બ્લોક ઇન્સ્ટોલેશન અને ફર્મવેર અપડેટ સાયકલ સ્ટોલ ફીચર રોલઆઉટ્સ.
PCI સુરક્ષા ધોરણો કાઉન્સિલ દ્વારા પ્રકાશિત PCI PTS POI સંસ્કરણ 7.0, હવે પ્રમાણિત POI ઉપકરણો પર ચલાવવા માટે એપ-સ્ટોર એપ્લિકેશન્સ જેવી તૃતીય-પક્ષ એપ્લિકેશનોને મંજૂરી આપે છે. પરંતુ ધોરણ માટે તે એપ્લિકેશનો જરૂરી છે સંવેદનશીલ ચુકવણી કાર્યોથી સુરક્ષિત રીતે અલગ અને ક્રિપ્ટોગ્રાફિક નિયંત્રણોનો ઉપયોગ કરીને પ્રમાણિત. સમાન સંસ્કરણમાં એક નવી આવશ્યકતા તૃતીય-પક્ષ એપ્લિકેશનોને ક્લિયરટેક્સ્ટ PAN અથવા PIN ડેટા વાંચવાથી અવરોધે છે, ભલે એપ્લિકેશન માન્ય વ્હાઇટલિસ્ટમાં હોય. લોયલ્ટી એન્જિન માટે, આ સીધું મહત્વનું છે: કોઈપણ ઇન્ટિગ્રેશન પેટર્ન જે ધારે છે કે લોયલ્ટી એપ્લિકેશન વ્યવહાર કુલ, કાર્ડ ટોકન અથવા ગ્રાહક ઓળખકર્તાને ચુકવણી પ્રક્રિયામાંથી સીધા જ વાંચી શકે છે તે v7.0-પ્રમાણિત ઉપકરણ પર સુસંગત નથી. લોયલ્ટી એપ્લિકેશનને તે ડેટા માન્ય, અલગ ચેનલ દ્વારા પ્રાપ્ત કરવો પડે છે - અને ઘણા લૉક કરેલા ટર્મિનલ્સ પર, આવી કોઈ ચેનલ અસ્તિત્વમાં નથી.
લોયલ્ટી પ્લેટફોર્મને ગ્રાહકોની નોંધણી કરવાની, પોઈન્ટ બેલેન્સ શોધવાની, રિડેમ્પશન લાગુ કરવાની અને વેચાણ બિંદુ પર પુરસ્કારો છાપવાની અથવા પ્રદર્શિત કરવાની જરૂર છે. તે દરેક ક્રિયા માટે SDK હૂકની જરૂર હોય છે. બંધ, વિક્રેતા-માલિકીનું OS ધરાવતા ટર્મિનલ્સ સામાન્ય રીતે આમાંથી કોઈ પણ હૂક બહારના વિકાસકર્તાઓને ખુલ્લા પાડતા નથી - વ્યવહાર પહેલાથી જ બંધ થઈ ગયા પછી લોયલ્ટી વિક્રેતાને ચુકવણી ગેટવે વેબહૂક દ્વારા એકીકૃત કરવાનું છોડી દેવામાં આવે છે, જે રીઅલ-ટાઇમ ડિસ્કાઉન્ટ લાગુ કરવા અથવા ઇન-સેશન રિવોર્ડ ટ્રિગર કરવા માટે ખૂબ મોડું છે. લેગસી કાઉન્ટરટૉપ ટર્મિનલ્સથી POS લોયલ્ટી પ્રોગ્રામ ડિપ્લોયમેન્ટમાં જતા વેપારીઓ દ્વારા નોંધાયેલ આ એકમાત્ર સૌથી સામાન્ય નિષ્ફળતા પેટર્ન છે: એકીકરણ તકનીકી રીતે પોસ્ટ-ટ્રાન્ઝેક્શન સિંક તરીકે "કામ કરે છે", પરંતુ ક્રિયાપ્રતિક્રિયાના બિંદુ પર જ કંઈ કરી શકતું નથી.
જ્યાં લૉક કરેલ ટર્મિનલ મર્યાદિત SDK ને ખુલ્લા પાડે છે, ત્યાં પણ સિંગલ-પર્પઝ પેમેન્ટ ડિવાઇસ પર ફર્મવેર સામાન્ય રીતે ધીમા, પ્રમાણપત્ર-આધારિત શેડ્યૂલ પર અપડેટ થાય છે, કારણ કે દરેક ફર્મવેર ફેરફાર PCI પુનઃપ્રમાણપત્રને ટ્રિગર કરી શકે છે. એક લોયલ્ટી વિક્રેતા જે નવો રિડેમ્પશન નિયમ, નવો નોંધણી પ્રવાહ અથવા નવો રિવોર્ડ ટાયર મોકલવા માંગે છે તેણે હાર્ડવેર વિક્રેતાના રિલીઝ ચક્રની રાહ જોવી પડે છે - તેમના પોતાના નહીં. ખુલ્લા Android POS ટર્મિનલ પર, લોયલ્ટી એપ્લિકેશન તેના પોતાના એપ્લિકેશન પેકેજ દ્વારા સ્વતંત્ર રીતે અપડેટ થાય છે, જેમાં ટર્મિનલ ફર્મવેર પર કોઈ નિર્ભરતા હોતી નથી.
નિષ્ફળ એકીકરણનો સીધો ખર્ચ અટકી ગયેલો અથવા ઉલટાવેલ રોલઆઉટ છે, પરંતુ મોટો ખર્ચ વ્યૂહાત્મક છે: રિટેલર્સ વધતા દરે લોયલ્ટી સોફ્ટવેર ખરીદતા રહે છે જ્યારે હાર્ડવેર સુસંગતતા પછીથી વિચારવામાં આવે છે. વૈશ્વિક લોયલ્ટી મેનેજમેન્ટ માર્કેટ 2026 માં અંદાજિત $17.38 બિલિયન સુધી પહોંચ્યું હતું, અને 2034 સુધીમાં 14% થી વધુ ચક્રવૃદ્ધિ વાર્ષિક દરે વૃદ્ધિ પામવાનો અંદાજ છે. ચેકઆઉટ હાર્ડવેર પર ખરેખર ચાલી ન શકે તેવા લોયલ્ટી પ્લેટફોર્મ પર ખર્ચવામાં આવેલ દરેક ડોલર બે વાર ખર્ચવામાં આવેલ ડોલર છે - એકવાર સોફ્ટવેર પર, ફરી એકવાર હાર્ડવેર રિફ્રેશ પર જે પહેલા થવું જોઈતું હતું.
પાલન ખર્ચ પણ છે. લોયલ્ટી પ્રોગ્રામ્સ વ્યક્તિગત ગ્રાહક ડેટા - નામો, ફોન નંબરો, ખરીદી ઇતિહાસ, ક્યારેક ટેપ-ટુ-આઇડેન્ટિફાઇ પ્રોગ્રામ્સ માટે બાયોમેટ્રિક નોંધણી ડેટા - એકત્રિત કરે છે અને પ્રક્રિયા કરે છે. EU નિયમન હેઠળ. ૨૦૧૬/૬૭૯ (જીડીપીઆર), તે પ્રક્રિયા માટે નોંધણી સમયે દસ્તાવેજીકૃત કાયદેસર આધાર અને સુસંગત સંમતિ પ્રવાહની જરૂર હોય છે. બિનસત્તાવાર ઉકેલ - જેલબ્રોકન ટર્મિનલ, અસમર્થિત સાઇડલોડેડ APK, સ્ક્રીન-સ્ક્રેપિંગ બ્રિજ - દ્વારા ફરજિયાત વફાદારી એકીકરણ ઓડિટ દરમિયાન તે પાલન દસ્તાવેજીકરણ ઉત્પન્ન કરવાનું વધુ મુશ્કેલ બનાવે છે, કારણ કે ડેટા પાથ પોતે ક્યારેય સમીક્ષા કરવા માટે ડિઝાઇન કરવામાં આવ્યો ન હતો.
એક આર્કિટેક્ચર જે વફાદારીને ટેકો આપે છે તે વિશ્વસનીય રીતે ત્રણ લક્ષણો શેર કરે છે: એક ઓપન SDK, એપ-સ્ટોર-લેવલ સોફ્ટવેર વિતરણ અને હાર્ડવેર ઓળખ સુવિધાઓ જે કાર્ડ સ્વાઇપથી આગળ વધે છે.
પ્રકાશિત SDK સાથેના Android-આધારિત POS ટર્મિનલ્સ, દરેક નવી સુવિધા માટે હાર્ડવેર ઉત્પાદકની રાહ જોયા વિના, લોયલ્ટી વિક્રેતાને પ્રિન્ટર, સ્કેનર, ગ્રાહક-સામનો ડિસ્પ્લે અને ચુકવણી કર્નલ માટે દસ્તાવેજીકૃત API સામે સીધા જ બિલ્ડ કરવાની મંજૂરી આપે છે. આ એ જ ઓપન-પ્લેટફોર્મ મોડેલ છે જે સ્ક્વેરના ટર્મિનલ API એ તેના પોતાના હાર્ડવેર માટે રજૂ કર્યું હતું, અને તે હવે મોટાભાગના Android POS ઉત્પાદકોમાં પ્રમાણભૂત પ્રથા છે જે બંધ સિંગલ-એપ કિઓસ્કને બદલે મલ્ટિ-વેન્ડર રિટેલ વાતાવરણમાં વેચાણ કરે છે. વેપારીઓ સપ્લાય બેઝમાંથી સીધા જ હાર્ડવેર સોર્સ કરે છે - જેમાં ચાઇનીઝ POS ટર્મિનલ ઉત્પાદકોનું B2B લેન્ડસ્કેપ — SDK ઓપનનેસને ખરીદી ફિલ્ટર તરીકે ગણવી જોઈએ, કરાર પર હસ્તાક્ષર થયા પછી જ ચર્ચા કરાયેલ વિચારણા તરીકે નહીં.
ગૂગલ મોબાઇલ સર્વિસીસ (GMS) સર્ટિફિકેશન ટર્મિનલને ફર્મવેર-બંડલ્ડ સોફ્ટવેર સુધી મર્યાદિત રાખવાને બદલે, પ્લે સ્ટોર અથવા સમકક્ષ મેનેજ્ડ એપ સ્ટોર દ્વારા માનક એન્ડ્રોઇડ એપ પેકેજ ચલાવવાની મંજૂરી આપે છે. GMS-પ્રમાણિત ટર્મિનલ લોયલ્ટી એપ ઇન્સ્ટોલ કરી શકે છે જે રીતે ફોન કોઈપણ અન્ય એપ ઇન્સ્ટોલ કરે છે: સ્વતંત્ર રીતે, વિક્રેતાના પોતાના રિલીઝ શેડ્યૂલ પર, ફર્મવેર-સ્તરના પુનઃપ્રમાણીકરણ ચક્ર વિના.
નાના પણ વધતા જતા ટર્મિનલ્સ કાર્ડ અને ફોન નંબરોથી આગળ વધીને બાયોમેટ્રિક નોંધણીમાં વફાદારી ઓળખનો વિસ્તાર કરે છે. પામ વેઇન રેકગ્નિશન એ પહેલાથી જ વ્યાપારી જમાવટમાં એક ઉદાહરણ છે - ZCS હાલમાં ઓપન SDK સાથે પામ-નસ-સક્ષમ ટર્મિનલ્સનું વિતરણ કરતા Android POS ઉત્પાદકોમાંનું એક છે, જે લોયલ્ટી પ્લેટફોર્મને કાર્ડ, એપ્લિકેશન અથવા ફોન નંબર લુકઅપની જરૂર પડવાને બદલે ચેકઆઉટ સમયે ગ્રાહકના પામ નસ પેટર્નને વૈકલ્પિક ઓળખકર્તા તરીકે નોંધણી કરવાની મંજૂરી આપે છે. આ પ્રકારની હાર્ડવેર-સ્તરની ઓળખ સુવિધા ફક્ત ત્યારે જ લોયલ્ટી પ્લેટફોર્મ દ્વારા ઉપયોગમાં લેવાય છે જ્યારે ટર્મિનલનું SDK તેને દસ્તાવેજીકૃત API તરીકે રજૂ કરે છે - જે બરાબર ઉપર વર્ણવેલ ઓપન-આર્કિટેક્ચર આવશ્યકતા છે, કોઈ એક બ્રાન્ડ માટે વિશિષ્ટ સુવિધા નથી.
લોયલ્ટી સોફ્ટવેર કરાર પર હસ્તાક્ષર કરતા પહેલા, ટર્મિનલ બાજુ પર નીચેની બાબતોની પુષ્ટિ કરો:
ટર્મિનલ પસંદગીના માપદંડો — OS ઓપનનેસ, સર્ટિફિકેશન સ્કોપ, SDK ડેપ્થ — વધુ વિગતવાર આવરી લેવામાં આવ્યા છે Android POS પ્લેટફોર્મ પસંદ કરવા માટેનું અમારું સંપૂર્ણ માળખું, જે ફક્ત લોયલ્ટી ઉપયોગના કેસોથી આગળ સમાન મૂલ્યાંકન તર્કમાંથી પસાર થાય છે.
પ્રશ્ન ૧: શું કોઈ POS ટર્મિનલ લોયલ્ટી પ્રોગ્રામ ચલાવી શકે છે?
ના. ટર્મિનલને તૃતીય-પક્ષ એપ્લિકેશનો માટે ઓપન SDK, એપ-સ્ટોર-લેવલ સોફ્ટવેર વિતરણ અને PCI PTS-સુસંગત સેન્ડબોક્સિંગની જરૂર હોય છે. બંધ, સિંગલ-એપ્લિકેશન ટર્મિનલ્સ લોયલ્ટી સોફ્ટવેરને સંપૂર્ણપણે પ્રતિબંધિત અથવા અવરોધિત કરે છે, પછી ભલે લોયલ્ટી વિક્રેતાનું પ્લેટફોર્મ કાગળ પર શું સપોર્ટ કરે છે તે ધ્યાનમાં લીધા વિના.
પ્રશ્ન ૨: POS ટર્મિનલ "લોક-ડાઉન" કેમ બને છે?
લૉક-ડાઉન ટર્મિનલ ઇન્સ્ટોલ કરી શકાય તેવી એપ્લિકેશનોને પ્રતિબંધિત કરે છે, કોઈ જાહેર SDK ને પ્રદર્શિત કરતું નથી, અને એક જ ચુકવણી એપ્લિકેશનની આસપાસ બનેલા ફર્મવેર ચલાવે છે. આ લક્ષણો PCI ઓડિટ સ્કોપ ઘટાડે છે પણ ડિઝાઇન દ્વારા લોયલ્ટી એપ્લિકેશન્સ, CRM સિંક અને અન્ય તૃતીય-પક્ષ એકીકરણને પણ અવરોધિત કરે છે.
પ્રશ્ન ૩: શું PCI પાલન લોયલ્ટી એપ્સને POS હાર્ડવેર પર ચાલતા અટકાવે છે?
ડિફૉલ્ટ રૂપે નહીં. PCI PTS POI v7.0 તૃતીય-પક્ષ એપ્લિકેશનોને મંજૂરી આપે છે, જેમાં લોયલ્ટી એપ્લિકેશન્સનો સમાવેશ થાય છે, જો કે તેઓ ક્લિયરટેક્સ્ટ પેમેન્ટ કાર્ડ અને PIN ડેટાથી દૂર સેન્ડબોક્સ કરેલી હોય. પાલન માટે અલગતાની જરૂર છે, બાકાત નહીં, અને ટર્મિનલનું આર્કિટેક્ચર નક્કી કરે છે કે તે અલગતા તકનીકી રીતે શક્ય છે કે નહીં.
પ્રશ્ન ૪: વ્યવહાર પછીના લોયલ્ટી સિંક અને રીઅલ-ટાઇમ ઇન્ટિગ્રેશન વચ્ચે શું તફાવત છે?
વેચાણ બંધ થયા પછી, પેમેન્ટ ગેટવે વેબહૂક દ્વારા, પોસ્ટ-ટ્રાન્ઝેક્શન સિંક રિવોર્ડ્સ લાગુ કરે છે. રીઅલ-ટાઇમ ઇન્ટિગ્રેશન ચેકઆઉટ દરમિયાન, SDK હૂક દ્વારા રિવોર્ડ્સ લાગુ કરે છે. લૉક કરેલા ટર્મિનલ્સ સામાન્ય રીતે ફક્ત પહેલા ટર્મિનલ્સને જ સપોર્ટ કરે છે, જે સત્રમાં ડિસ્કાઉન્ટ અને રિડેમ્પશનને અટકાવે છે.
પ્રશ્ન ૫: શું બાયોમેટ્રિક ઓળખ, જેમ કે પામ નસ,નો ઉપયોગ લોયલ્ટી નોંધણી માટે થઈ શકે છે?
હા, એવા ટર્મિનલ્સ પર જ્યાં ઉત્પાદક દસ્તાવેજીકૃત SDK દ્વારા બાયોમેટ્રિક કેપ્ચરનો ખુલાસો કરે છે. પામ વેઇન અને સમાન બાયોમેટ્રિક ઓળખકર્તાઓ લોયલ્ટી પ્લેટફોર્મને કાર્ડ, ફોન નંબર અથવા એપ્લિકેશન લુકઅપ વિના પરત આવતા ગ્રાહકને ઓળખવા દે છે, જો હાર્ડવેર આર્કિટેક્ચર તે ડેટાની તૃતીય-પક્ષ ઍક્સેસને સપોર્ટ કરે છે.
મુખ્ય પૃષ્ઠ 
સભ્યપદ અને વફાદારી કાર્યક્રમો માટે પામ વેઇન રેકગ્નિશન કેવી રીતે કાર્ય કરે છે? 
