Kor vanskeleg er det å byggje sin eigen Tap to Pay-app? (Vi prøvde)

Vanskelegare enn SDK-brosjyrane antydar, og utfordringa ligg stort sett ikkje i koden. Vi leverte Tap to Pay i Final POS-appen, så dette svaret kjem frå faktisk erfaring, ikkje frå å lese dokumentasjon. Viss du vil byggje din eigen tap to pay-app, må du planleggje for eit kort programvareprosjekt pakka inn i eit mykje lengre godkjenningsprosjekt: eit partnarskap med ein betalingsformidlar, eit manuelt løyve frå Apple eller ein laboratorieevaluering på Android, og ein app-revisjon, alt før di første live-tæpping.

Eit kjapt atterhald: Reglane for plattformer og kortbransjen endrar seg ofte. Alt nedanfor er nøyaktig på publiseringstidspunktet, så sjå på detaljane som eit augeblinksbilete.

Kva gjer ein tap to pay-app eigentleg?

Tap to pay gjer sjølve telefonen om til ein kortlesar. Ingen terminal, ingen dongle: Kunden tæppar eit kontaktlaust kort eller ein mobil lommebok som Apple Pay eller Google Pay direkte på eininga til forhandlaren, og betalinga går gjennom NFC-brikken i telefonen (kortrekkjeviddsradioen som blir brukt til kontaktlaus betaling). Viss terminologien kjennest forvirrande, har vi brote ned forskjellen mellom mobile tæppebetalingar og Tap to Pay på mobil.

Her er fella. Å lese ei NFC-brikke er faktisk eit helgeprosjekt; hobbyutviklarar gjer det heile tida. Å lese eit betalingskort er ein heilt annan sport. Kort snakkar EMV (kortbransjen sin brikkeprotokoll), kortdataa må vere krypterte ende-til-ende, og berre sertifisert programvare har lov til å røre dei.

Kvifor kan du ikkje berre lese kortet sjølv?

Fordi kvart lag i teknologistakken krev løyve før koden din får lov til å køyre offentleg.

• Apple gir ikkje appar direkte tilgang til NFC for betaling. Du må bruke deira ProximityReader-rammeverk, som ligg bak eit løyve for Tap to Pay på iPhone (ein spesiell tillating Apple gir i kvart enkelt tilfelle). Apple krev også at du integrerer med ein støtta betalingstenesteleverandør, eller PSP (selskapet som faktisk flyttar pengane). PSP-en leverer dei sertifiserte lesarkonfigurasjonane som blir lasta inn på eininga til forhandlaren, og ber sertifiseringsbøra.

• Android gir utviklarar meir open tilgang til NFC, men ein app for betalingsmottak må framleis evaluerast av eit uavhengig, PCI-godkjent laboratorium opp mot PCI MPoC-standarden (kortbransjen sine tryggleiksreglar for telefoner som fungerer som betalingsterminalar).

• Under begge plattformene treng du ein innløysingsavtale: ein betalingsformidlar som er viljug til å gjere opp pengar for forhandlarane dine, med kortnettverka sine reglar på kjøpet.

Ingenting av dette kan løysast berre ved å skrive betre kode. Det handlar om papirarbeid, kontraktar og godkjenningskøar.

Korleis ser godkjenningsvegen ut på iPhone?

I følgje Apple sine publiserte krav ser vegen slik ut: Du må ha ein Apple Developer-konto på organisasjonsnivå (kontohavaren må personleg sende inn førespurnaden), inngå partnarskap med ein støtta PSP for dine regionar, be om løyvet, integrere ProximityReader-API-et eller PSP-en sitt SDK, følgje Apple sine designretningslinjer for betalingsskjermen, og sende inn appen til vurdering. Apple sin dokumentasjon påpeikar også at funksjonen berre fungerer i støtta land og regionar, så sjølve tilgjengelegheita blir avgjord for deg, marknad for marknad.

Les den lista ein gong til som gründer eller forhandlar i staden for som utviklar. Ikkje eitt einaste steg handlar om å «skrive funksjonen». Sjølve funksjonen er den enkle delen; løyvet er vollgrava.

Kvar går arbeidet etter at tæppinga fungerer?

Ei godkjend tæpping gir deg ei betaling, ikkje ein POS. Med det same pengane flyttar på seg, må alt rundt tæppinga vere korrekt: handlekorga ho blir gjort opp mot, skattane på kvitteringa, refusjonsvegen og rapportering som stemmer (kvar krone kopla til eit sal, kvar dag). Vi fann det same gapet då vi undersøkte om du kan byggje ein POS med Lovable eller Replit: Å generere eit grensesnitt går raskt, men handelslaget under er det som et opp kalenderen.

Tap to pay fører også med seg sine eigne driftsmessige særheiter. I vår implementering må salet slåast inn på same eining som tek imot tæppinga, og det fungerer berre i den opphavlege appen, aldri i ein nettlesar. Slike avgrensingar står ikkje i nokon brosjyre. Du oppdagar dei, finn tekniske løysingar, og skriv deretter hjelpeartikkelen. Og når ein telefon på disken ikkje lenger er nok, er du uansett over på reelle maskinvareavgjerder.

Så, kor vanskeleg er det å byggje sin eigen tap to pay-app?

Vanskeleg på ein spesifikk måte: Kodinga er den minste biten, medan partnarskapet med betalingsformidlaren, Apple-løyvet, laboratoriesertifiseringa på Android og app-revisjonen utgjer hovuddelen – og ingen av dei reagerer på ekstra innsats frå utviklarane. For oss var det verdt det, fordi ein POS-plattform fordeler denne kostnaden på alle forhandlarane som brukar han. Tap to pay er no ein betalingsknapp forhandlarane våre slår på, og å ta imot ei Tap to Pay-betaling er ein rutine på fem steg ved disken. Viss betalingar er produktet ditt, er denne runden inngangsbilletten. Viss betalingar berre er måten du får betalt på, gir det inga økonomisk meining å byggje din eigen tap to pay-app; den ferdige versjonen finst allereie inni POS-appar, og gebyra er der den reelle samanlikninga ligg.

Tommelfingerregel: viss ein funksjon treng nokon andre sitt løyve for å eksistere, kan ingen mengd smart kode ta ein snarveg rundt det.