Miks lojaalsusprogrammi tarkvara lukustatud POS-riistvara puhul ebaõnnestub?

Lojaalsusprogramm ebaõnnestub müügiterminalis ühel põhjusel rohkem kui ühelgi teisel: riistvara ei ole kunagi ehitatud välise tarkvara sisselaskmiseks. Jaemüüjad ostavad lojaalsusplatvormi, allkirjastavad lepingu, koostavad eelarve selle kasutuselevõtuks – ja avastavad seejärel, et terminali operatsioonisüsteem, SDK või maksesertifikaat blokeerib integratsiooni täielikult. See ei ole tarkvaraprobleem. See on riistvaraarhitektuuri probleem ja see ilmneb peaaegu iga kord, kui kaupmees üritab paigaldada lojaalsusprogrammi funktsionaalsusega müügisüsteemi terminalile, mis on loodud suletud makseseadmena, mitte avatud arvutiseadmena.
Enne mis tahes platvormi hindamist on kasulik kindlaks teha põhiküsimus, mida POS-terminal saab ja mida mitte preemiaandmetega teha — sest vastus sõltub täielikult selle all olevast riistvarast, mitte lojaalsusprogrammi funktsioonide loendist.
See artikkel selgitab konkreetseid tehnilisi põhjuseid, miks lojaalsusprogrammi integreeritud müügikohasüsteemid lukustatud riistvaral ei tööta, mida „lukustatud“ tegelikult operatsioonisüsteemi ja sertifitseerimise tasandil tähendab ning milline näeb välja hindamisnimekiri kaupmeestele, kes vajavad klientide lojaalsusprogrammi kuuluvat müügikohasüsteemi, mis tegelikult tootmises töötab.

1. Mida "lukustatud POS-riistvara" tegelikult tähendab

Lukustatud POS-riistvara on terminal, mille puhul tootja piirab, millised rakendused saavad töötada, millistele süsteemiressurssidele need rakendused juurde pääsevad või mõlemat. See on teadlik disainivalik, mitte defekt. Traditsioonilised kaardipõhised terminalid – peamiselt EMV ja PIN-koodiga tehingute jaoks ehitatud lauapealsed seadmed – on sertifitseeritud PCI PTS POI standardite kohaselt, mis käsitlevad kogu seadet ühtse usaldusväärse maksekeskkonnana. Lojaalsusrakenduse lisamine sellesse keskkonda tähendas ajalooliselt kaardiomaniku andmete kõrvale kinnitamata kooditee lisamist, mida maksebrändid ja hankijad ei luba.
Lukustatud terminali iseloomustavad kolm riistvaralist omadust:

• ● Suletud või tugevalt piiratud operatsioonisüsteem ilma rakenduste poe ja külglaadimiseta.
• ● Avaldatud SDK-d pole või on SDK piiratud kviitungi vormindamise ja põhiliste välisseadmete kõnedega.
• ● Ühe rakenduse püsivara mudel, kus makserakendus on ainus rakendus, mida seade töötab.

Ükski neist omadustest pole oma olemuselt vale. Vanemate müüjate spetsiaalsed kaardimakseterminalid on konstrueeritud spetsiaalselt PCI DSS-auditi ulatuse minimeerimiseks. Probleem ilmneb ainult siis, kui kaupmees eeldab, et sama terminal käitab ka lojaalsusprogrammi mooduliga müügikohta, CRM-sünkroniseerimist või turundusrakendust – funktsioone, mille toetamiseks riistvara pole kunagi sertifitseeritud ega kavandatud.

2. Miks lojaalsusprogrammid suletud müügikoha arhitektuurides ei tööta

Lojaalsusprogrammide integratsioonid ebaõnnestuvad suletud arhitektuurides kolmel korduval tehnilisel põhjusel: liivakastireeglid piiravad juurdepääsu andmetele, patenteeritud SDK-d blokeerivad installimist ja püsivara värskendustsüklid takistavad funktsioonide avaldamist.

2.1 PCI PTS liivakastireeglid piiravad kolmandate osapoolte andmetele juurdepääsu

PCI turvastandardite nõukogu avaldatud PCI PTS POI versioon 7.0 lubab nüüd kolmandate osapoolte rakendustel, näiteks rakenduste poe rakendustel, töötada sertifitseeritud POI-seadmetes. Kuid standard nõuab, et need rakendused oleksid turvaliselt isoleeritud tundlikest maksefunktsioonidest ja autentitud krüptograafiliste kontrollide abilSama versiooni uuem nõue blokeerib kolmandate osapoolte rakendustel selgetekstilise PAN- või PIN-koodi lugemise isegi siis, kui rakendus on heakskiidetud valges nimekirjas. Lojaalsusmootori jaoks on see otseselt oluline: iga integratsioonimuster, mis eeldab, et lojaalsusrakendus saab tehingu kogusummat, kaarditokenit või kliendi identifikaatorit otse makseprotsessist lugeda, ei ole v7.0 sertifitseeritud seadmes ühilduv. Lojaalsusrakendus peab need andmed vastu võtma heakskiidetud, isoleeritud kanali kaudu – ja paljudes lukustatud terminalides sellist kanalit pole.

2.2 Patenteeritud SDK-d blokeerivad lojaalsusrakenduste installimise

Lojaalsusplatvorm peab registreerima kliente, otsima punktide saldosid, rakendama lunastusi ning printima või kuvama müügikohas preemiaid. Igaüks neist toimingutest vajab SDK konksu. Suletud, müüja enda operatsioonisüsteemiga terminalid ei avalda tavaliselt ühtegi neist konksudest välistele arendajatele – lojaalsusprogrammi müüja integreerub maksevärava veebikonksu kaudu pärast tehingu lõpuleviimist, mis on liiga hilja reaalajas allahindluse rakendamiseks või seansisisese preemia käivitamiseks. See on kõige levinum tõrkemuster, millest kaupmehed on teatanud, kui nad lähevad üle vanadelt lauaarvutiterminalidelt müügikoha lojaalsusprogrammide juurutustele: integratsioon "töötab" tehniliselt tehingujärgse sünkroonimisena, kuid ei saa interaktsiooni enda ajal midagi teha.

2.3 Püsivara värskendustsüklid lõpetavad lojaalsusprogrammide väljalasked

Isegi kui lukustatud terminal avaldab piiratud SDK-d, uuendatakse üheotstarbeliste makseseadmete püsivara tavaliselt aeglase, sertifitseerimispõhise ajakava järgi, kuna iga püsivara muudatus võib käivitada PCI uuesti sertifitseerimise. Lojaalsusprogrammi müüja, kes soovib tarnida uue lunastusreegli, uue registreerimisvoo või uue preemiataseme, peab ootama riistvaratootja väljalasketsüklit, mitte enda oma. Avatud Androidi POS-terminalis uuendatakse lojaalsusrakendust iseseisvalt oma rakenduse paketi kaudu, ilma et see sõltuks terminali püsivarast üldse.

3. Ebaõnnestunud lojaalsusprogrammi integreerimise tegelik hind

Ebaõnnestunud integratsiooni otsene kulu on juurutamise takerdumine või tühistamine, kuid suurem kulu on strateegiline: jaemüüjad ostavad lojaalsustarkvara üha kiiremas tempos, samal ajal kui riistvara ühilduvus jääb teisejärguliseks. Globaalne lojaalsushalduse turg ulatus 2026. aastal hinnanguliselt 17.38 miljardi dollarini ja prognooside kohaselt kasvab see 2034. aastani üle 14% liitaastase määraga. Iga dollar, mis kulutatakse lojaalsusplatvormile, mis tegelikult kassariistvaral ei tööta, on kaks korda kulutatud dollar – üks kord tarkvarale ja teine ​​kord riistvara uuendamisele, mis oleks pidanud toimuma esimesena.
Samuti on vastavuskulud. Lojaalsusprogrammid koguvad ja töötlevad klientide isikuandmeid – nimesid, telefoninumbreid, ostuajalugu, mõnikord biomeetrilisi registreerimisandmeid puudutusega tuvastamise programmide jaoks. ELi määruse kohaselt 2016/679 (GDPR), et töötlemine nõuab dokumenteeritud õiguslikku alust ja nõuetele vastavat nõusolekuvoogu registreerumisel. Lojaalsusprogrammide integreerimine, mis on sunnitud läbi mitteametliku lahenduse – jailbreakitud terminali, toetuseta külglaaditud APK-i, ekraani kraapimise silla –, muudab vastavusdokumentatsiooni esitamise auditi ajal palju raskemaks, sest andmetee ise ei olnud kunagi mõeldud läbivaatamiseks.

4. Milline näeb välja avatud ja lojaalsusprogrammile orienteeritud müügikoha arhitektuur

Lojaalsust usaldusväärselt toetaval arhitektuuril on kolm ühist omadust: avatud SDK, rakenduste poe tasemel tarkvara levitamine ja riistvara identiteedi funktsioonid, mis ulatuvad kaardi libistamisest kaugemale.

4.1 Avatud SDK ja API juurdepääs

Avaldatud SDK-ga Android-põhised POS-terminalid võimaldavad lojaalsusprogrammide müüjatel luua otse dokumenteeritud API-de abil printeri, skänneri, kliendile suunatud ekraani ja maksetuuma jaoks – ilma iga uue funktsiooni jaoks riistvaratootjalt ootamata. See on sama avatud platvormi mudel, mille Square'i terminali API oma riistvara jaoks tutvustas, ja see on nüüdseks standardpraktika enamiku Androidi POS-tootjate seas, kes müüvad mitme müüjaga jaemüügikeskkondadesse, mitte suletud ühe rakendusega kioskitesse. Kaupmehed hangivad riistvara otse tarnijabaasist – sealhulgas Hiina POS-terminalitootjate B2B-maastik — peaks SDK avatust käsitlema hankefiltrina, mitte järelmõttena, mida arutatakse alles pärast lepingu allkirjastamist.

4.2 GMS-sertifikaat ja ühilduvus rakenduste poega

Google Mobile Services'i (GMS) sertifikaat võimaldab terminalil käitada standardseid Androidi rakenduste pakette Play poe või samaväärse hallatud rakenduste poe kaudu, selle asemel, et piirata seadet püsivaraga kaasasoleva tarkvaraga. GMS-sertifikaadiga terminal saab lojaalsusrakenduse installida samamoodi nagu telefon installib mis tahes muu rakenduse: iseseisvalt, müüja enda väljalaskegraafiku alusel, ilma püsivara tasemel uuesti sertifitseerimistsüklita.

4.3 Biomeetrilise lojaalsusprogrammi registreerimine

Väiksem, kuid kasvav terminalide hulk laiendab lojaalsusprogrammi abil identiteedi tuvastamist kaartide ja telefoninumbrite kõrval ka biomeetrilise registreerimise abil. Peopesa veenide tuvastamine on üks näide, mis on juba kommertskasutuses – ZCS on üks Androidi müügikohasüsteemide tootjaid, kes praegu tarnivad peopesa veenituvastusega terminale avatud SDK-ga, mis võimaldab lojaalsusplatvormil registreerida kliendi peopesa veenimustrit kassas alternatiivse identifikaatorina, selle asemel et nõuda kaardi, rakenduse või telefoninumbri otsingut. Sellist riistvaratasemel identiteedifunktsiooni saab lojaalsusplatvorm kasutada ainult siis, kui terminali SDK avaldab selle dokumenteeritud API-na – mis on täpselt eespool kirjeldatud avatud arhitektuuri nõue, mitte ühelegi kaubamärgile ainuomane funktsioon.

5. Hindamisnimekiri: kas teie müügikoha terminal on lojaalsusprogrammiks valmis?

Enne lojaalsusprogrammi lepingu allkirjastamist kontrollige terminali poolel järgmist:

• ● Terminalil on avaldatud ja dokumenteeritud SDK – mitte ainult maksevärava veebikonks.
• ● Terminal on GMS-sertifikaat ning toetab iseseisvate rakenduste installimist ja värskendamist.
• ● Tootja saab kinnitada PCI PTS POI vastavust mis tahes kolmanda osapoole rakenduse liivakastitehnoloogiale, mis vastab praeguse PTS POI versiooni isolatsiooninõuetele.
• ● Lojaalsusprogrammi müüja saab nimetada reaalajas kaupmehe viitenumbri, mis käitab täpset terminali mudelit, mitte ainult terminali kaubamärki.
• ● Riistvaratarnija püsivara väljalaske rütm on dokumenteeritud ja see ei blokeeri lojaalsusprogrammi müüja sõltumatuid rakenduse tasemel värskendusi.

Terminali valikukriteeriume – operatsioonisüsteemi avatust, sertifitseerimise ulatust, SDK sügavust – käsitletakse üksikasjalikumalt jaotises meie täielik raamistik Androidi POS-platvormi valimiseks, mis käsitleb sama hindamisloogikat ka väljaspool lojaalsuse kasutusjuhtumeid.

6. Korduma kippuvad küsimused

K1: Kas iga POS-terminal saab käitada lojaalsusprogrammi?

Ei. Terminal vajab avatud SDK-d, rakenduste poe tasemel tarkvara levitamist ja PCI PTS-iga ühilduvat liivakastikeskkonda kolmandate osapoolte rakenduste jaoks. Suletud, ühe rakendusega terminalid piiravad või blokeerivad lojaalsustarkvara täielikult, olenemata sellest, mida lojaalsusprogrammi pakkuja platvorm paberil toetab.
K2: Mis teeb POS-terminali „lukustatuks“?

Lukustatud terminal piirab installitavate rakenduste arvu, ei avalda avalikku SDK-d ja käitab ühe makserakenduse ümber ehitatud püsivara. Need omadused vähendavad PCI auditi ulatust, kuid blokeerivad ka lojaalsusrakendusi, CRM-i sünkroonimisi ja muid kolmandate osapoolte integratsioone.
K3: Kas PCI-vastavus takistab lojaalsusprogrammide käivitamist POS-riistvaras?

Mitte vaikimisi. PCI PTS POI v7.0 lubab kolmandate osapoolte rakendusi, sealhulgas lojaalsusrakendusi, tingimusel, et need on liivakastis, eraldatud selgetekstilistest maksekaardi- ja PIN-andmetest. Nõuetele vastavus nõuab eraldamist, mitte välistamist, ja terminali arhitektuur määrab, kas see eraldamine on tehniliselt võimalik.
K4: Mis vahe on tehingujärgsel lojaalsusprogrammi sünkroonimisel ja reaalajas integratsioonil?

Tehingujärgne sünkroonimine rakendab preemiaid pärast müügi lõpetamist maksevärava veebikonksu kaudu. Reaalajas integratsioon rakendab preemiaid kassas SDK konksu kaudu. Lukustatud terminalid toetavad tavaliselt ainult esimest, mis takistab seansisiseseid allahindlusi ja lunastusi.
K5: Kas biomeetrilist tuvastamist, näiteks peopesa veeni tuvastamist, saab kasutada lojaalsusprogrammi registreerumiseks?

Jah, terminalides, kus tootja avaldab biomeetrilise jäädvustamise dokumenteeritud SDK kaudu. Peopesa veeni ja sarnased biomeetrilised identifikaatorid võimaldavad lojaalsusplatvormil tuvastada naasva kliendi ilma kaardi, telefoninumbri või rakenduse otsinguta, eeldusel, et riistvaraarhitektuur toetab kolmandate osapoolte juurdepääsu neile andmetele.