Hoe moeilijk is het om uw eigen Tap to Pay-app te bouwen? (We hebben het geprobeerd)

Moeilijker dan de SDK-brochures doen vermoeden, en de moeilijkheid zit hem meestal niet in de code. We hebben Tap to Pay uitgebracht in de Final POS-app, dus dit antwoord komt uit de praktijk, niet uit het lezen van documentatie. Als u uw eigen Tap to Pay-app wilt bouwen, houd dan rekening met een kort softwareproject verpakt in een veel langer goedkeuringstraject: een partnerschap met een betalingsverwerker, een handmatige entitlement van Apple of een laboratoriumevaluatie op Android, en een app-beoordeling, allemaal nog vóór uw eerste live betaling.

Een kleine waarschuwing: de regels van platforms en de kaartindustrie veranderen vaak. Alles hieronder is nauwkeurig op het moment van publicatie, dus beschouw de details als een momentopname.

Wat doet een Tap to Pay-app eigenlijk?

Tap to Pay verandert de telefoon zelf in de kaartlezer. Geen terminal, geen dongle: de klant tikt een contactloze kaart of een mobiele portemonnee zoals Apple Pay of Google Pay direct op het apparaat van de winkelier, en de betaling verloopt via de NFC-chip van de telefoon (de radio voor korte afstand die wordt gebruikt voor contactloos betalen). Als de terminologie wat verwarrend aanvoelt, hebben we het verschil tussen mobiele tikbetalingen en Tap to Pay op mobiel op een rijtje gezet.

Hier schuilt de valkuil. Het lezen van een NFC-tag is echt een weekendproject; hobbyisten doen het voortdurend. Het lezen van een betaalkaart is andere koek. Kaarten spreken EMV (het chipprotocol van de kaartindustrie), de kaartgegevens moeten end-to-end versleuteld blijven en alleen gecertificeerde software mag deze aanraken.

Waarom kunt u de kaart niet gewoon zelf lezen?

Omdat elke laag van de stack toestemming vereist voordat uw code in het openbaar mag worden uitgevoerd.

• Apple geeft apps geen directe toegang tot betalings-NFC. U moet het ProximityReader-framework gebruiken, dat achter een Tap to Pay on iPhone-entitlement zit (een speciale toestemming die Apple per geval verleent). Apple vereist ook dat u integreert met een ondersteunde betalingsdienstaanbieder, of PSP (het bedrijf dat daadwerkelijk het geld overboekt). De PSP levert de gecertificeerde lezerconfiguraties die op het apparaat van de winkelier worden geladen en draagt de certificeringslast.

• Android geeft ontwikkelaars meer open NFC-toegang, maar een app voor betalingsacceptatie moet nog steeds door een onafhankelijk, door PCI erkend laboratorium worden geëvalueerd aan de hand van de PCI MPoC-standaard (de beveiligingsregels van de kaartindustrie voor telefoons die als betalingsterminal fungeren).

• Onder beide platforms hebt u een acquiring-relatie nodig: een verwerker die bereid is geld af te wikkelen voor uw winkeliers, waarbij de regels van de kaartnetwerken van toepassing zijn.

Niets hiervan kan worden afgedwongen door betere code te schrijven. Het is papierwerk, contracten en beoordelingswachtrijen.

Hoe ziet het goedkeuringstraject eruit op iPhone?

Volgens de gepubliceerde vereisten van Apple verloopt het traject als volgt: zorg voor een Apple Developer-account op organisatieniveau (de accounthouder dient het verzoek persoonlijk in), werk samen met een ondersteunde PSP voor uw regio's, vraag de entitlement aan, integreer de ProximityReader-API of de SDK van uw PSP, volg de ontwerprichtlijnen van Apple voor het betalingsscherm en dien de app in ter beoordeling. De documentatie van Apple vermeldt ook dat de functie alleen werkt in ondersteunde landen en regio's, dus de beschikbaarheid zelf wordt markt per markt voor u bepaald.

Lees die lijst nog eens als oprichter of winkelier in plaats van als ontwikkelaar. Geen enkele stap ervan is "schrijf de functie". De functie is het makkelijke deel; de entitlement is de slotgracht.

Waar gaat het werk naartoe nadat de betaling werkt?

Een goedgekeurde tik geeft u een betaling, geen verkooppunt (POS). Op het moment dat er geld wordt overgemaakt, moet alles rondom de tik kloppen: het winkelwagentje waarmee wordt afgerekend, de btw op de bon, het terugbetalingstraject en de rapportage die aansluit (elke dollar gekoppeld aan een verkoop, elke dag weer). We stuitten op dezelfde kloof toen we keken naar of je een POS kunt bouwen met Lovable of Replit: het genereren van een interface gaat snel, maar de onderliggende handelslaag is wat de meeste tijd kost.

Tap to Pay brengt ook eigen operationele eigenaardigheden met zich mee. In onze implementatie moet de verkoop worden aangeslagen op hetzelfde apparaat dat de betaling ontvangt, en het werkt alleen in de native app, nooit in een browser. Dit soort beperkingen staat in geen enkele brochure. Je ontdekt ze, bouwt er oplossingen voor en schrijft vervolgens het hulpartikel. En wanneer een telefoon op de toonbank niet meer genoeg is, kom je sowieso uit bij echte hardwarebeslissingen.

Dus, hoe moeilijk is het om uw eigen Tap to Pay-app te bouwen?

Moeilijk op een specifieke manier: het coderen is het kleinste deel, terwijl het partnerschap met de verwerker, de Apple-entitlement, de laboratoriumcertificering op Android en de app-beoordeling het grootste deel uitmaken, en geen daarvan reageert op technische inspanningen. Voor ons was het de moeite waard, omdat een POS-platform die kosten spreidt over elke winkelier die er gebruik van maakt. Tap to Pay is nu een betaalknop die onze winkeliers inschakelen, en een Tap to Pay-betaling aannemen is een routine van vijf stappen aan de toonbank. Als betalingen uw product zijn, is deze beproeving de toegangsprijs. Als betalingen gewoon de manier zijn waarop u betaald krijgt, heeft het bouwen van uw eigen Tap to Pay-app financieel geen zin; de voltooide versie bestaat al binnen POS-apps, en de tarieven zijn waar de echte vergelijking ligt.

Vuistregel: als een functie de toestemming van iemand anders nodig heeft om te bestaan, kan geen enkele hoeveelheid slimme code dat omzeilen.