Kuinka vaikeaa on rakentaa oma Tap to Pay -sovellus? (Me kokeilimme)
Julkaisimme tap to pay -lähimaksun omassa POS-sovelluksessamme. Tässä on, mitä se todella vaatii: kumppanuuden maksunvälittäjän kanssa, Applen käyttöoikeuden (entitlement), PCI-sertifioinnin Androidilla ja toimivan kassajärjestelmän lähimaksun ympärille.

Vaikeampaa kuin SDK-esitteet antavat ymmärtää, eikä vaikeus johdu pääasiassa koodista. Julkaisimme Tap to Pay -ominaisuuden Final POS -sovelluksessa, joten tämä vastaus perustuu käytännön kokemukseen, ei dokumentaation lukemiseen. Jos haluat rakentaa oman tap to pay -sovelluksen, varaudu lyhyeen ohjelmistoprojektiin, joka on kääritty paljon pidemmän lupaprojektin sisään: kumppanuus maksunvälittäjän kanssa, manuaalinen käyttöoikeus (entitlement) Applelta tai laboratorioarviointi Androidilla sekä sovelluksen arviointi – kaikki tämä ennen ensimmäistäkään todellista lähimaksua.
Pieni varoitus: alustojen ja korttialan säännöt muuttuvat usein. Kaikki alla oleva pitää paikkansa julkaisuhetkellä, joten suhtaudu yksityiskohtiin tilannevedoksena.
Mitä tap to pay -sovellus oikeastaan tekee?
Tap to pay muuttaa puhelimen itsessään kortinlukijaksi. Ei maksupäätettä, ei donglea: asiakas näyttää lähimaksukorttia tai puhelimen lompakkoa, kuten Apple Payta tai Google Payta, suoraan kauppiaan laitteeseen, ja maksu kulkee puhelimen NFC-sirun (lähimaksuissa käytettävän lyhyen kantaman radion) kautta. Jos terminologia tuntuu epäselvältä, olemme eritelleet mobiililähimaksujen ja mobiililaitteella tapahtuvan Tap to Pay -maksamisen eron.
Tässä on sudenkuoppa. NFC-tunnisteen lukeminen on todellakin vain viikonloppuprojekti; harrastajat tekevät sitä jatkuvasti. Maksukortin lukeminen on aivan eri laji. Kortit käyttävät EMV-protokollaa (korttialan siruprotokolla), korttitietojen on pysyttävä salattuina päästä päähän, ja vain sertifioitu ohjelmisto saa koskea niihin.
Miksi et voi vain lukea korttia itse?
Koska pinon jokainen kerros vaatii luvan ennen kuin koodisi saa ajaa julkisesti.
Apple ei anna sovelluksille suoraa pääsyä maksamiseen käytettävään NFC-yhteyteen. Sinun on käytettävä sen ProximityReader-kehystä, joka vaatii Tap to Pay on iPhone -käyttöoikeuden (entitlement) (erityisoikeus, jonka Apple myöntää tapauskohtaisesti). Apple vaatii myös integroinnin tuetun maksupalveluntarjoajan eli PSP:n (yritys, joka todellisuudessa siirtää rahat) kanssa. PSP toimittaa kauppiaan laitteeseen ladattavat sertifioidut lukija-asetukset ja kantaa sertifiointivastuun.
Android antaa kehittäjille avoimemman pääsyn NFC-yhteyteen, mutta riippumattoman, PCI-hyväksytyn laboratorion on silti arvioitava maksuja vastaanottava sovellus PCI MPoC -standardin (korttialan turvallisuussäännöt puhelimille, jotka toimivat maksupäätteinä) mukaisesti.
Molempien alustojen alla tarvitset lunastussuhteen (acquiring relationship): maksunvälittäjän, joka on valmis selvittämään rahat kauppiaillesi korttiverkostojen sääntöjen mukaisesti.
Mitään tästä ei voi ratkaista pelkästään kirjoittamalla parempaa koodia. Kyse on paperitöistä, sopimuksista ja arviointijonoista.

Miltä hyväksyntäpolku näyttää iPhonella?
Applen julkaisemien vaatimusten mukaan polku etenee näin: sinulla on oltava organisaatiotason Apple Developer -tili (tilinhaltija tekee pyynnön henkilökohtaisesti), kumppanuus alueillasi tuetun PSP:n kanssa, pyydettävä käyttöoikeutta (entitlement), integroitava ProximityReader API tai PSP:si SDK, noudatettava Applen suunnitteluohjeita maksunäytölle ja lähetettävä sovellus arvioitavaksi. Applen dokumentaatiossa mainitaan myös, että ominaisuus toimii vain tuetuissa maissa ja alueilla, joten saatavuus itsessään päätetään puolestasi markkina-alueittain.
Lue tuo lista uudelleen perustajan tai kauppiaan, älä kehittäjän, näkökulmasta. Yksikään vaiheista ei ole "kirjoita ominaisuus". Ominaisuus on se helppo osuus; käyttöoikeus on se vallihauta.
Mihin työ kohdistuu sen jälkeen, kun lähimaksu toimii?
Hyväksytty lähimaksu antaa sinulle maksun, ei kassajärjestelmää. Heti kun raha liikkuu, kaiken maksun ympärillä on oltava oikein: ostoskori, johon se kohdistuu, kuitin verot, hyvityspolku ja täsmäävä raportointi (jokainen euro yhdistettynä myyntiin, joka päivä). Huomasimme saman puutteen, kun selvitimme, voiko POS-järjestelmän rakentaa Lovablella tai Replitillä: käyttöliittymän luominen on nopeaa, mutta sen alla oleva kaupankäyntikerros on se, mikä vie kalenterista aikaa.
Tap to pay tuo mukanaan myös omia toiminnallisia erikoisuuksiaan. Meidän toteutuksessamme myynti on kirjattava samalla laitteella, joka vastaanottaa lähimaksun, ja se toimii vain natiivisovelluksessa, ei koskaan selaimessa. Tällaisia rajoituksia ei näy missään esitteessä. Ne löydetään, ne ratkaistaan teknisesti ja sitten niistä kirjoitetaan ohjeartikkeli. Ja kun tiskillä oleva puhelin ei enää riitä, edessä ovat joka tapauksessa todelliset laitteistopäätökset anyway.

Kuinka vaikeaa on siis rakentaa oma tap to pay -sovellus?
Vaikeaa tietyllä tavalla: koodaus on pienin osa-alue, kun taas maksunvälittäjäkumppanuus, Applen käyttöoikeus, Androidin laboratoriotodistus ja sovelluksen arviointi muodostavat valtaosan, eikä mikään niistä reagoi kehitystyön määrään. Meille se oli sen arvoista, koska POS-alusta jakaa nämä kustannukset kaikkien sitä käyttävien kauppiaiden kesken. Tap to pay on nyt kassapainike, jonka kauppiaamme voivat ottaa käyttöön, ja Tap to Pay -maksun vastaanottaminen on viisivaiheinen rutiini tiskillä. Jos maksut ovat tuotteesi, tämä haaste on sisäänpääsyn hinta. Jos maksut ovat vain tapa saada palkkasi, oman tap to pay -sovelluksen rakentamisessa ei ole taloudellisesti järkeä; valmis versio on jo olemassa POS-sovelluksissa, ja kulut ovat se, missä todellinen vertailu tapahtuu.
Nyrkkisääntö: jos ominaisuuden olemassaolo vaatii jonkun toisen luvan, mikään määrä nokkelaa koodia ei oikaise sitä.
Usein kysytyt kysymykset
Tarvitseeko Tap to Payta varten erillisen kortinlukijan?
Ei. Puhelin toimii lukijana: asiakas näyttää lähimaksuominaisuudella varustettua korttia tai puhelimen lompakkosovellusta kauppiaan laitteelle, ja maksu kulkee puhelimen NFC-sirun kautta.
Voiko kuka tahansa kehittäjä rakentaa Tap to Pay -sovelluksen iPhoneen?
Ei ilman hyväksyntöjä. Apple vaatii integraation tuetun maksupalveluntarjoajan kanssa sekä Tap to Pay on iPhone -käyttöoikeuden, jonka se myöntää tapauskohtaisesti, mitä seuraa sovelluksen arviointiprosessi.
Miten Tap to Pay sertifioidaan Androidilla?
Riippumattomat, PCI-hyväksytyt laboratoriot arvioivat maksujen vastaanottosovellukset PCI MPoC -standardia vasten, joka on korttialan turvallisuusstandardi maksupäätteinä toimiville puhelimille.
Onko Tap to Pay turvallinen?
Sertifioidut toteutukset ovat. iPhonessa tapahtumat salataan ja käsitellään laitteen Secure Element -turvasirulla; Androidilla MPoC-sertifioitujen ratkaisujen on täytettävä standardin turvallisuusvaatimukset.
Voiko tekoäly kirjoittaa Tap to Pay -sovelluksen puolestani?
Se voi kirjoittaa integraatiokoodin. Se ei kuitenkaan voi myöntää Applen käyttöoikeutta, läpäistä PCI-laboratorioarviointia tai allekirjoittaa sopimusta maksunvälittäjän kanssa – ja nämä esteet muodostavat suurimman osan projektista.
