Kodėl lojalumo programos programinė įranga neveikia užrakintoje POS aparatinėje įrangoje?

Lojalumo programa POS terminale neveikia dėl vienos priežasties labiau nei bet kuri kita: aparatinė įranga niekada nebuvo sukurta taip, kad praleistų išorinę programinę įrangą. Mažmenininkai nusiperka lojalumo platformą, pasirašo sutartį, sudaro biudžetą diegimui – tada atranda, kad terminalo operacinė sistema, SDK ar mokėjimo sertifikatas visiškai blokuoja integraciją. Tai ne programinės įrangos problema. Tai aparatinės įrangos architektūros problema, kuri iškyla beveik kiekvieną kartą, kai prekybininkas bando įdiegti POS sistemą su lojalumo programos funkcijomis į terminalą, kuris buvo sukurtas kaip uždaras mokėjimo įrenginys, o ne atviras skaičiavimo įrenginys.
Prieš vertinant bet kokią platformą, pravartu išsiaiškinti pagrindinis klausimas, ką POS terminalas gali ir ko negali daryti su lojalumo duomenimis – nes atsakymas visiškai priklauso nuo po ja esančios aparatinės įrangos, o ne nuo lojalumo programinės įrangos funkcijų sąrašo.
Šiame straipsnyje aptariamos konkrečios techninės priežastys, kodėl lojalumo programoje integruotos POS sistemos neveikia naudojant užrakintą aparatinę įrangą, ką „užrakinimas“ iš tikrųjų reiškia OS ir sertifikavimo lygmeniu ir kaip atrodo vertinimo kontrolinis sąrašas prekybininkams, kuriems reikia klientų lojalumo POS sistemos, kuri iš tikrųjų veiktų gamyboje.

1. Ką iš tikrųjų reiškia „užrakinta POS įranga“

Užrakinta POS įranga yra terminalas, kuriame gamintojas riboja, kurios programos gali veikti, kuriuos sistemos išteklius tos programos gali pasiekti, arba abu šiuos apribojimus. Tai sąmoningas konstrukcijos pasirinkimas, o ne defektas. Tradiciniai kortelės pateikimo terminalai – stalviršio įrenginiai, sukurti pirmiausia EMV ir PIN operacijoms atlikti – yra sertifikuoti pagal PCI PTS POI standartus, kurie visą įrenginį traktuoja kaip vieną patikimą mokėjimo aplinką. Lojalumo programėlės pridėjimas prie šios aplinkos istoriškai reiškė nepatvirtinto kodo kelio pridėjimą šalia kortelės turėtojo duomenų, ko mokėjimo prekių ženklai ir aptarnaujančios įmonės neleidžia.
Trys aparatinės įrangos savybės apibrėžia užrakintą terminalą:

• ● Uždara arba griežtai apribota operacinė sistema be programėlių parduotuvės ir be šalutinio įkėlimo kelio.
• ● Nėra publikuoto SDK arba SDK, apsiribojantis kvitų formatavimu ir pagrindiniais periferinių įrenginių iškvietimais.
• ● Vienos programos programinės įrangos modelis, kai įrenginyje veikia tik mokėjimo programėlė.

Nė viena iš šių savybių nėra savaime bloga. Specialūs senesnių tiekėjų kortelės pateikimo terminalai yra sukurti specialiai taip, kad sumažintų PCI DSS audito apimtį. Problema iškyla tik tada, kai prekybininkas tikisi, kad tas pats terminalas taip pat veiks su lojalumo programos moduliu, CRM sinchronizavimu arba rinkodaros programėle – funkcijomis, kurioms ši aparatinė įranga niekada nebuvo sertifikuota ar sukurta palaikyti.

2. Kodėl lojalumo programinė įranga neveikia uždarose POS architektūrose

Lojalumo programų integracijos uždarose architektūrose neveikia dėl trijų pasikartojančių techninių priežasčių: smėlio dėžės taisyklės riboja prieigą prie duomenų, patentuoti SDK blokuoja diegimą, o programinės įrangos atnaujinimo ciklai stabdo funkcijų diegimą.

2.1 PCI PTS „smėlio dėžės“ taisyklės riboja trečiųjų šalių prieigą prie duomenų

PCI PTS POI 7.0 versija, kurią išleido PCI saugumo standartų taryba, dabar leidžia trečiųjų šalių programoms, pvz., programėlių parduotuvių programoms, veikti sertifikuotuose POI įrenginiuose. Tačiau standartas reikalauja, kad tos programos būtų... saugiai izoliuota nuo jautrių mokėjimo funkcijų ir autentifikuota naudojant kriptografines kontrolės priemonesNaujesnis reikalavimas toje pačioje versijoje blokuoja trečiųjų šalių programas nuo aiškaus teksto PAN arba PIN duomenų nuskaitymo, net jei programa yra patvirtintame baltajame sąraše. Lojalumo varikliui tai yra tiesiogiai svarbu: bet koks integravimo modelis, kuris daro prielaidą, kad lojalumo programa gali nuskaityti bendrą operacijos sumą, kortelės žetoną arba kliento identifikatorių tiesiai iš mokėjimo proceso, neatitinka v7.0 sertifikuoto įrenginio reikalavimų. Lojalumo programa turi gauti šiuos duomenis per patvirtintą, izoliuotą kanalą, o daugelyje užrakintų terminalų tokio kanalo nėra.

2.2 Nuosavybės teise paremti SDK blokuoja vietinių lojalumo programėlių diegimą

Lojalumo platforma turi užregistruoti klientus, peržiūrėti taškų likučius, pritaikyti išpirkimus ir atspausdinti arba rodyti atlygius pardavimo vietoje. Kiekvienam iš šių veiksmų reikalingas SDK priedas. Terminalai su uždara, tiekėjo patentuota OS paprastai neatskleidžia nė vieno iš šių priedų išoriniams kūrėjams – lojalumo tiekėjas lieka integruotis per mokėjimo šliuzo žiniatinklio priedą, kai sandoris jau uždarytas, o tai jau per vėlu, kad būtų galima pritaikyti nuolaidą realiuoju laiku arba suaktyvinti atlygį sesijos metu. Tai yra dažniausiai pasitaikantis gedimų modelis, apie kurį praneša prekybininkai, pereinantys nuo senesnių stalinių terminalų prie lojalumo programų diegimo pardavimo vietose: integracija techniškai „veikia“ kaip sinchronizavimas po sandorio, bet negali nieko daryti pačios sąveikos metu.

2.3 Programinės įrangos atnaujinimo ciklai nutraukia lojalumo funkcijų diegimą

Net jei užrakintame terminale yra ribotas SDK, vienkartinių mokėjimo įrenginių programinė įranga paprastai atnaujinama lėtai, pagal sertifikavimo grafiką, nes kiekvienas programinės įrangos pakeitimas gali sukelti PCI pakartotinį sertifikavimą. Lojalumo programos tiekėjas, norintis pristatyti naują panaudojimo taisyklę, naują registracijos srautą ar naują atlygio lygį, turi laukti aparatinės įrangos tiekėjo išleidimo ciklo, o ne savo. Atvirame „Android“ POS terminale lojalumo programa atnaujinama savarankiškai, naudojant savo programėlės paketą, visiškai nepriklausydama nuo terminalo programinės įrangos.

3. Tikroji nepavykusios lojalumo programos integracijos kaina

Tiesioginė nesėkmingos integracijos kaina yra sustabdytas arba atšauktas diegimas, tačiau didesnė kaina yra strateginė: mažmenininkai vis labiau perka lojalumo programinę įrangą, o aparatinės įrangos suderinamumas lieka antraeilis klausimas. Pasaulinė lojalumo valdymo rinka 2026 m. pasiekė maždaug 17.38 mlrd. JAV dolerių ir prognozuojama, kad iki 2034 m. ji augs daugiau nei 14 % metiniu sudėtiniu tempu. Kiekvienas doleris, išleistas lojalumo platformai, kuri iš tikrųjų negali veikti kasos aparatinėje įrangoje, yra doleris, išleistas du kartus – pirmą kartą programinei įrangai, o antrą kartą aparatinės įrangos atnaujinimui, kuris turėjo būti atliktas pirmiausia.
Taip pat yra atitikties išlaidos. Lojalumo programos renka ir tvarko asmeninius klientų duomenis – vardus, telefono numerius, pirkimų istoriją, kartais biometrinius registracijos duomenis, skirtus identifikavimo bakstelėjimu programoms. Pagal ES reglamentą 2016/679 (BDAR), kad apdorojimas reikalauja dokumentuoto teisinio pagrindo ir reikalavimus atitinkančio sutikimo srauto registracijos metu. Lojalumo integracija, priverstinai atliekama neoficialiu būdu – naudojant atrakinimo kodą turintį terminalą, nepalaikomą iš šono įkeltą APK, ekrano duomenų išgavimo tiltą – gerokai apsunkina atitikties dokumentų pateikimą audito metu, nes pats duomenų kelias niekada nebuvo skirtas peržiūrai.

4. Kaip atrodo atvira, lojalumui pritaikyta POS architektūra

Architektūra, kuri patikimai palaiko lojalumą, turi tris bruožus: atvirą SDK, programėlių parduotuvės lygio programinės įrangos platinimą ir aparatinės įrangos tapatybės funkcijas, kurios neapsiriboja kortele.

4.1 Atvira SDK ir API prieiga

„Android“ pagrindu sukurti POS terminalai su publikuotu SDK leidžia lojalumo programų tiekėjams kurti tiesiogiai pagal dokumentuotas spausdintuvo, skaitytuvo, klientui skirto ekrano ir mokėjimo branduolio API sąsajas – nelaukiant aparatinės įrangos gamintojo dėl kiekvienos naujos funkcijos. Tai tas pats atvirosios platformos modelis, kurį „Square“ terminalo API pristatė savo aparatinei įrangai, ir dabar tai yra standartinė praktika daugumai „Android“ POS gamintojų, kurie parduoda mažmeninės prekybos aplinkoms su keliais tiekėjais, o ne uždaroms vienos programėlės kioskams. Prekybininkai, perkantys aparatinę įrangą tiesiogiai iš tiekėjų bazės, įskaitant... Kinijos POS terminalų gamintojų B2B aplinka — SDK atvirumą reikėtų traktuoti kaip viešųjų pirkimų filtrą, o ne kaip papildomas dalykas, aptariamas tik po sutarties pasirašymo.

4.2 GMS sertifikavimas ir suderinamumas su programėlių parduotuve

„Google Mobile Services“ (GMS) sertifikatas leidžia terminalui paleisti standartinius „Android“ programų paketus per „Play Store“ arba atitinkamą valdomą programų parduotuvę, užuot apribojus įrenginį iki programinės įrangos paketo. GMS sertifikuotas terminalas gali įdiegti lojalumo programėlę taip pat, kaip telefonas įdiegia bet kurią kitą programėlę: savarankiškai, pagal paties tiekėjo išleidimo grafiką, be programinės įrangos lygio pakartotinio sertifikavimo ciklo.

4.3 Biometrinės lojalumo programos registracija

Mažesnis, bet augantis terminalų rinkinys leidžia lojalumo programose atpažinti ne tik korteles ir telefono numerius, bet ir biometrinius duomenis. Delno venų atpažinimas yra vienas iš pavyzdžių, jau diegiamų komerciniais tikslais. ZCS yra vienas iš „Android“ POS įrenginių gamintojų, šiuo metu tiekiančių delno venų atpažinimo terminalus su atviru SDK, leidžiančiu lojalumo platformai užregistruoti kliento delno venų modelį kaip alternatyvų identifikatorių atsiskaitant, o ne reikalauti kortelės, programėlės ar telefono numerio paieškos. Tokią aparatinės įrangos lygio tapatybės nustatymo funkciją lojalumo platforma gali naudoti tik tada, kai terminalo SDK ją pateikia kaip dokumentuotą API – tai yra būtent aukščiau aprašytas atvirosios architektūros reikalavimas, o ne tik vienam prekės ženklui būdinga funkcija.

5. Įvertinimo kontrolinis sąrašas: ar jūsų POS terminalas pasiruošęs lojalumo programai?

Prieš pasirašydami lojalumo programinės įrangos sutartį, terminale patikrinkite šiuos dalykus:

• ● Terminalas pateikiamas su publikuotu, dokumentuotu SDK, o ne tik mokėjimo šliuzo žiniatinklio kabliu.
• ● Terminalas yra sertifikuotas pagal GMS ir palaiko nepriklausomą programų diegimą bei atnaujinimus.
• ● Gamintojas gali patvirtinti bet kurios trečiosios šalies programos „smėlio dėžės“ aplinkos atitiktį PCI PTS POI reikalavimams, atitinkantiems dabartinės PTS POI versijos izoliacijos reikalavimus.
• ● Lojalumo programos tiekėjas gali nurodyti realaus pardavėjo nuorodą, kurioje rodomas tikslus terminalo modelis, o ne tik terminalo prekės ženklas.
• ● Aparatinės įrangos tiekėjo programinės įrangos išleidimo dažnumas yra dokumentuotas ir neblokuoja nepriklausomų programėlių lygio atnaujinimų iš lojalumo programos tiekėjo.

Terminalo pasirinkimo kriterijai – OS atvirumas, sertifikavimo apimtis, SDK išsamumas – išsamiau aptariami visa mūsų sistema, skirta „Android“ POS platformos pasirinkimui, kuris apžvelgia tą pačią vertinimo logiką, neapsiribojant vien lojalumo naudojimo atvejais.

6. Dažnai užduodami klausimai

1 klausimas: Ar bet kuris POS terminalas gali vykdyti lojalumo programą?

Ne. Terminalui reikalingas atviras SDK, programėlių parduotuvės lygio programinės įrangos platinimas ir PCI PTS reikalavimus atitinkanti „sandboxing“ trečiųjų šalių programoms. Uždari, vienos programos terminalai visiškai riboja arba blokuoja lojalumo programinę įrangą, neatsižvelgiant į tai, ką lojalumo tiekėjo platforma palaiko popieriuje.
2 klausimas: Kas lemia POS terminalo „užrakinimą“?

Užrakintas terminalas riboja įdiegiamų programų skaičių, neatskleidžia jokio viešo SDK ir paleidžia programinę-aparatinę įrangą, sukurtą vienai mokėjimo programai. Šie bruožai sumažina PCI audito apimtį, bet taip pat pagal numatytuosius nustatymus blokuoja lojalumo programas, CRM sinchronizavimą ir kitas trečiųjų šalių integracijas.
3 klausimas: Ar PCI atitiktis neleidžia lojalumo programėlėms veikti POS įrangoje?

Ne pagal nutylėjimą. PCI PTS POI v7.0 leidžia trečiųjų šalių programas, įskaitant lojalumo programas, su sąlyga, kad jos yra izoliuotos nuo aiškiateksčių mokėjimo kortelių ir PIN duomenų. Atitiktis reikalauja izoliacijos, o ne išskyrimo, o terminalo architektūra lemia, ar toks izoliavimas yra techniškai įmanomas.
4 klausimas: Kuo skiriasi lojalumo sinchronizavimas po operacijos ir integravimas realiuoju laiku?

Sinchronizavimas po operacijos suteikia apdovanojimus užbaigus pardavimą per mokėjimo šliuzo žiniatinklio kablį. Integracija realiuoju laiku suteikia apdovanojimus atsiskaitymo metu per SDK kablį. Užrakinti terminalai paprastai palaiko tik pirmąjį variantą, todėl negalima taikyti nuolaidų ir išpirkimų sesijos metu.
5 klausimas: Ar biometrinis identifikavimas, pvz., delno venų atpažinimas, gali būti naudojamas lojalumo programoje?

Taip, terminaluose, kuriuose gamintojas biometrinius duomenis fiksuoja naudodamas dokumentuotą SDK. Delno venų ir panašūs biometriniai identifikatoriai leidžia lojalumo platformai atpažinti grįžtantį klientą be kortelės, telefono numerio ar programėlės paieškos, jei aparatinės įrangos architektūra palaiko trečiųjų šalių prieigą prie šių duomenų.