Wie schwer ist es, eine eigene Tap-to-Pay-App zu entwickeln? (Wir haben es versucht)

Schwerer, als die SDK-Broschüren vermuten lassen, und die Schwierigkeit liegt meistens nicht im Code. Wir haben Tap to Pay in der Final POS-App eingeführt. Diese Antwort basiert also auf praktischer Erfahrung, nicht auf dem Lesen von Dokumentationen. Wenn Sie Ihre eigene Tap-to-Pay-App entwickeln möchten, planen Sie ein kurzes Softwareprojekt ein, das in ein viel längeres Genehmigungsprojekt verpackt ist: eine Partnerschaft mit einem Zahlungsabwickler, eine manuelle Berechtigung (Entitlement) von Apple oder eine Laborbewertung für Android sowie eine App-Überprüfung – und das alles vor der ersten echten Zahlung.

Ein kleiner Vorbehalt: Die Regeln der Plattformen und der Kartenbranche ändern sich häufig. Alles Folgende entspricht dem Stand bei Veröffentlichung, betrachten Sie die Details also als Momentaufnahme.

Was macht eine Tap-to-Pay-App eigentlich?

Tap to Pay verwandelt das Telefon selbst in ein Kartenlesegerät. Kein Terminal, kein Dongle: Der Kunde hält eine kontaktlose Karte oder eine mobile Geldbörse wie Apple Pay oder Google Pay direkt an das Gerät des Händlers, und die Zahlung läuft über den NFC-Chip des Telefons (die Nahbereichs-Funktechnik für kontaktlose Zahlungen). Wenn Ihnen die Terminologie unklar erscheint, haben wir den Unterschied zwischen mobilen Tap-Zahlungen und Tap to Pay auf Mobilgeräten aufgeschlüsselt.

Hier liegt die Falle. Das Auslesen eines NFC-Tags ist wirklich ein Wochenendprojekt; Bastler tun das ständig. Das Auslesen einer Zahlungskarte ist eine ganz andere Liga. Karten sprechen EMV (das Chip-Protokoll der Kartenindustrie), die Kartendaten müssen durchgehend verschlüsselt bleiben und nur zertifizierte Software darf damit in Berührung kommen.

Warum kann man die Karte nicht einfach selbst auslesen?

Weil jede Ebene des Stacks eine Genehmigung erfordert, bevor Ihr Code öffentlich ausgeführt werden darf.

• Apple gewährt Apps keinen direkten Zugriff auf NFC für Zahlungen. Sie müssen das ProximityReader-Framework verwenden, das hinter einer Tap to Pay on iPhone-Berechtigung (einer speziellen Berechtigung, die Apple von Fall zu Fall erteilt) liegt. Apple verlangt außerdem die Integration mit einem unterstützten Zahlungsdienstleister oder PSP (dem Unternehmen, das das Geld tatsächlich bewegt). Der PSP stellt die zertifizierten Leserkonfigurationen bereit, die auf das Gerät des Händlers geladen werden, und trägt die Last der Zertifizierung.

• Android gewährt Entwicklern einen offeneren NFC-Zugriff, aber eine Zahlungsakzeptanz-App muss dennoch von einem unabhängigen, von der PCI anerkannten Labor gemäß dem PCI MPoC-Standard (den Sicherheitsregeln der Kartenindustrie für Telefone, die als Zahlungsterminals fungieren) bewertet werden.

• Unter beiden Plattformen benötigen Sie eine Acquiring-Beziehung: einen Abwickler, der bereit ist, das Geld für Ihre Händler abzurechnen, wobei die Regeln der Kartennetzwerke gelten.

Nichts davon lässt sich durch besseren Code erzwingen. Es ist Papierkram, Verträge und Warteschlangen für Prüfungen.

Wie sieht der Genehmigungsweg auf dem iPhone aus?

Gemäß den veröffentlichten Anforderungen von Apple sieht der Weg wie folgt aus: Sie müssen ein Apple Developer-Konto auf Organisationsebene besitzen (der Kontoinhaber stellt den Antrag persönlich), mit einem unterstützten PSP für Ihre Regionen zusammenarbeiten, die Berechtigung beantragen, die ProximityReader-API oder das SDK Ihres PSP integrieren, die Design-Richtlinien von Apple für den Zahlungsbildschirm befolgen und die App zur Überprüfung einreichen. In der Dokumentation von Apple wird außerdem darauf hingewiesen, dass die Funktion nur in unterstützten Ländern und Regionen funktioniert, sodass die Verfügbarkeit selbst von Markt zu Markt für Sie vorgegeben ist.

Lesen Sie diese Liste noch einmal aus der Sicht eines Gründers oder Händlers statt aus der eines Entwicklers. Kein einziger Schritt davon lautet „Funktion programmieren“. Die Funktion ist der einfache Teil; die Berechtigung ist der Burggraben.

Wohin fließt die Arbeit, nachdem das kontaktlose Bezahlen funktioniert?

Eine genehmigte kontaktlose Zahlung liefert Ihnen eine Zahlung, aber kein Kassensystem. Sobald Geld fließt, muss alles um die Zahlung herum stimmen: der Warenkorb, gegen den abgerechnet wird, die Steuern auf dem Beleg, der Erstattungsweg und Berichte, die übereinstimmen (jeder Dollar muss täglich einem Verkauf zugeordnet werden). Wir haben dieselbe Lücke festgestellt, als wir untersucht haben, ob man ein POS mit Lovable oder Replit bauen kann: Eine Benutzeroberfläche ist schnell erstellt, aber die darunter liegende Handelsebene ist das, was Zeit kostet.

Tap to Pay bringt auch eigene betriebliche Besonderheiten mit sich. In unserer Implementierung muss der Verkauf auf demselben Gerät erfasst werden, das die kontaktlose Zahlung entgegennimmt, und es funktioniert nur in der nativen App, niemals im Browser. Solche Einschränkungen stehen in keiner Broschüre. Man entdeckt sie, findet technische Lösungen und schreibt dann den Hilfeartikel. Und wenn ein Telefon auf dem Tresen nicht mehr ausreicht, steht man ohnehin vor echten Hardware-Entscheidungen.

Wie schwer ist es also, eine eigene Tap-to-Pay-App zu entwickeln?

Auf eine ganz bestimmte Art schwer: Das Codieren ist der kleinste Teil, während die Partnerschaft mit dem Abwickler, die Apple-Berechtigung, die Laborzertifizierung für Android und die App-Überprüfung den Großteil ausmachen – und nichts davon lässt sich durch Entwicklungsaufwand beschleunigen. Für uns hat es sich gelohnt, weil eine POS-Plattform diese Kosten auf alle Händler verteilt, die sie nutzen. Tap to Pay ist jetzt eine Bezahl-Schaltfläche, die unsere Händler einfach aktivieren können, und eine Tap-to-Pay-Zahlung anzunehmen ist eine Routine in fünf Schritten am Tresen. Wenn Zahlungen Ihr Produkt sind, ist dieser Spießrutenlauf der Preis für den Markteintritt. Wenn Zahlungen nur der Weg sind, wie Sie bezahlt werden, macht die Entwicklung einer eigenen Tap-to-Pay-App finanziell keinen Sinn; die fertige Version existiert bereits in POS-Apps, und bei den Gebühren liegt der eigentliche Vergleich.

Faustregel: Wenn eine Funktion die Genehmigung eines Dritten erfordert, um zu existieren, lässt sie sich durch noch so cleveren Code nicht abkürzen.