Jak trudno jest stworzyć własną aplikację Tap to Pay? (Spróbowaliśmy)

Trudniejsze, niż sugerują broszury pakietów SDK, a trudność w większości nie tkwi w kodzie. Wdrożyliśmy Tap to Pay w aplikacji Final POS, więc ta odpowiedź wynika z praktyki, a nie z czytania dokumentacji. Jeśli chcesz stworzyć własną aplikację Tap to Pay, zaplanuj krótki projekt programistyczny opakowany w znacznie dłuższy projekt uzyskiwania pozwoleń: partnerstwo z operatorem płatności, ręczne nadanie uprawnień przez Apple lub ocenę laboratoryjną na Androidzie oraz weryfikację aplikacji – a to wszystko jeszcze przed pierwszą rzeczywistą płatnością zbliżeniową.

Szybkie zastrzeżenie: zasady platform i branży kart płatniczych często się zmieniają. Wszystkie poniższe informacje są dokładne na dzień publikacji, więc traktuj te szczegóły jako migawkę stanu faktycznego.

Co właściwie robi aplikacja Tap to Pay?

Tap to Pay zamienia sam telefon w czytnik kart. Bez terminala, bez przystawek: klient przykłada kartę zbliżeniową lub portfel w telefonie, taki jak Apple Pay lub Google Pay, bezpośrednio do urządzenia sprzedawcy, a płatność przechodzi przez chip NFC telefonu (krótkofalowe radio używane do komunikacji zbliżeniowej). Jeśli ta terminologia wydaje się niejasna, szczegółowo opisaliśmy różnicę między mobilnymi płatnościami zbliżeniowymi a Tap to Pay na urządzeniach mobilnych.

Oto pułapka. Odczytanie tagu NFC to rzeczywiście projekt na weekend; hobbystom zdarza się to bez przerwy. Odczytanie karty płatniczej to zupełnie inna dyscyplina. Karty posługują się standardem EMV (protokołem chipowym branży kart płatniczych), dane karty muszą być szyfrowane na całej trasie przesyłu, a dostęp do nich może mieć wyłącznie certyfikowane oprogramowanie.

Dlaczego nie możesz po prostu samodzielnie odczytać karty?

Ponieważ każda warstwa stosu technologicznego wymaga pozwolenia, zanim Twój kod będzie mógł zostać uruchomiony publicznie.

• Apple nie daje aplikacjom bezpośredniego dostępu do NFC na potrzeby płatności. Musisz korzystać z frameworku ProximityReader, który wymaga uprawnienia Tap to Pay on iPhone (specjalnego pozwolenia przyznawanego przez Apple indywidualnie dla każdego przypadku). Apple wymaga również integracji ze wspieranym dostawcą usług płatniczych, czyli PSP (firmą, która faktycznie przesyła pieniądze). PSP dostarcza certyfikowane konfiguracje czytnika ładowane na urządzenie sprzedawcy i bierze na siebie ciężar certyfikacji.

• Android daje programistom bardziej otwarty dostęp do NFC, ale aplikacja do akceptowania płatności i tak musi zostać oceniona przez niezależne laboratorium uznawane przez PCI pod kątem zgodności ze standardem PCI MPoC (zasadami bezpieczeństwa branży kart płatniczych dla telefonów działających jako terminale płatnicze).

• Pod obiema platformami potrzebujesz relacji z agentem rozliczeniowym: operatorem gotowym rozliczać środki dla Twoich sprzedawców, z uwzględnieniem zasad organizacji płatniczych.

Niczego z tego nie da się przeskoczyć, pisząc lepszy kod. To kwestia formalności, umów i kolejek do weryfikacji.

Jak wygląda ścieżka zatwierdzania na iPhonie?

Zgodnie z opublikowanymi wymogami Apple ścieżka wygląda następująco: posiadanie konta Apple Developer na poziomie organizacji (właściciel konta osobiście składa wniosek), partnerstwo ze wspieranym PSP w Twoich regionach, złożenie wniosku o uprawnienie, integracja API ProximityReader lub SDK Twojego PSP, przestrzeganie wytycznych projektowych Apple dotyczących ekranu płatności i przesłanie aplikacji do weryfikacji. Dokumentacja Apple wskazuje również, że funkcja ta działa tylko w obsługiwanych krajach i regionach, więc sama dostępność jest z góry określona dla poszczególnych rynków.

Przeczytaj tę listę jeszcze raz jako założyciel lub sprzedawca, a nie programista. Żaden z tych kroków nie brzmi „napisz funkcję”. Sama funkcja to ta łatwa część; uprawnienie to prawdziwa fosa.

Gdzie trafia praca, gdy płatność zbliżeniowa już działa?

Zatwierdzone zbliżenie daje Ci płatność, a nie punkt sprzedaży. W momencie, gdy pieniądze ruszają w drogę, wszystko wokół płatności musi być poprawne: koszyk, z którego jest rozliczana, podatki na paragonie, ścieżka zwrotu kosztów oraz raportowanie, które się uzgadnia (każdy dolar przypisany do sprzedaży, każdego dnia). Tę samą lukę zauważyliśmy, gdy sprawdzaliśmy, czy można zbudować POS za pomocą Lovable lub Replit: wygenerowanie interfejsu jest szybkie, ale to warstwa handlowa pod spodem pochłania najwięcej czasu.

Tap to Pay niesie ze sobą również własne specyficzne wyzwania operacyjne. W naszej implementacji sprzedaż musi być nabita na tym samym urządzeniu, które przyjmuje płatność zbliżeniową, i działa to tylko w aplikacji natywnej, nigdy w przeglądarce. Takich ograniczeń nie znajdziesz w żadnej broszurze. Odkrywasz je, obchodzisz programistycznie, a potem piszesz artykuł pomocy. A kiedy telefon na ladzie przestaje wystarczać, i tak stajesz przed prawdziwymi decyzjami sprzętowymi.

Jak trudno jest więc stworzyć własną aplikację Tap to Pay?

Trudne w specyficzny sposób: kodowanie to najmniejsza część, podczas gdy partnerstwo z operatorem, uprawnienia od Apple, certyfikacja laboratoryjna na Androidzie i weryfikacja aplikacji stanowią większość pracy, a żadna z tych rzeczy nie zależy od wysiłku programistycznego. Dla nas było to warte zachodu, ponieważ platforma POS rozkłada te koszty na wszystkich korzystających z niej sprzedawców. Tap to Pay to teraz przycisk płatności, który nasi sprzedawcy mogą po prostu włączyć, a przyjmowanie płatności Tap to Pay to pięciokrokowa rutyna przy ladzie. Jeśli płatności są Twoim produktem, ta ścieżka zdrowia to cena wejścia. Jeśli płatności to tylko sposób, w jaki otrzymujesz zapłatę, budowanie własnej aplikacji Tap to Pay nie ma sensu finansowego; gotowa wersja już istnieje w aplikacjach POS, a porównanie opłat to miejsce, gdzie kryje się prawdziwa różnica.

Złota zasada: jeśli funkcja wymaga czyjegoś pozwolenia, by istnieć, żaden sprytny kod tego nie przyspieszy.