Namestitev soft POS: od prenosa aplikacije do prvega plačila
October 21, 2026
Za mobilne aplikacije brez dodatne strojne opreme izberite izoliran SoftPOS oziroma MPoC SDK, saj zmanjša vaš obseg skladnosti in pospeši razvoj. Za visokoobremenjene fizične lokacije je bolj zanesljiv klasičen POS terminal z ločenim SDK-jem. Izbira SDK-ja določa, koliko varnostne dokumentacije in testiranja prevzamete vi in koliko ponudnik, zato jo velja premisliti pred prvo vrstico kode.
Na kratko:
- Izbira izoliranega MPoC SDK-ja zmanjša vaš obseg varnostne dokumentacije in pospeši čas certifikacije, kar je prednost predvsem za manjše projekte.
- SoftPOS je primeren za mobilne aplikacije brez dodatne strojne opreme, vendar zahteva skladnost s PCI MPoC, medtem ko klasičen POS zagotavlja večjo zanesljivost pri velikem obsegu transakcij.
- Integracija Apple Pay in Google Pay zahteva ločene strežniške postopke za validacijo in tokenizacijo, kar podaljša razvojni cikel v primerjavi z običajnimi kartičnimi SDK-ji.
- Pri izbiri SDK-ja je pomembno preveriti, ali je navedena na uradnem seznamu MPoC rešitev pri PCI SSC in katere plačilne metode podpira, saj to vpliva na stroške in skladnost.
- Pri razvoju je priporočljivo začeti z gateway tokenizacijo, saj zmanjšuje varnostne obveznosti in pospešuje predstavitev MVP-ja na trg.
Preden začnete pisati kodo, velja razumeti tri osnovne poti do sprejemanja plačil v aplikaciji in kdaj je vsaka smiselna.
SoftPOS (včasih imenovan tudi MPoC) spremeni navadni telefon ali tablico v sprejemnik kartičnih plačil. Rešitev deluje na običajnih potrošniških napravah (angleško COTS, commercial off-the-shelf) in ne potrebuje dodatnega čitalnika kartic. Taka rešitev je varna, kadar je skladna s standardom PCI MPoC, ki ga je postavil PCI Security Standards Council. Primerna je za taksiste, serviserje na terenu, stojnice na dogodkih in vsakogar, ki potrebuje mobilnost brez dodatne opreme.
Klasičen POS z ločenim SDK-jem pomeni, da aplikacija komunicira z namensko strojno napravo (terminalom), ki opravi samo kartično transakcijo, medtem ko vaša aplikacija upravlja preostali del poslovnega procesa. Ta pristop je bolj zanesljiv pri visokem obsegu transakcij, ker je strojna oprema namenjena izključno plačilom in manj podvržena prekinitvam operacijskega sistema telefona.
Vgrajene plačilne knjižnice, kot sta Apple Pay in Google Pay, pa ne zamenjujejo kartičnega terminala, temveč olajšajo plačilo prek digitalne denarnice znotraj aplikacije ali na spletu.
Razlike med pristopi so predvsem naslednje:
Za razvijalca je odločitev pogosto kombinacija: SoftPOS ali klasičen terminal za fizično sprejemanje kartic, dopolnjen z Apple Pay in Google Pay za hitrejše plačevanje znotraj aplikacije.
Varnostni okvir, znotraj katerega deluje SDK, neposredno vpliva na to, koliko dela in stroškov pade na vašo ekipo.
PCI MPoC je standard, namenjen prav mobilnim plačilom na navadnih napravah. Zahteva, da rešitev podpira vsaj eno obliko vnosa podatkov neposredno na napravi (na primer brezstično branje) in vsaj eno standardno EMV obliko vnosa, na primer stik s čipom ali PIN. Ko izberete izoliran (isolating) MPoC SDK, se del odgovornosti za varnost in upravljanje kriptografskih ključev prenese na ponudnika SDK-ja, kar lahko bistveno zmanjša obseg lastne PCI dokumentacije in laboratorijskega preverjanja, ki ga morate opraviti sami.
To pa ne pomeni, da je odgovornost ponudnika povsem avtomatizirana. Ponudnik mora redno izvajati storitve spremljanja in vzdrževanja (angleško attestation and monitoring, A&M) ter sodelovati pri preverjanju s strani PCI SSC, sicer se status skladnosti SDK-ja lahko izteče.
Statistični poudarek: PCI SSC je maja 2026 izdal MPoC SDK Integration Report v1.1, ki natančneje opredeljuje postopek integracije izoliranih MPoC SDK-jev in s tem lahko skrajša čas, potreben za vendor verification, če ponudnik sledi priporočenim korakom.
Pri EMV in NFC transakcijah SDK običajno poskrbi za tokenizacijo, torej zamenjavo dejanske številke kartice z enkratnim žetonom, ki je uporaben samo za posamezno transakcijo. To zmanjša tveganje, da bi podatki kartice uhajali skozi vašo aplikacijo, saj surovi podatki pogosto nikoli ne zapustijo varnega modula SDK-ja.
Konsekvenca za razvijalca je preprosta: izoliran SDK praviloma pomeni manj lastne PCI dokumentacije, nižje stroške certificiranja in hitrejši čas do produkcije, neizoliran pristop pa zahteva lastno vlaganje v varnostno revizijo in pogosto tudi v laboratorijsko testiranje.
Strokovni nasvet: Pred podpisom pogodbe z vsakim ponudnikom SDK-ja preverite, ali je njegova rešitev dejansko navedena na uradnem seznamu MPoC listed solutions pri PCI SSC, ne zgolj oglaševana kot “skladna”.
Izbira platforme vpliva na to, kateri SDK boste uporabili in koliko strežniškega dela boste morali opraviti sami.
Na Androidu večina SoftPOS in klasičnih POS ponudnikov dostavi nativni SDK v obliki knjižnice, ki jo vključite prek Gradle odvisnosti. Na iOS strani je postopek podoben, le da morate upoštevati Appleove omejitve glede dostopa do NFC strojne opreme. Flutter in React Native razvijalci običajno uporabljajo ovojne (wrapper) vtičnike, ki kličejo isti nativni SDK v ozadju, kar pomeni, da je testiranje na obeh platformah še vedno obvezno, tudi če pišete skupno kodo.
Pri vgradnji Apple Pay in Google Pay je postopek na strežniški strani ključen in se razlikuje od običajne kartične integracije:
isReadyToPay pred prikazom gumba za plačilo in konfiguracijo tokenizationSpecification.tokenizationSpecification izberete med PAYMENT_GATEWAY, kjer tokenizacijo opravi vaš plačilni ponudnik in s tem razbremeni vaš strežnik velikega dela PCI obveznosti, ali DIRECT, kjer prevzamete poln nadzor nad šifriranimi podatki, kar pa zahteva strožje upoštevanje PCI DSS.Za hiter začetek je PAYMENT_GATEWAY pristop pri Google Pay praviloma smiselna izbira, ker znatno zmanjša obseg strežniških PCI obveznosti v primerjavi z DIRECT načinom.
Ko ste izbrali platformo in SDK, sledi dejanska implementacija, ki vedno vključuje tako odjemalsko kot strežniško stran.
Testiranje naj poleg sandboxa vključuje tudi simulacije napak, na primer prekinjeno omrežno povezavo med avtorizacijo in potrditvijo, saj se prav tam najpogosteje skrivajo napake, ki jih v mirnem testnem okolju ne opazite. Preverite tudi isReadyToPay odziv na napravah brez nastavljene plačilne metode, da aplikacija ne prikaže gumba, ki ga uporabnik ne more uporabiti.
Med pogostimi napakami pri integraciji so napačno konfigurirana CORS pravila na strežniškem endpointu za Merchant Validation, potekli ali napačno naloženi certifikati ter pomanjkanje jasnega načrta za rollback, če transakcija obvisi med avtorizacijo in potrditvijo. Priprava mehanizma za ponovno poizvedbo o stanju transakcije precej zmanjša število pritožb uporabnikov.
Strokovni nasvet: Preden aplikacijo pošljete v pregled pri Applu ali Googlu, preverite celoten tok plačila na resnični napravi, ne le v simulatorju, saj se NFC in Secure Enclave vedenje med njima pomembno razlikujeta.
Ko primerjate konkretne ponudnike SDK-jev, si pomagajte z naborom kriterijev, ki presegajo samo ceno licence.
Pri izbiri ponudnika vprašajte tudi, kakšen je model podpore ob izpadu storitve in kako hitro odzivajo na incidente, saj to pogosto pove več o zanesljivosti kot marketinško gradivo.
Hitrejša vpeljava skoraj vedno pomeni izoliran SDK z manj lastnega nadzora, počasnejša, a bolj prilagodljiva pot pa pomeni več lastnega razvoja in revizije. Odločitev je odvisna od tega, ali vaš produkt zahteva hitro tržno validacijo ali dolgoročno nadzorovano arhitekturo.
Časovni okvir se precej razlikuje glede na to, katero rešitev izberete, zato velja pričakovanja uskladiti že pred začetkom projekta.
Integracija samo Apple Pay ali Google Pay v obstoječo aplikacijo je praviloma najhitrejša pot do delujočega MVP-ja, saj gre predvsem za sledenje uradnim vodnikom in vzpostavitev enega strežniškega endpointa. SoftPOS integracija z MPoC skladnostjo zahteva dodaten čas za pridobitev certifikatov in morebitno vendor verification, zato je smiselno računati na daljši razvojni cikel. Klasičen POS z ločenim SDK-jem je pri fizični integraciji pogosto najbolj predvidljiv, saj gre za uveljavljeno strojno opremo, vendar zahteva usklajevanje dobave naprav.
Glavne stroškovne postavke pri tovrstnem projektu so:
Statistični poudarek: PCI SSC navaja, da jasnejše smernice za izolirane MPoC SDK-je lahko skrajšajo čas vendor verification, kar neposredno znižuje stroške certificiranja za ekipe, ki sledijo priporočenemu postopku integracije.
Za znižanje začetnih stroškov je smiselno začeti z že verificiranim SDK-jem in gateway tokenizacijo, saj se s tem izognete velikemu delu lastne varnostne revizije. Podroben pregled provizij in stroškov brez fiksnih mesečnih obveznosti najdete v vodniku o sprejemanju plačil brez fiksnih stroškov.
Pri razvoju aplikacije, ki mora sprejemati kartice v fizičnem okolju, pogosto potrebujete tudi preizkušeno strojno opremo, ne le programsko rešitev.
Ko razvijalska ekipa testira integracijo SoftPOS ali klasičnega POS SDK-ja, lahko podporo pri nas izkoristite na nekaj konkretnih načinov:
Za ekipe, ki razvijajo aplikacijo s plačilno funkcionalnostjo in hkrati potrebujejo fizično opremo za sprejemanje kartic, je to pogosto hitrejša pot do delujoče rešitve kot graditev lastnega strojnega sloja od začetka.
Pri večini projektov, ki jih spremljamo, se ekipe prehitro osredotočijo na uporabniški vmesnik plačila, preden sploh razčistijo, kdo nosi varnostno odgovornost. To je napačen vrstni red. Najprej je treba zagotoviti skladnost in jasno razmejitev odgovornosti med vašim strežnikom in ponudnikom SDK-ja, šele nato ima smisel vlagati čas v lepljenje gumbov in animacij.
Druga stvar, ki jo pogosto podcenjujejo produktni lastniki, je hitrost do prvega delujočega plačila. Priporočamo, da MVP zgradite z gateway tokenizacijo, kjer ponudnik plačil prevzame večino varnostnega bremena, in šele kasneje, če poslovni model to resnično zahteva, preidete na neposreden (DIRECT) pristop z večjim nadzorom. Preskakovanje tega zaporedja običajno podaljša čas do lansiranja, ne pa izboljša uporabniške izkušnje.
— PosSlo
Ko pride čas za testiranje plačilnega SDK-ja na resnični strojni opremi, ponujamo neposredno pot do tega brez zapletenih pogodb ali skritih mesečnih stroškov. Namesto da sami iščete dobavitelja terminalov in se ukvarjate z nastavitvami merchant računa, lahko ta del prepustite nam in se osredotočite na razvoj aplikacije.
Naša ponudba vključuje:
Konkurenčne tarife, instantna izplačila in brez mesečnih stroškov veljajo za vse naprave, ki jih ponujamo. Če razvijate aplikacijo, ki bo potrebovala fizično sprejemanje kartic ob lansiranju, si lahko že danes preverite ponudbo soft POS rešitev in nas kontaktirate glede testne naprave za vašo integracijo.
SoftPOS spremeni navadno pametno napravo v sprejemnik plačil brez dodatne strojne opreme, medtem ko klasičen POS uporablja namenski terminal, ločen od telefona. SoftPOS je bolj mobilen, klasičen POS pa je pogosto zanesljivejši pri visokem obsegu dnevnih transakcij.
PCI MPoC zahteva, da rešitev za mobilna plačila podpira vsaj eno obliko vnosa podatkov neposredno na napravi in vsaj eno standardno EMV obliko vnosa. Izoliran SDK, skladen s tem standardom, zmanjša obseg lastne varnostne dokumentacije, ki jo morate pripraviti kot razvijalec.
Pri Apple Pay strežnik izvede Merchant Validation s certifikati, pridobljenimi pri Applu, medtem ko Google Pay integracija na Androidu temelji na preverjanju isReadyToPay in izbiri med PAYMENT_GATEWAY ali DIRECT tokenizacijo. Oba pristopa zahtevata ločeno strežniško logiko, ki je ločena od odjemalske kode.
Integracija Apple Pay ali Google Pay je praviloma najhitrejša, saj gre predvsem za sledenje uradnim vodnikom in enemu strežniškemu endpointu. SoftPOS integracija z MPoC skladnostjo traja dlje zaradi pridobivanja certifikatov in morebitnega vendor verification postopka.
Da, pri skoraj vseh resnih integracijah, saj Merchant Validation za Apple Pay in izmenjava tokenov za Google Pay ali SoftPOS ponudnike ne sme potekati v mobilni aplikaciji. Strežniška komponenta hrani certifikate in izvaja občutljive korake, ki jih odjemalska koda ne sme opravljati.
