Hvor vanskelig er det å bygge sin egen Tap to Pay-app? (We prøvde)

Vanskeligere enn det SDK-brosjyrene antyder, og utfordringen ligger stort sett ikke i koden. Vi lanserte Tap to Pay i Final POS-appen, so dette svaret kommer fra faktisk erfaring, ikke fra å lese dokumentasjon. Hvis du vil bygge din egen app for kontaktløs betaling, må du planlegge for et kort programvareprosjekt pakket inn i et mye lengre godkjenningsprosjekt: et partnerskap med en betalingsformidler, en manuell godkjenning (entitlement) fra Apple eller en laboratorieevaluering på Android, og en app-gjennomgang, alt før din første reelle tæpping.

Et lite forbehold: Reglene for plattformer og kortbransjen endres ofte. Alt nedenfor er nøyaktig på publiseringstidspunktet, så se på detaljene som et øyeblikksbilde.

Hva gjør egentlig en app for kontaktløs betaling?

Kontaktløs betaling (tap to pay) forvandler selve telefonen til en kortleser. Ingen terminal, ingen dongle: kunden tæpper et kontaktløst kort eller en mobil lommebok som Apple Pay eller Google Pay direkte på forhandlerens enhet, og betalingen går gjennom telefonens NFC-brikke (radioen med kort rekkevidde som brukes til kontaktløs kommunikasjon). Hvis terminologien føles forvirrende, har vi forklart forskjellen mellom mobile tæppebetalinger og Tap to Pay på mobil.

Her er fellen. Å lese en NFC-brikke er egentlig et helgeprosjekt; hobbyister gjør det hele tiden. Å lese et betalingskort er en helt annen sport. Kort snakker EMV (kortbransjens brikkeprotokoll), kortdataene må forbli kryptert ende-til-ende, og bare sertifisert programvare har lov til å berøre dem.

Hvorfor kan du ikke bare lese kortet selv?

Fordi hvert lag i teknologistakken krever tillatelse før koden din får lov til å kjøre offentlig.

• Apple gir ikke apper direkte tilgang til NFC for betaling. Du må bruke deres ProximityReader-rammeverk, som ligger bak en Tap to Pay on iPhone-godkjenning (en spesiell tillatelse Apple innvilger fra sak til sak). Apple krever også at du integrerer med en støttet betalingstjenesteleverandør, eller PSP (selskapet som faktisk flytter pengene). PSP-en leverer de sertifiserte leserkonfigurasjonene som lastes inn på forhandlerens enhet, og bærer sertifiseringsbyrden.

• Android gir utviklere mer åpen NFC-tilgang, men en app for betalingsmottak må likevel evalueres av et uavhengig PCI-godkjent laboratorium opp mot PCI MPoC-standarden (kortbransjens sikkerhetsregler for telefoner som fungerer som betalingsterminaler).

• Under begge plattformene trenger du en innløseravtale: en betalingsformidler som er villig til å gjøre opp penger for forhandlerne dine, i tråd med kortnettverkets regler.

Ingenting av dette kan løses ved å skrive bedre kode. Det handler om papirarbeid, kontrakter og godkjenningskøer.

Hvordan ser godkjenningsprosessen ut på iPhone?

I henhold til Apples publiserte krav ser prosessen slik ut: Ha en Apple Developer-konto på organisasjonsnivå (kontoeieren må sende inn forespørselen personlig), samarbeid med en støttet PSP for dine regioner, be om godkjenning (entitlement), integrer ProximityReader-API-et eller PSP-ens SDK, følg Apples retningslinjer for design av betalingsskjermen, og send inn appen til vurdering. Apples dokumentasjon påpeker også at funksjonen bare fungerer i støttede land og regioner, så selve tilgjengeligheten er bestemt for deg, marked for marked.

Les den listen på nytt som gründer eller forhandler i stedet for som utvikler. Ikke ett eneste steg handler om å «skrive funksjonen». Funksjonen er den enkle delen; godkjenningen er vollgraven.

Hvor havner arbeidet etter at tæppingen fungerer?

En godkjent tæpping gir deg en betaling, ikke et salgspunkt (POS). I det øyeblikket pengene flyttes, må alt rundt tæppingen være riktig: handlekurven den gjøres opp mot, avgiftene på kvitteringen, refusjonsveien og rapportering som avstemmes (hver krone matchet mot et salg, hver dag). Vi oppdaget det samme gapet da vi undersøkte om du kan bygge en POS med Lovable eller Replit: å generere et grensesnitt går raskt, men det er handelslaget under som spiser opp kalenderen.

Kontaktløs betaling bringer også med seg sine egne operasjonelle særegenheter. I vår implementering må salget slås inn på samme enhet som tar imot tæppingen, og det fungerer bare i den opprinnelige appen, aldri i en nettleser. Slike begrensninger står ikke i noen brosjyre. Du oppdager dem, finner tekniske løsninger, og skriver deretter hjelpeartikkelen. Og når en telefon på disken ikke lenger er nok, må du uansett ta reelle maskinvarebeslutninger.

Så, hvor vanskelig er det å bygge sin egen app for kontaktløs betaling?

Vanskelig på en helt spesiell måte: kodingen er den minste biten, mens partnerskapet med betalingsformidleren, Apple-godkjenningen, laboratoriesertifiseringen på Android og app-gjennomgangen utgjør brorparten – og ingen av dem påvirkes av ren ingeniørinnsats. For oss var det verdt det, fordi en POS plattform fordeler denne kostnaden på alle forhandlere som bruker den. Kontaktløs betaling er nå en betalingsknapp forhandlerne våre slår på, og å ta imot en Tap to Pay-betaling er en rutine på fem trinn ved disken. Hvis betalinger er produktet ditt, er dette nåløyet inngangsbilletten. Hvis betalinger bare er måten du får betalt på, gir det ingen økonomisk mening å bygge din egen app; den ferdige versjonen finnes allerede i POS-apper, og gebyrene er der den virkelige sammenligningen ligger.

Tommelfingerregel: hvis en funksjon trenger noen andres tillatelse for å eksistere, finnes det ingen mengde smart kode som kan ta en snarvei rundt det.