2026-08-10 Autori: ZCS
Një program besnikërie dështon në një terminal POS për një arsye më shumë se çdo tjetër: hardueri nuk është ndërtuar kurrë për të lejuar hyrjen e softuerëve të jashtëm. Shitësit me pakicë blejnë një platformë besnikërie, nënshkruajnë kontratën, parashikojnë buxhetin e lançimit - pastaj zbulojnë se sistemi operativ, SDK ose certifikimi i pagesës i terminalit bllokojnë tërësisht integrimin. Ky nuk është një problem softueri. Është një problem i arkitekturës së harduerit dhe shfaqet pothuajse çdo herë që një tregtar përpiqet të fiksojë një sistem POS me funksionalitetin e programit të besnikërisë në një terminal që është projektuar si një pajisje pagese e mbyllur dhe jo si një pajisje kompjuterike e hapur.
Përpara se të vlerësohet ndonjë platformë, ndihmon të përcaktohet Pyetja bazë se çfarë mund dhe nuk mund të bëjë një terminal POS me të dhënat e shpërblimeve — sepse përgjigjja varet tërësisht nga hardueri që ndodhet poshtë tij, jo nga lista e veçorive të softuerit të besnikërisë.
Ky artikull analizon arsyet specifike teknike pse sistemet POS të integruara me besnikëri dështojnë në pajisjet e bllokuara, çfarë do të thotë në të vërtetë "i bllokuar" në nivelin e sistemit operativ dhe certifikimit, dhe si duket një listë kontrolli vlerësimi për tregtarët që kanë nevojë për një sistem POS të besnikërisë së klientit që funksionon realisht në prodhim.
Pajisjet POS të bllokuara janë një terminal ku prodhuesi kufizon se cilat aplikacione mund të ekzekutohen, cilat burime sistemi mund të qasen nga këto aplikacione, ose të dyja. Ky është një zgjedhje e qëllimshme e dizajnit, jo një defekt. Terminalet tradicionale me kartë - njësitë e banakut të ndërtuara kryesisht për transaksione EMV dhe PIN - janë të certifikuara sipas standardeve PCI PTS POI që e trajtojnë të gjithë pajisjen si një mjedis të vetëm pagese të besuar. Shtimi i një aplikacioni besnikërie në atë mjedis historikisht nënkuptonte shtimin e një shtegu kodi të paverifikuar pranë të dhënave të mbajtësit të kartës, të cilin markat e pagesave dhe blerësit nuk e lejojnë.
Tre karakteristika të harduerit përcaktojnë një terminal të mbyllur:
Asnjë nga këto tipare nuk është në thelb e gabuar. Terminalet e dedikuara për praninë e kartës nga shitësit e vjetër janë projektuar në këtë mënyrë posaçërisht për të minimizuar fushëveprimin e auditimit të PCI DSS. Problemi shfaqet vetëm kur një tregtar pret që i njëjti terminal të ekzekutojë edhe një pikë shitjeje me modul programi besnikërie, një sinkronizim CRM ose një aplikacion marketingu - aftësi për të cilat pajisja nuk është certifikuar ose arkitekturuar kurrë për t'i mbështetur.
Integrimet e besnikërisë dështojnë në arkitekturat e mbyllura për tre arsye teknike të përsëritura: rregullat e sandbox-it kufizojnë aksesin në të dhëna, SDK-të pronësore bllokojnë instalimin dhe ciklet e përditësimit të firmware-it pengojnë shpërndarjen e veçorive.
Versioni 7.0 i PCI PTS POI, i publikuar nga Këshilli i Standardeve të Sigurisë PCI, tani lejon që aplikacionet e palëve të treta, siç janë aplikacionet e dyqanit të aplikacioneve, të ekzekutohen në pajisjet e çertifikuara POI. Por standardi kërkon që këto aplikacione të jenë i izoluar në mënyrë të sigurt nga funksionet e ndjeshme të pagesave dhe i autentifikuar duke përdorur kontrolle kriptografikeNjë kërkesë më e re në të njëjtin version bllokon aplikacionet e palëve të treta nga leximi i të dhënave PAN ose PIN me tekst të qartë edhe kur aplikacioni është në një listë të bardhë të miratuar. Për një motor besnikërie, kjo ka rëndësi drejtpërdrejt: çdo model integrimi që supozon se aplikacioni i besnikërisë mund të lexojë totalin e transaksionit, tokenin e kartës ose identifikuesin e klientit direkt jashtë procesit të pagesës nuk është në përputhje me një pajisje të çertifikuar me v7.0. Aplikacioni i besnikërisë duhet t'i marrë ato të dhëna përmes një kanali të miratuar dhe të izoluar - dhe në shumë terminale të kyçura, nuk ekziston një kanal i tillë.
Një platformë besnikërie duhet të regjistrojë klientët, të kërkojë bilancet e pikëve, të aplikojë shpengimet dhe të printojë ose shfaqë shpërblimet në pikën e shitjes. Secili prej këtyre veprimeve ka nevojë për një grep SDK. Terminalet me një sistem operativ të mbyllur, në pronësi të shitësit, zakonisht nuk i ekspozojnë asnjë nga këto grepa zhvilluesve të jashtëm - shitësi i besnikërisë mbetet duke u integruar përmes një webhook-u të portës së pagesës pasi transaksioni është mbyllur tashmë, gjë që është tepër vonë për të aplikuar një zbritje në kohë reale ose për të shkaktuar një shpërblim gjatë seancës. Ky është modeli më i zakonshëm i dështimit i raportuar nga tregtarët që kalojnë nga terminalet e vjetra të banakut në vendosjet e programeve të besnikërisë në pikat e shitjes: integrimi teknikisht "funksionon" si një sinkronizim pas transaksionit, por nuk mund të bëjë asgjë në vetë pikën e ndërveprimit.
Edhe kur një terminal i bllokuar ekspozon një SDK të kufizuar, firmware-i në pajisjet e pagesave me një qëllim të vetëm zakonisht përditësohet me një orar të ngadaltë, të bazuar në certifikim, pasi çdo ndryshim i firmware-it mund të shkaktojë riçertifikim të PCI-së. Një shitës besnikërie që dëshiron të dërgojë një rregull të ri shpengimi, një fluks të ri regjistrimi ose një nivel të ri shpërblimesh duhet të presë ciklin e lëshimit të shitësit të pajisjeve - jo të vetin. Në një terminal POS të hapur Android, aplikacioni i besnikërisë përditësohet në mënyrë të pavarur përmes paketës së vet të aplikacionit, pa asnjë varësi nga firmware-i i terminalit.
Kostoja direkte e një integrimi të dështuar është një lançim i bllokuar ose i përmbysur, por kostoja më e madhe është strategjike: shitësit me pakicë vazhdojnë të blejnë softuer besnikërie me një ritëm në rritje, ndërsa përputhshmëria e harduerit mbetet një mendim i dytë. Tregu global i menaxhimit të besnikërisë arriti në rreth 17.38 miliardë dollarë në vitin 2026 dhe parashikohet të rritet me një normë vjetore të përbërë mbi 14% deri në vitin 2034. Çdo dollar i shpenzuar në një platformë besnikërie që në të vërtetë nuk mund të funksionojë në harduerin e arkës është një dollar i shpenzuar dy herë - një herë në softuer, një herë tjetër në një rifreskim hardueri që duhej të kishte ndodhur më parë.
Ekziston edhe një kosto përputhshmërie. Programet e besnikërisë mbledhin dhe përpunojnë të dhëna personale të klientëve - emrat, numrat e telefonit, historikun e blerjeve, ndonjëherë të dhëna biometrike të regjistrimit për programet e identifikimit me prekje. Sipas Rregullores së BE-së 2016/679 (GDPR), se përpunimi kërkon një bazë ligjore të dokumentuar dhe një rrjedhë pëlqimi në përputhje me rregullat gjatë regjistrimit. Një integrim besnikërie i detyruar përmes një zgjidhjeje jozyrtare - një terminal i bllokuar, një APK i pambështetur i ngarkuar anash, një urë për skranim ekrani - e bën atë dokumentacion të përputhshmërisë shumë më të vështirë për t'u prodhuar gjatë një auditimi, sepse vetë rruga e të dhënave nuk është projektuar kurrë për t'u rishikuar.
Një arkitekturë që mbështet besnikërinë ndan në mënyrë të besueshme tre tipare: një SDK të hapur, shpërndarje softuerësh në nivelin e dyqanit të aplikacioneve dhe karakteristika të identitetit të harduerit që shkojnë përtej një rrëshqitjeje karte.
Terminalet POS të bazuara në Android me një SDK të publikuar i lejojnë një shitësi besnikërie të ndërtojë drejtpërdrejt mbi API-të e dokumentuara për printerin, skanerin, ekranin që i drejtohet klientit dhe bërthamën e pagesave - pa pritur prodhuesin e pajisjeve për çdo veçori të re. Ky është i njëjti model me platformë të hapur që API-ja e Terminalit e Square prezantoi për pajisjet e veta, dhe tani është praktikë standarde në shumicën e prodhuesve të POS-ve Android që shesin në mjedise me pakicë me shumë shitës në vend të kioskave të mbyllura me një aplikacion të vetëm. Tregtarët që furnizohen me pajisje direkt nga baza e furnizimit - duke përfshirë Peizazhi B2B i prodhuesve kinezë të terminaleve POS — duhet ta trajtojnë hapjen e SDK-së si një filtër prokurimi, jo si një mendim të mëvonshëm që diskutohet vetëm pasi të nënshkruhet kontrata.
Certifikimi i Shërbimeve Mobile të Google (GMS) i lejon një terminali të ekzekutojë paketa standarde të aplikacioneve Android përmes Play Store ose një dyqani aplikacionesh të menaxhuar ekuivalent, në vend që ta kufizojë pajisjen në softuer të përfshirë në firmware. Një terminal i certifikuar nga GMS mund të instalojë një aplikacion besnikërie në të njëjtën mënyrë siç instalon një telefon çdo aplikacion tjetër: në mënyrë të pavarur, sipas orarit të lëshimit të vetë shitësit, pa një cikël riçertifikimi në nivelin e firmware-it.
Një grup më i vogël, por në rritje terminalesh, e zgjerojnë identifikimin e besnikërisë përmes kartave dhe numrave të telefonit në regjistrimin biometrik. Njohja e venave të pëllëmbës është një shembull që tashmë është në zbatim komercial — ZCS është ndër prodhuesit e POS-ve Android që aktualisht ofrojnë terminale të aktivizuara me venë pëllëmbësh me një SDK të hapur, duke i lejuar një platforme besnikërie të regjistrojë modelin e venës së pëllëmbës së një klienti si një identifikues alternativ në arkë në vend që të kërkojë një kërkim karte, aplikacioni ose numri telefoni. Ky lloj funksioni identiteti në nivel hardueri mund të përdoret vetëm nga një platformë besnikërie kur SDK e terminalit e ekspozon atë si një API të dokumentuar - që është pikërisht kërkesa e arkitekturës së hapur e përshkruar më sipër, jo një funksion unik për ndonjë markë të vetme.
Para se të nënshkruani një kontratë softueri besnikërie, konfirmoni sa vijon në anën e terminalit:
Kriteret e përzgjedhjes së terminalit — hapja e sistemit operativ, fushëveprimi i certifikimit, thellësia e SDK — trajtohen më hollësisht në Korniza jonë e plotë për zgjedhjen e një platforme POS Android, e cila ndjek të njëjtën logjikë vlerësimi përtej vetëm rasteve të përdorimit të besnikërisë.
P1: A mund të drejtojë ndonjë terminal POS një program besnikërie?
Jo. Një terminal ka nevojë për një SDK të hapur, shpërndarje softueri në nivel dyqani aplikacionesh dhe sandbox të pajtueshëm me PCI PTS për aplikacionet e palëve të treta. Terminalet e mbyllura, me një aplikacion të vetëm, kufizojnë ose bllokojnë tërësisht softuerin e besnikërisë, pavarësisht se çfarë mbështet në letër platforma e shitësit të besnikërisë.
P2: Çfarë e bën një terminal POS "të mbyllur"?
Një terminal i mbyllur kufizon aplikacionet e instalueshme, nuk ekspozon asnjë SDK publik dhe ekzekuton firmware të ndërtuar rreth një aplikacioni të vetëm pagese. Këto karakteristika zvogëlojnë fushëveprimin e auditimit të PCI, por gjithashtu bllokojnë aplikacionet e besnikërisë, sinkronizimet CRM dhe integrimet e tjera të palëve të treta që nga vetë dizajni.
P3: A i pengon përputhshmëria me PCI aplikacionet e besnikërisë të funksionojnë në pajisjet POS?
Jo si parazgjedhje. PCI PTS POI v7.0 lejon aplikacione të palëve të treta, duke përfshirë aplikacionet e besnikërisë, me kusht që ato të jenë të izoluara nga të dhënat e kartave të pagesave me tekst të qartë dhe të PIN-it. Pajtueshmëria kërkon izolim, jo përjashtim, dhe arkitektura e terminalit përcakton nëse ky izolim është teknikisht i mundur.
P4: Cili është ndryshimi midis një sinkronizimi të besnikërisë pas transaksionit dhe një integrimi në kohë reale?
Një sinkronizim pas transaksionit zbaton shpërblimet pas mbylljes së shitjes, përmes një webhook-u të portalit të pagesave. Një integrim në kohë reale zbaton shpërblimet gjatë përfundimit të blerjes, përmes një hook-u SDK. Terminalet e kyçura zakonisht mbështesin vetëm të parin, gjë që parandalon zbritjet dhe shpërblimet gjatë seancës.
P5: A mund të përdoret identifikimi biometrik, siç është vena e palmës, për regjistrimin e besnikërisë?
Po, në terminalet ku prodhuesi ekspozon kapjen biometrike përmes një SDK të dokumentuar. Identifikuesit biometrikë të venës së palmës dhe identifikues të ngjashëm biometrikë lejojnë që një platformë besnikërie të njohë një klient që kthehet pa një kartë, numër telefoni ose kërkim aplikacioni, me kusht që arkitektura e harduerit të mbështesë aksesin e palëve të treta në ato të dhëna.
Kryesore 
Si funksionon njohja e venave të palmës për programet e anëtarësimit dhe besnikërisë? 
