Hvor svært er det at bygge sin egen Tap to Pay-app? (Vi prøvede)

Sværere end SDK-brochurerne antyder, og vanskeligheden ligger for det meste ikke i koden. Vi lancerede Tap to Pay i Final POS-appen, så dette svar kommer af at have gjort det, ikke af at have læst dokumentation. Hvis du vil bygge din egen Tap to Pay-app, skal du forberede dig på et kortvarigt softwareprojekt pakket ind i et meget længere godkendelsesprojekt: et partnerskab med en betalingsudbyder, en manuel godkendelse (entitlement) fra Apple eller en laboratorieevaluering på Android samt en app-gennemgang – alt sammen før din første rigtige betaling.

Et lille forbehold: Platform- og kortbranche-regler ændres ofte. Alt nedenfor er nøjagtigt på udgivelsestidspunktet, så betragt de specifikke detaljer som et øjebliksbillede.

Hvad gør en Tap to Pay-app egentlig?

Tap to Pay forvandler selve telefonen til en kortlæser. Ingen terminal, ingen dongle: Kunden bipper et kontaktløst kort eller en mobilpung som Apple Pay eller Google Pay direkte på forhandlerens enhed, og betalingen kører gennem telefonens NFC-chip (den kortrækkende radio, der bruges til kontaktløs betaling). Hvis terminologien føles svær at gribe om, har vi opdelt forskellen mellem mobile kontaktløse betalinger og Tap to Pay på mobilen.

Her er fælden. At aflæse et NFC-tag er vitterligt et weekendprojekt; det gør hobbyfolk hele tiden. At aflæse et betalingskort er en helt anden disciplin. Kort taler EMV (kortbranchens chipprotokol), kortdataene skal forblive krypteret hele vejen, og kun certificeret software må røre ved dem.

Hvorfor kan du ikke bare selv aflæse kortet?

Fordi hvert lag i systemet kræver tilladelse, før din kode må køre offentligt.

• Apple giver ikke apps direkte adgang til betalings-NFC. Du skal bruge deres ProximityReader-framework, som ligger bag en Tap to Pay on iPhone-godkendelse (en særlig tilladelse, Apple giver fra sag til sag). Apple kræver også, at du integrerer med en understøttet betalingsudbyder, eller PSP (virksomheden, der rent faktisk flytter pengene). Denne PSP leverer de certificerede læserkonfigurationer, der indlæses på forhandlerens enhed, og bærer certificeringsbyrden.

• Android giver udviklere more åben NFC-adgang, men en app til betalingsmodtagelse skal stadig evalueres af et uafhængigt PCI-anerkendt laboratorium i forhold til PCI MPoC-standarden (kortbranchens sikkerhedsregler for telefoner, der fungerer som betalingsterminaler).

• Under begge platforme har du brug for en indløsningsaftale: en indløser, der er villig til at afregne penge for dine forhandlere, underlagt kortnetværkenes regler.

Intet af dette kan gennemtvinges ved at skrive bedre kode. Det handler om papirarbejde, kontrakter og godkendelseskøer.

Hvordan ser godkendelsesprocessen ud på iPhone?

Ifølge Apples offentliggjorte krav ser processen således ud: Du skal have en Apple Developer-konto på organisationsniveau (kontoholderen skal personligt indsende anmodningen), samarbejde med en understøttet PSP i dine regioner, anmode om godkendelsen (entitlement), integrere ProximityReader-API'et eller din PSP's SDK, følge Apples designretningslinjer for betalingsskærmen og indsende appen til godkendelse. Apples dokumentation bemærker også, at funktionen kun virker i understøttede lande og regioner, så selve tilgængeligheden er bestemt på forhånd for dig, marked for marked.

Læs den liste igen som stifter eller forhandler i stedet for som udvikler. Ikke ét eneste trin handler om at "skrive funktionen". Funktionen er den nemme del; godkendelsen er voldgraven.

Hvor ligger arbejdet, efter selve betalingen virker?

Et godkendt bip giver dig en betaling, ikke et point of sale. I det øjeblik pengene flyttes, skal alt omkring betalingen være korrekt: indkøbskurven, der afregnes mod, momsen på kvitteringen, refusionsvejen og en afstemt rapportering (hver dollar matchet med et salg, hver dag). Vi fandt det samme hul, da vi undersøgte, om man kan bygge et POS med Lovable eller Replit: Det går hurtigt at generere en grænseflade, men det er handelslaget nedenunder, der æder kalenderen.

Tap to Pay bringer også sine egne operationelle særheder med sig. I vores implementering skal salget slås op på den samme enhed, som modtager betalingen, og det fungerer kun i den oprindelige app, aldrig i en browser. Begrænsninger som disse står ikke i nogen brochure. Du opdager dem, finder tekniske løsninger og skriver derefter hjælpeartiklen. Og når en telefon på disken ikke længere er nok, står du alligevel over for reelle hardwarebeslutninger.

Så hvor svært er det at bygge sin egen Tap to Pay-app?

Svært på en specifik måde: Kodningen er den mindste del, mens partnerskabet med betalingsudbyderen, Apples godkendelse, laboratoriecertificeringen på Android og app-gennemgangen udgør størstedelen, og ingen af delene påvirkes af den tekniske indsats. For os var det det værd, fordi en POS platform fordeler denne omkostning på alle de forhandlere, der bruger den. Tap to Pay er nu en betalingsknap, vores forhandlere kan slå til, og at tage en Tap to Pay-betaling er en rutine på fem trin ved disken. Hvis betalinger er dit produkt, er denne udfordring adgangsbilletten. Hvis betalinger blot er måden, du får løn på, giver det ingen økonomisk mening at bygge din egen Tap to Pay-app; den færdige version findes allerede i POS-apps, og gebyrerne er der, hvor den reelle sammenligning ligger.

Tommelfingerregel: Hvis en funktion kræver en andens tilladelse for at eksistere, kan ingen mængde smart kode skyde genvej.