2026-08-10 Аўтар: ZCS
Праграма лаяльнасці на POS-тэрмінале не працуе па адной прычыне, а не па любой іншай: абсталяванне ніколі не было распрацавана для ўключэння знешняга праграмнага забеспячэння. Рознічныя гандляры купляюць платформу лаяльнасці, падпісваюць кантракт, складаюць бюджэт на разгортванне, а потым выяўляюць, што аперацыйная сістэма тэрмінала, SDK або сертыфікацыя плацяжоў цалкам блакуюць інтэграцыю. Гэта не праблема праграмнага забеспячэння. Гэта праблема архітэктуры абсталявання, і яна праяўляецца амаль кожны раз, калі прадавец спрабуе ўсталяваць POS-сістэму з функцыянальнасцю праграмы лаяльнасці на тэрмінал, які быў распрацаваны як закрытая плацежная прылада, а не як адкрытая вылічальная прылада.
Перад ацэнкай любой платформы карысна высветліць базавае пытанне аб тым, што можа і не можа рабіць POS-тэрмінал з дадзенымі аб узнагародах — таму што адказ цалкам залежыць ад апаратнага забеспячэння, якое ляжыць у аснове яго, а не ад спісу функцый праграмнага забеспячэння лаяльнасці.
У гэтым артыкуле разглядаюцца канкрэтныя тэхнічныя прычыны, па якіх інтэграваныя з праграмамі лаяльнасці POS-сістэмы не працуюць на заблакаваным абсталяванні, што насамрэч азначае «заблакіраваны» на ўзроўні аперацыйнай сістэмы і сертыфікацыі, а таксама як выглядае кантрольны спіс ацэнкі для прадаўцоў, якім патрэбна сістэма POS для лаяльнасці кліентаў, якая сапраўды працуе ў прадукцыйных умовах.
Блакіраванае POS-абсталяванне — гэта тэрмінал, дзе вытворца абмяжоўвае, якія праграмы могуць запускацца, да якіх сістэмных рэсурсаў гэтыя праграмы могуць атрымліваць доступ, або і тое, і другое. Гэта свядомы дызайнерскі выбар, а не дэфект. Традыцыйныя тэрміналы з прад'яўленнем карты — настольныя прылады, прызначаныя ў першую чаргу для аперацый EMV і PIN-кодаў — сертыфікаваны па стандартах PCI PTS POI, якія разглядаюць усю прыладу як адзінае надзейнае плацежнае асяроддзе. Даданне праграмы лаяльнасці ў гэтае асяроддзе гістарычна азначала даданне неправеранага шляху кода побач з дадзенымі ўладальніка карты, што не дазваляюць плацежныя брэнды і эквайеры.
Тры характарыстыкі абсталявання вызначаюць заблакаваны тэрмінал:
Ніводная з гэтых рыс не з'яўляецца па сваёй сутнасці памылковай. Спецыялізаваныя тэрміналы з прадстаўленнем карты ад старых пастаўшчыкоў распрацаваны такім чынам, каб мінімізаваць аб'ём аўдыту PCI DSS. Праблема ўзнікае толькі тады, калі прадавец чакае, што той жа тэрмінал будзе таксама запускаць POS з модулем праграмы лаяльнасці, сінхранізацыяй CRM або маркетынгавым дадаткам — магчымасцямі, для падтрымкі якіх абсталяванне ніколі не было сертыфікавана або распрацавана.
Інтэграцыя праграм лаяльнасці не працуе на закрытых архітэктурах па трох паўтаральных тэхнічных прычынах: правілы пясочніцы абмяжоўваюць доступ да дадзеных, запатэнтаваныя SDK блакуюць усталёўку, а цыклы абнаўлення прашыўкі тармазяць разгортванне функцый.
Стандарт PCI PTS POI версіі 7.0, апублікаваны Саветам па стандартах бяспекі PCI, цяпер дазваляе запускаць праграмы іншых вытворцаў, такія як праграмы з крам праграм, на сертыфікаваных прыладах POI. Але стандарт патрабуе, каб гэтыя праграмы былі надзейна ізаляваны ад канфідэнцыйных плацежных функцый і аўтэнтыфікаваны з дапамогай крыптаграфічных элементаў кіраванняНовае патрабаванне ў той жа версіі блакуе староннія праграмы ад чытання дадзеных PAN або PIN у адкрытым выглядзе, нават калі праграма знаходзіцца ў зацверджаным белым спісе. Для сістэмы лаяльнасці гэта мае непасрэднае значэнне: любая схема інтэграцыі, якая мяркуе, што праграма лаяльнасці можа прачытаць агульную суму транзакцыі, токен карты або ідэнтыфікатар кліента непасрэдна з працэсу аплаты, не адпавядае патрабаванням на прыладзе, сертыфікаванай v7.0. Праграма лаяльнасці павінна атрымліваць гэтыя дадзеныя праз зацверджаны, ізаляваны канал, а на многіх заблакаваных тэрміналах такога канала не існуе.
Платформа лаяльнасці павінна рэгістраваць кліентаў, праглядаць баланс балаў, прымяняць актывацыі і друкаваць або адлюстроўваць узнагароды ў пункце продажу. Для кожнага з гэтых дзеянняў патрабуецца перахопнік SDK. Тэрміналы з закрытай аперацыйнай сістэмай, якая належыць пастаўшчыку, звычайна не падвяргаюць ніводнаму з гэтых перахопнікаў знешнім распрацоўшчыкам — пастаўшчык лаяльнасці застаецца інтэгравацца праз вэб-хук плацежнага шлюза пасля таго, як транзакцыя ўжо завершана, што ўжо занадта позна, каб ужыць зніжку ў рэжыме рэальнага часу або актываваць узнагароду ў сесіі. Гэта найбольш распаўсюджаная схема збояў, пра якую паведамляюць прадаўцы, якія пераходзяць са старых настольных тэрміналаў на разгортванне праграм лаяльнасці POS: інтэграцыя тэхнічна «працуе» як сінхранізацыя пасля транзакцыі, але нічога не можа зрабіць у самым пункце ўзаемадзеяння.
Нават калі заблакаваны тэрмінал мае абмежаваны SDK, прашыўка на аднамэтавых плацежных прыладах звычайна абнаўляецца павольна, у залежнасці ад сертыфікацыі, паколькі кожнае змяненне прашыўкі можа выклікаць паўторную сертыфікацыю PCI. Пастаўшчык лаяльнасці, які хоча выпусціць новае правіла выкарыстання, новы працэс рэгістрацыі або новы ўзровень узнагарод, павінен чакаць цыклу выпуску пастаўшчыка абсталявання, а не свайго ўласнага. На адкрытым POS-тэрмінале Android праграма лаяльнасці абнаўляецца незалежна праз свой уласны пакет праграм, без якой-небудзь залежнасці ад прашыўкі тэрмінала.
Прамымі выдаткамі няўдалай інтэграцыі з'яўляюцца спыненае або адмененае ўкараненне, але большыя выдаткі маюць стратэгічны характар: рознічныя гандляры працягваюць купляць праграмнае забеспячэнне для лаяльнасці з усё большай хуткасцю, у той час як сумяшчальнасць абсталявання застаецца ў другім плане. Сусветны рынак кіравання лаяльнасцю дасягнуў ацэнак у 17.38 мільярда долараў у 2026 годзе і, паводле прагнозаў, будзе расці са сукупным гадавым тэмпам больш за 14% да 2034 года. Кожны долар, выдаткаваны на платформу лаяльнасці, якая фактычна не можа працаваць на абсталяванні для афармлення заказаў, — гэта долар, выдаткаваны двойчы — адзін раз на праграмнае забеспячэнне, другі раз на абнаўленне абсталявання, якое павінна было адбыцца раней.
Існуюць таксама выдаткі на захаванне патрабаванняў. Праграмы лаяльнасці збіраюць і апрацоўваюць асабістыя дадзеныя кліентаў — імёны, нумары тэлефонаў, гісторыю пакупак, часам біяметрычныя дадзеныя рэгістрацыі для праграм ідэнтыфікацыі па дакрананні. Згодна з рэгламентам ЕС 2016/679 (GDPR), што апрацоўка патрабуе дакументальна пацверджанай прававой падставы і адпаведнага працэсу атрымання згоды пры рэгістрацыі. Інтэграцыя лаяльнасці, якая была вымушана рэалізавана праз неафіцыйны абходны шлях — узламаны тэрмінал, непадтрымоўваны загружаны APK, мост для скрапінгу экрана — значна ўскладняе атрыманне дакументацыі аб адпаведнасці падчас аўдыту, бо сам шлях даных ніколі не быў распрацаваны для праверкі.
Архітэктура, якая надзейна падтрымлівае лаяльнасць, мае тры агульныя рысы: адкрыты SDK, распаўсюджванне праграмнага забеспячэння на ўзроўні крамы прыкладанняў і функцыі ідэнтыфікацыі абсталявання, якія выходзяць за рамкі правядзення карты.
POS-тэрміналы на базе Android з апублікаваным SDK дазваляюць пастаўшчыкам лаяльнасці ствараць непасрэдна на аснове дакументаваных API для прынтара, сканера, дысплея, арыентаванага на кліента, і плацежнага ядра, не чакаючы ад вытворцы абсталявання кожнай новай функцыі. Гэта тая ж мадэль адкрытай платформы, якую API тэрміналаў Square увёў для ўласнага абсталявання, і цяпер гэта стандартная практыка для большасці вытворцаў Android POS, якія прадаюць у рознічныя асяроддзі з некалькімі пастаўшчыкамі, а не ў закрытыя кіёскі з адным дадаткам. Прадаўцы закупляюць абсталяванне непасрэдна ў базы пастаўшчыкоў, у тым ліку B2B-ландшафт кітайскіх вытворцаў POS-тэрміналаў — варта разглядаць адкрытасць SDK як фільтр закупак, а не як дадатковае пытанне, якое абмяркоўваецца толькі пасля падпісання кантракту.
Сертыфікацыя Google Mobile Services (GMS) дазваляе тэрміналу запускаць стандартныя пакеты праграм Android праз Play Store або эквівалентную кіраваную краму праграм, замест таго, каб абмяжоўваць прыладу праграмным забеспячэннем, якое пастаўляецца ў камплекце з прашыўкай. Тэрмінал, сертыфікаваны GMS, можа ўсталёўваць праграму лаяльнасці гэтак жа, як тэлефон усталёўвае любую іншую праграму: незалежна, у адпаведнасці з уласным графікам выпуску пастаўшчыка, без цыклу паўторнай сертыфікацыі ўзроўню прашыўкі.
Меншы, але ўсё большы набор тэрміналаў пашырае ідэнтыфікацыю лаяльнасці, за выключэннем картак і нумароў тэлефонаў, і ўключае біяметрычную рэгістрацыю. Распазнаванне вен далоні — адзін з прыкладаў, які ўжо выкарыстоўваецца ў камерцыйных мэтах. ZCS з'яўляецца адным з вытворцаў Android POS, якія ў цяперашні час пастаўляюць тэрміналы з падтрымкай вен на далоні з адкрытым SDK, што дазваляе платформе лаяльнасці рэгістраваць малюнак вен на далоні кліента ў якасці альтэрнатыўнага ідэнтыфікатара пры афармленні замовы, замест таго, каб патрабаваць пошуку па картцы, дадатку або нумары тэлефона. Такая функцыя ідэнтыфікацыі на апаратным узроўні можа выкарыстоўвацца платформай лаяльнасці толькі тады, калі SDK тэрмінала прадстаўляе яе як дакументаваны API — што менавіта з'яўляецца патрабаваннем адкрытай архітэктуры, апісаным вышэй, а не функцыяй, унікальнай для якога-небудзь аднаго брэнда.
Перад падпісаннем кантракту на праграмнае забеспячэнне лаяльнасці пацвердзіце наступнае на баку тэрмінала:
Крытэрыі выбару тэрмінала — адкрытасць АС, аб'ём сертыфікацыі, глыбіня SDK — больш падрабязна разглядаюцца ў наша поўная структура для выбару платформы Android POS, які ахоплівае тую ж логіку ацэнкі, што і выходзіць за рамкі выпадкаў выкарыстання лаяльнасці.
Пытанне 1: Ці можа любы POS-тэрмінал запускаць праграму лаяльнасці?
Не. Тэрмінал патрабуе адкрытага SDK, дыстрыбуцыі праграмнага забеспячэння на ўзроўні крамы прыкладанняў і пясочніцы, якая адпавядае стандарту PCI PTS, для праграм іншых вытворцаў. Закрытыя тэрміналы з адным дадаткам абмяжоўваюць або цалкам блакуюць праграмнае забеспячэнне лаяльнасці, незалежна ад таго, што платформа пастаўшчыка праграм лаяльнасці падтрымлівае на паперы.
Пытанне 2: Што робіць POS-тэрмінал "заблакаваным"?
Заблакаваны тэрмінал абмяжоўвае колькасць усталёўваемых праграм, не дае доступу да публічнага SDK і запускае прашыўку, пабудаваную на адным плацежным дадатку. Гэтыя асаблівасці абмяжоўваюць аб'ём аўдыту PCI, але таксама блакуюць праграмы лаяльнасці, сінхранізацыю CRM і іншыя інтэграцыі трэціх бакоў.
Пытанне 3: Ці перашкаджае адпаведнасць стандарту PCI працаваць праграмам лаяльнасці на абсталяванні POS?
Не па змаўчанні. PCI PTS POI v7.0 дазваляе выкарыстанне старонніх праграм, у тым ліку праграм лаяльнасці, пры ўмове, што яны знаходзяцца ў пясочніцы і не маюць доступу да дадзеных плацежных карт і PIN-кодаў у адкрытым выглядзе. Адпаведнасць патрабуе ізаляцыі, а не выключэння, і архітэктура тэрмінала вызначае, ці з'яўляецца такая ізаляцыя тэхнічна магчымай.
Пытанне 4: У чым розніца паміж сінхранізацыяй лаяльнасці пасля транзакцыі і інтэграцыяй у рэжыме рэальнага часу?
Паслятранзакцыйная сінхранізацыя ўжывае ўзнагароды пасля завяршэння продажу праз вэбхук плацежнага шлюза. Інтэграцыя ў рэжыме рэальнага часу ўжывае ўзнагароды падчас афармлення замовы праз хук SDK. Заблакаваныя тэрміналы звычайна падтрымліваюць толькі першы спосаб, што прадухіляе зніжкі і пагашэнне бонусаў падчас сесіі.
Пытанне 5: Ці можна выкарыстоўваць біяметрычную ідэнтыфікацыю, такую як вены далоні, для рэгістрацыі ў праграме лаяльнасці?
Так, на тэрміналах, дзе вытворца прадастаўляе біяметрычны збор дадзеных праз дакументаваны SDK. Вены далоні і падобныя біяметрычныя ідэнтыфікатары дазваляюць платформе лаяльнасці распазнаваць пастаяннага кліента без карты, нумара тэлефона або пошуку ў дадатку, пры ўмове, што апаратная архітэктура падтрымлівае доступ трэціх асоб да гэтых дадзеных.
Галоўная 
Як працуе распазнаванне вен на далоні для праграм сяброўства і лаяльнасці? 
