Hur svårt är det att bygga en egen Tap to Pay-app? (We Tried)

Svårare än vad SDK-broschyrerna antyder, och svårigheten ligger oftast inte i koden. Vi lanserade Tap to Pay i Final POS-appen, så det här svaret kommer från att faktiskt ha gjort det, inte från att ha läst dokumentation. Om du vill bygga en egen Tap to Pay-app bör du planera för ett kort mjukvaruprojekt insvept i ett mycket längre tillståndsprojekt: ett partnerskap med en betalningsförmedlare, ett manuellt godkännande (entitlement) från Apple eller en laboratorieutvärdering på Android, samt en appgranskning – allt innan din första live-blippning.

En snabb varning: plattforms- och kortbranschregler ändras ofta. Allt nedan är korrekt vid tidpunkten för publicering, så se detaljerna som en ögonblicksbild.

Vad gör en Tap to Pay-app egentligen?

Tap to Pay förvandlar själva telefonen till en kortläsare. Ingen terminal, ingen dongel: kunden blippar ett kontaktlöst kort eller en mobil plånbok som Apple Pay eller Google Pay direkt på handlarens enhet, och betalningen körs via telefonens NFC-chip (den korthållsradio som används för kontaktlösa betalningar). Om terminologin känns luddig har vi brutit ner skillnaden mellan mobila blippbetalningar och Tap to Pay på mobilen.

Här är fällan. Att läsa en NFC-tagg är verkligen ett helgprojekt; hobbyister gör det hela tiden. Att läsa ett betalkort är en helt annan sport. Kort kommunicerar via EMV (kortbranschens chipprotokoll), kortdatan måste förbli krypterad hela vägen (end-to-end), och endast certifierad programvara får hantera den.

Varför kan du inte bara läsa kortet själv?

Eftersom varje lager i teknikstacken kräver tillstånd innan din kod får köras offentligt.

• Apple ger inte appar direktåtkomst till NFC för betalningar. Du måste använda deras ProximityReader-ramverk, som ligger bakom ett Tap to Pay on iPhone-godkännande (entitlement) (ett särskilt tillstånd som Apple beviljar från fall till fall). Apple kräver också att du samarbetar med en betaltjänstleverantör som stöds, eller PSP (företaget som faktiskt flyttar pengarna). Denna PSP tillhandahåller de certifierade läsarkonfigurationerna som laddas på handlarens enhet och bär certifieringsbördan.

• Android ger utvecklare mer öppen NFC-åtkomst, men en app för betalningsmottagning måste ändå utvärderas av ett oberoende PCI-erkänt laboratorium mot PCI MPoC-standarden (kortbranschens säkerhetsregler för telefoner som fungerar som betalterminaler).

• Under båda plattformarna behöver du en inlösenrelation: en inlösare som är villig att avveckla pengar för dina handlare, med kortnätverkens regler på köpet.

Inget av detta kan forceras genom att skriva bättre kod. Det handlar om pappersarbete, kontrakt och granskningsköer.

Hur ser godkännandeprocessen ut på iPhone?

Enligt Apples publicerade krav ser processen ut så här: ha ett Apple Developer-konto på organisationsnivå (kontoinnehavaren skickar personligen in begäran), samarbeta med en PSP som stöds i dina regioner, begär godkännandet (entitlement), integrera ProximityReader-API:et eller din PSP:s SDK, följ Apples designriktlinjer för betalningsskärmen och skicka in appen för granskning. Apples dokumentation anger också att funktionen endast fungerar i länder och regioner som stöds, så själva tillgängligheten bestäms åt dig, marknad för marknad.

Läs den listan igen som grundare eller handlare snarare än som utvecklare. Inte ett enda steg handlar om att ”skriva funktionen”. Funktionen är den enkla delen; godkännandet (entitlement) är vallgraven.

Var hamnar arbetet efter att blippandet fungerar?

Ett godkänt blipp ger dig en betalning, inte ett kassasystem. I samma ögonblick som pengar flyttas måste allt runt omkring stämma: varukorgen den matchas mot, skatterna på kvittot, återbetalningsvägen och rapporteringen som stämmer av (varje krona matchad mot en försäljning, varje dag). Vi upptäckte samma glapp när vi undersökte om man kan bygga ett POS med Lovable eller Replit: att generera ett gränssnitt går snabbt, men det är handelslagret under huven som äter upp kalendern.

Tap to Pay har också sina egna operativa egenheter. I vår implementering måste försäljningen slås in på samma enhet som tar emot blippet, och det fungerar bara i den interna appen, aldrig i en webbläsare. Sådana begränsningar syns inte i några broschyrer. Du upptäcker dem, bygger runt dem och skriver sedan hjälpartikeln. Och när en telefon på disken inte längre räcker, hamnar du ändå i riktiga hårdvarubeslut.

Så, hur svårt är det att bygga en egen Tap to Pay-app?

Svårt på ett specifikt sätt: kodningen är den minsta delen, medan partnerskapet med betalningsförmedlaren, Apples godkännande, laboratoriecertifieringen på Android och appgranskningen utgör merparten – och inget av detta påverkas av hur mycket du än kodar.

För oss var det värt det, eftersom en POS-plattform fördelar den kostnaden på alla handlare som använder den. Tap to Pay är nu en betalknapp som våra handlare bara slår på, och att ta emot en Tap to Pay-betalning är en rutin i fem steg vid disken. Om betalningar är din produkt är denna utmaning inträdesbiljetten. Om betalningar bara är sättet du får betalt på, är det ekonomiskt oförsvarbart att bygga en egen Tap to Pay-app; den färdiga versionen finns redan i POS-appar, och avgifterna är där den verkliga jämförelsen ligger.

Tumregel: om en funktion kräver någon annans tillstånd för att existera, kan ingen mängd smart kod gena förbi det.