2026-08-10 ავტორი: ZCS
ლოიალობის პროგრამა POS ტერმინალზე ერთი მიზეზის გამო ვერ ხერხდება: აპარატურა არასდროს ყოფილა შექმნილი გარე პროგრამული უზრუნველყოფის შეღწევისთვის. საცალო მოვაჭრეები ყიდულობენ ლოიალობის პლატფორმას, ხელს აწერენ კონტრაქტს, ადგენენ ბიუჯეტს დანერგვისთვის - შემდეგ აღმოაჩენენ, რომ ტერმინალის ოპერაციული სისტემა, SDK ან გადახდის სერტიფიკატი მთლიანად ბლოკავს ინტეგრაციას. ეს არ არის პროგრამული უზრუნველყოფის პრობლემა. ეს არის აპარატურის არქიტექტურის პრობლემა და ის თითქმის ყოველთვის ჩნდება, როდესაც ვაჭარი ცდილობს ლოიალობის პროგრამის ფუნქციონალის მქონე POS სისტემის დამონტაჟებას ტერმინალზე, რომელიც შექმნილია როგორც დახურული გადახდის მოწყობილობა და არა როგორც ღია გამოთვლითი მოწყობილობა.
ნებისმიერი პლატფორმის შეფასებამდე, სასარგებლოა გადაწყვიტოთ საბაზისო კითხვა, თუ რა შეუძლია და რა არ შეუძლია POS ტერმინალს ჯილდოს მონაცემებით — რადგან პასუხი მთლიანად მის ქვეშ არსებულ აპარატურაზეა დამოკიდებული და არა ლოიალობის პროგრამის ფუნქციების სიაზე.
ეს სტატია განმარტავს კონკრეტულ ტექნიკურ მიზეზებს, რის გამოც ლოიალობის ინტეგრირებული საფოსტო სისტემები ვერ ახერხებენ მუშაობას დაბლოკილ აპარატურაზე, რას ნიშნავს სინამდვილეში „დაბლოკილი“ ოპერაციული სისტემისა და სერტიფიცირების დონეზე და როგორ გამოიყურება შეფასების საკონტროლო სია იმ ვაჭრებისთვის, რომლებსაც სჭირდებათ მომხმარებელთა ლოიალობის საფოსტო სისტემა, რომელიც რეალურად მუშაობს წარმოებაში.
ჩაკეტილი POS აპარატურა არის ტერმინალი, სადაც მწარმოებელი ზღუდავს, თუ რომელი აპლიკაციების გაშვებაა შესაძლებელი, რომელ სისტემურ რესურსებზე შეუძლიათ წვდომა ამ აპლიკაციებს, ან ორივეს. ეს არის დიზაინის განზრახ არჩევანი და არა დეფექტი. ტრადიციული ბარათით აღჭურვილი ტერმინალები - დახლის მოწყობილობები, რომლებიც ძირითადად EMV და PIN ტრანზაქციებისთვისაა შექმნილი - სერტიფიცირებულია PCI PTS POI სტანდარტებით, რომლებიც მთელ მოწყობილობას ერთ სანდო გადახდის გარემოდ მიიჩნევენ. ამ გარემოში ლოიალობის აპლიკაციის დამატება ისტორიულად ნიშნავდა ბარათის მფლობელის მონაცემების გვერდით დაუდასტურებელი კოდის გზის დამატებას, რასაც გადახდის ბრენდები და შემძენი კომპანიები არ უშვებენ.
ჩაკეტილ ტერმინალს სამი აპარატურის მახასიათებელი განსაზღვრავს:
არცერთი ეს მახასიათებელი არ არის თავისი არსით არასწორი. ძველი მომწოდებლების მიერ შექმნილი ბარათის ატვირთვისთვის განკუთვნილი ტერმინალები სპეციალურად ამ გზით არის შექმნილი PCI DSS აუდიტის მასშტაბის მინიმიზაციისთვის. პრობლემა მხოლოდ მაშინ ჩნდება, როდესაც ვაჭარი ელის, რომ იმავე ტერმინალმა ასევე გაუშვას ლოიალობის პროგრამის მოდულის, CRM სინქრონიზაციის ან მარკეტინგული აპლიკაციის მქონე პუნქტი - შესაძლებლობები, რომელთა მხარდაჭერისთვისაც აპარატურა არასდროს ყოფილა სერტიფიცირებული ან არქიტექტურული.
ლოიალობის ინტეგრაციები დახურულ არქიტექტურებზე სამი განმეორებადი ტექნიკური მიზეზის გამო ვერ ხერხდება: sandboxing-ის წესები ზღუდავს მონაცემებზე წვდომას, საკუთრების SDK-ები ბლოკავს ინსტალაციას და firmware-ის განახლების ციკლები აფერხებს ფუნქციების დანერგვას.
PCI უსაფრთხოების სტანდარტების საბჭოს მიერ გამოქვეყნებული PCI PTS POI ვერსია 7.0 ამჟამად მესამე მხარის აპლიკაციებს, როგორიცაა აპლიკაციების მაღაზიის აპლიკაციები, საშუალებას აძლევს გაუშვან სერტიფიცირებულ POI მოწყობილობებზე. თუმცა, სტანდარტი მოითხოვს, რომ ეს აპლიკაციები იყოს... უსაფრთხოდ იზოლირებულია მგრძნობიარე გადახდის ფუნქციებისგან და ავტორიზებულია კრიპტოგრაფიული კონტროლის გამოყენებითიმავე ვერსიაში არსებული უფრო ახალი მოთხოვნა მესამე მხარის აპლიკაციებს უკრძალავს PAN ან PIN მონაცემების წაკითხვას ტექსტურიდან, მაშინაც კი, როდესაც აპლიკაცია დამტკიცებულ თეთრ სიაშია. ლოიალობის სისტემისთვის ეს პირდაპირ მნიშვნელოვანია: ნებისმიერი ინტეგრაციის ნიმუში, რომელიც ვარაუდობს, რომ ლოიალობის აპლიკაციას შეუძლია წაიკითხოს ტრანზაქციის ჯამური რაოდენობა, ბარათის ტოკენი ან მომხმარებლის იდენტიფიკატორი პირდაპირ გადახდის პროცესის შემდეგ, არ შეესაბამება v7.0-სერტიფიცირებულ მოწყობილობას. ლოიალობის აპლიკაციამ ეს მონაცემები უნდა მიიღოს დამტკიცებული, იზოლირებული არხით - და ბევრ ჩაკეტილ ტერმინალზე ასეთი არხი არ არსებობს.
ლოიალობის პლატფორმას სჭირდება მომხმარებლების რეგისტრაცია, ქულების ბალანსის მოძიება, გამოსყიდვის გამოყენება და ჯილდოების დაბეჭდვა ან ჩვენება გაყიდვის ეტაპზე. თითოეულ ამ მოქმედებას სჭირდება SDK ჰუკი. დახურული, მომწოდებლის საკუთრებაში არსებული ოპერაციული სისტემის მქონე ტერმინალები, როგორც წესი, ამ ჰუკებიდან არცერთს არ ავლენს გარე დეველოპერებისთვის - ლოიალობის მომწოდებელი ინტეგრირდება გადახდის კარიბჭის ვებჰუკის მეშვეობით მას შემდეგ, რაც ტრანზაქცია უკვე დასრულებულია, რაც ძალიან გვიანია რეალურ დროში ფასდაკლების გამოსაყენებლად ან სესიის დროს ჯილდოს გასააქტიურებლად. ეს არის ყველაზე გავრცელებული წარუმატებლობის ნიმუში, რომელსაც აფიქსირებენ ვაჭრები, რომლებიც ძველი დახლის ტერმინალებიდან POS ლოიალობის პროგრამის განლაგებაზე გადადიან: ინტეგრაცია ტექნიკურად „მუშაობს“ როგორც ტრანზაქციის შემდგომი სინქრონიზაცია, მაგრამ თავად ურთიერთქმედების ეტაპზე ვერაფერს აკეთებს.
მაშინაც კი, როდესაც ჩაკეტილი ტერმინალი ავლენს შეზღუდულ SDK-ს, ერთჯერადი გადახდის მოწყობილობებზე პროგრამული უზრუნველყოფა, როგორც წესი, განახლდება ნელი, სერტიფიცირებაზე დაფუძნებული გრაფიკით, რადგან პროგრამული უზრუნველყოფის ყველა ცვლილებამ შეიძლება გამოიწვიოს PCI-ს ხელახალი სერტიფიცირება. ლოიალობის სერვისის გამყიდველს, რომელსაც სურს ახალი გამოსყიდვის წესის, ახალი რეგისტრაციის ნაკადის ან ახალი ჯილდოს დონის გაგზავნა, უნდა დაელოდოს აპარატურის გამყიდველის გამოშვების ციკლს - და არა საკუთარს. ღია Android POS ტერმინალზე, ლოიალობის აპლიკაცია დამოუკიდებლად განახლდება საკუთარი აპლიკაციის პაკეტის მეშვეობით, ტერმინალის პროგრამული უზრუნველყოფზე საერთოდ არ არის დამოკიდებული.
ინტეგრაციის წარუმატებლობის პირდაპირი ხარჯი მისი შეფერხება ან შექცევადი დანერგვაა, თუმცა უფრო დიდი ხარჯი სტრატეგიულია: საცალო მოვაჭრეები ლოიალობის პროგრამული უზრუნველყოფის მზარდი ტემპით შეძენას აგრძელებენ, აპარატურული თავსებადობა კი მეორეხარისხოვან საკითხად რჩება. გლობალური ლოიალობის მართვის ბაზარმა 2026 წელს, სავარაუდოდ, 17.38 მილიარდ დოლარს მიაღწია და, სავარაუდოდ, 2034 წლამდე წლიური ტემპით 14%-ზე მეტით გაიზრდება. ლოიალობის პლატფორმაზე დახარჯული ყოველი დოლარი, რომელიც რეალურად ვერ მუშაობს გადახდის აპარატურაზე, ორჯერ დახარჯული ერთი დოლარია - ერთხელ პროგრამულ უზრუნველყოფაზე, მეორედ აპარატურის განახლებაზე, რომელიც ჯერ უნდა მომხდარიყო.
ასევე არსებობს შესაბამისობის საფასური. ლოიალობის პროგრამები აგროვებენ და ამუშავებენ მომხმარებლის პერსონალურ მონაცემებს — სახელებს, ტელეფონის ნომრებს, შესყიდვების ისტორიას, ზოგჯერ ბიომეტრიულ რეგისტრაციის მონაცემებს შეხებით იდენტიფიცირების პროგრამებისთვის. ევროკავშირის რეგულაციის თანახმად. 2016/679 (GDPR), რომ დამუშავება მოითხოვს დოკუმენტირებულ სამართლებრივ საფუძველს და შესაბამის თანხმობის ნაკადს რეგისტრაციისას. არაოფიციალური შემოვლითი გზით — ჯეილბრეიკ ტერმინალით, მხარდაუჭერელი გვერდულად ჩატვირთული APK ფაილით, ეკრანის ამოღების ხიდით — იძულებითი ლოიალობის ინტეგრაცია აუდიტის დროს შესაბამისობის დოკუმენტაციის წარმოებას გაცილებით ართულებს, რადგან თავად მონაცემთა გზა არასდროს ყოფილა შემუშავებული გადახედვისთვის.
არქიტექტურა, რომელიც საიმედოდ უჭერს მხარს ლოიალობას, სამ საერთო მახასიათებელს აერთიანებს: ღია SDK, აპლიკაციების მაღაზიის დონის პროგრამული უზრუნველყოფის დისტრიბუცია და აპარატურული იდენტურობის ფუნქციები, რომლებიც ბარათის უბრალოდ გადაფურცვლას სცილდება.
Android-ზე დაფუძნებული POS ტერმინალები გამოქვეყნებული SDK-ით საშუალებას აძლევს ლოიალობის მომწოდებელს პირდაპირ ააწყოს პრინტერის, სკანერის, მომხმარებელზე ორიენტირებული ეკრანისა და გადახდის ბირთვის დოკუმენტირებული API-ების საფუძველზე — აპარატურის მწარმოებლისგან თითოეული ახალი ფუნქციის მოლოდინის გარეშე. ეს არის იგივე ღია პლატფორმის მოდელი, რომელიც Square-ის Terminal API-მ საკუთარი აპარატურისთვის შემოიღო და ახლა ეს სტანდარტული პრაქტიკაა Android POS მწარმოებლების უმეტესობაში, რომლებიც ყიდიან მრავალმომწოდებლიან საცალო გარემოში და არა დახურულ, ერთაპლიკაციურ კიოსკებში. ვაჭრები აპარატურას პირდაპირ მომწოდებლების ბაზიდან იღებენ — მათ შორის ჩინური POS ტერმინალების მწარმოებლების B2B ლანდშაფტი — SDK-ის ღიაობა უნდა განიხილებოდეს, როგორც შესყიდვების ფილტრი და არა როგორც დამატებითი აზრი, რომელიც მხოლოდ კონტრაქტის ხელმოწერის შემდეგ განიხილება.
Google Mobile Services (GMS) სერტიფიცირება ტერმინალს საშუალებას აძლევს, გაუშვას სტანდარტული Android აპლიკაციების პაკეტები Play Store-ის ან ექვივალენტური მართული აპლიკაციების მაღაზიის მეშვეობით, მოწყობილობის მხოლოდ firmware-თან დაკავშირებული პროგრამული უზრუნველყოფის შეზღუდვის ნაცვლად. GMS-სერტიფიცირებულ ტერმინალს შეუძლია ლოიალობის აპლიკაციის ინსტალაცია ისევე, როგორც ტელეფონი აყენებს ნებისმიერ სხვა აპლიკაციას: დამოუკიდებლად, მომწოდებლის საკუთარი გამოშვების გრაფიკით, firmware-ის დონის ხელახალი სერტიფიცირების ციკლის გარეშე.
ტერმინალების უფრო მცირე, მაგრამ მზარდი ნაკრები ლოიალობის იდენტიფიკაციას ბარათებითა და ტელეფონის ნომრებით ბიომეტრიულ რეგისტრაციაშიც აფართოებს. ხელისგულის ვენების ამოცნობა ერთ-ერთი მაგალითია, რომელიც უკვე კომერციულ დანერგვაშია — ZCS ამჟამად Android POS მწარმოებელთა შორისაა, რომლებიც ყიდიან ტერმინალებს, რომლებიც აღჭურვილია ღია SDK-ით, რაც ლოიალობის პლატფორმას საშუალებას აძლევს, მომხმარებლის ლოიალობის ვენის ნიმუში დაარეგისტრიროს ალტერნატიულ იდენტიფიკატორად გადახდისას, ბარათის, აპლიკაციის ან ტელეფონის ნომრის მოძიების მოთხოვნის ნაცვლად. ამ ტიპის აპარატურული დონის იდენტიფიკაციის ფუნქცია ლოიალობის პლატფორმის მიერ მხოლოდ მაშინ არის გამოსაყენებელი, როდესაც ტერმინალის SDK მას დოკუმენტირებული API-ს სახით აჩვენებს — რაც ზუსტად ზემოთ აღწერილი ღია არქიტექტურის მოთხოვნაა და არა რომელიმე ბრენდისთვის დამახასიათებელი ფუნქცია.
ლოიალობის პროგრამული უზრუნველყოფის ხელშეკრულების ხელმოწერამდე, ტერმინალის მხარეს დაადასტურეთ შემდეგი:
ტერმინალის შერჩევის კრიტერიუმები — ოპერაციული სისტემის ღიაობა, სერტიფიცირების ფარგლები, SDK-ის სიღრმე — უფრო დეტალურად არის განხილული ჩვენი სრული ჩარჩო Android POS პლატფორმის არჩევისთვის, რომელიც მხოლოდ ლოიალობის გამოყენების შემთხვევების მიღმა იმავე შეფასების ლოგიკას გადის.
კითხვა 1: შეუძლია თუ არა ნებისმიერ POS ტერმინალს ლოიალობის პროგრამის გაშვება?
არა. ტერმინალს სჭირდება ღია SDK, აპლიკაციების მაღაზიის დონის პროგრამული უზრუნველყოფის დისტრიბუცია და PCI PTS-თან თავსებადი sandboxing მესამე მხარის აპლიკაციებისთვის. დახურული, ერთი აპლიკაციის ტერმინალები მთლიანად ზღუდავს ან ბლოკავს ლოიალობის პროგრამულ უზრუნველყოფას, მიუხედავად იმისა, თუ რას უჭერს მხარს ლოიალობის მომწოდებლის პლატფორმა ქაღალდზე.
კითხვა 2: რა ხდის POS ტერმინალს „ჩაკეტილს“?
ჩაკეტილი ტერმინალი ზღუდავს ინსტალაციად აპლიკაციებს, არ ავლენს საჯარო SDK-ს და იყენებს ერთიანი გადახდის აპლიკაციის გარშემო აგებულ firmware-ს. ეს მახასიათებლები ამცირებს PCI აუდიტის მასშტაბებს, მაგრამ ასევე ბლოკავს ლოიალობის აპლიკაციებს, CRM სინქრონიზაციას და სხვა მესამე მხარის ინტეგრაციებს.
კითხვა 3: PCI-თან თავსებადობა ხელს უშლის თუ არა ლოიალობის აპლიკაციების გაშვებას POS აპარატურაზე?
ნაგულისხმევად არა. PCI PTS POI v7.0 უშვებს მესამე მხარის აპლიკაციებს, მათ შორის ლოიალობის აპლიკაციებს, იმ პირობით, რომ ისინი დაცულია ტექსტური გადახდის ბარათისა და PIN კოდის მონაცემებისგან. შესაბამისობა მოითხოვს იზოლაციას და არა გამორიცხვას, და ტერმინალის არქიტექტურა განსაზღვრავს, ტექნიკურად შესაძლებელია თუ არა ეს იზოლაცია.
კითხვა 4: რა განსხვავებაა ტრანზაქციის შემდგომ ლოიალობის სინქრონიზაციასა და რეალურ დროში ინტეგრაციას შორის?
ტრანზაქციის შემდგომი სინქრონიზაცია ჯილდოებს გაყიდვის დასრულების შემდეგ გადახდის კარიბჭის ვებჰუკის მეშვეობით აწესებს. რეალურ დროში ინტეგრაცია ჯილდოებს შეკვეთის გაფორმებისას SDK ჰუკის მეშვეობით აწესებს. ჩაკეტილი ტერმინალები, როგორც წესი, მხოლოდ პირველს უჭერს მხარს, რაც ხელს უშლის სესიის დროს ფასდაკლებებსა და გამოსყიდვას.
კითხვა 5: შეიძლება თუ არა ბიომეტრიული იდენტიფიკაცია, როგორიცაა ხელისგულის ვენა, გამოყენებულ იქნას ლოიალობის პროგრამის რეგისტრაციისთვის?
დიახ, ტერმინალებზე, სადაც მწარმოებელი ბიომეტრიულ მონაცემებს დოკუმენტირებული SDK-ის მეშვეობით აქვეყნებს. ხელის ვენა და მსგავსი ბიომეტრიული იდენტიფიკატორები ლოიალობის პლატფორმას საშუალებას აძლევს ამოიცნოს დაბრუნებული მომხმარებელი ბარათის, ტელეფონის ნომრის ან აპლიკაციის ძიების გარეშე, იმ პირობით, რომ აპარატურის არქიტექტურა მხარს უჭერს მესამე მხარის წვდომას ამ მონაცემებზე.
მთავარი 
როგორ მუშაობს ხელისგულის ვენების ამოცნობა წევრობისა და ლოიალობის პროგრამებისთვის? 
