Cât de greu este să îți construiești propria aplicație Tap to Pay? (Noi am încercat)

Mai greu decât sugerează broșurile SDK-urilor, iar dificultatea nu ține în principal de cod. Am lansat Tap to Pay în aplicația Final POS, așa că acest răspuns vine din experiență directă, nu din citirea documentației. Dacă vrei să îți construiești propria aplicație tap to pay, planifică un proiect software scurt, învelit într-un proiect de autorizare mult mai lung: un parteneriat cu un procesator de plăți, o autorizație manuală de la Apple sau o evaluare de laborator pe Android și o revizuire a aplicației, toate acestea înainte de prima plată reală prin atingere.

O scurtă precizare: regulile platformelor și ale industriei cardurilor se schimbă des. Tot ce este scris mai jos este corect la data publicării, așa că tratează detaliile ca pe o imagine de moment.

Ce face de fapt o aplicație tap to pay?

Tap to pay transformă telefonul în sine într-un cititor de carduri. Fără terminal, fără dongle: clientul apropie un card contactless sau un portofel digital de pe telefon, cum ar fi Apple Pay sau Google Pay, direct de dispozitivul comerciantului, iar plata se realizează prin intermediul cipului NFC al telefonului (tehnologia radio pe distanțe scurte utilizată pentru plăți contactless). Dacă terminologia ți se pare ambiguă, am explicat pe larg diferența dintre plățile mobile prin atingere și Tap to Pay pe mobil.

Iată capcana. Citirea unei etichete NFC este într-adevăr un proiect de weekend; pasionații fac asta în mod constant. Citirea unui card de plată este însă un alt sport. Cardurile folosesc EMV (protocolul de cip al industriei cardurilor), datele cardului trebuie să rămână criptate cap-la-cap și doar software-ul certificat are voie să le acceseze.

De ce nu poți citi pur și simplu cardul singur?

Deoarece fiecare strat al sistemului necesită permisiune înainte ca codul tău să poată rula în mod public.

• Apple nu oferă aplicațiilor acces direct la NFC-ul de plată. Trebuie să folosești framework-ul său ProximityReader, care se află în spatele unei autorizații Tap to Pay pe iPhone (o permisiune specială pe care Apple o acordă de la caz la caz). De asemenea, Apple îți cere să te integrezi cu un furnizor de servicii de plată acceptat, sau PSP (compania care mută efectiv banii). PSP-ul furnizează configurațiile certificate de cititor încărcate pe dispozitivul comerciantului și preia povara certificării.

• Android oferă dezvoltatorilor un acces NFC mai deschis, dar o aplicație de acceptare a plăților trebuie totuși să fie evaluată de un laborator independent recunoscut de PCI în raport cu standardul PCI MPoC (regulile de securitate ale industriei cardurilor pentru telefoanele care funcționează ca terminale de plată).

• Sub ambele platforme, ai nevoie de o relație de acceptare (acquiring): un procesator dispus să deconteze banii pentru comercianții tăi, respectând în același timp regulile rețelelor de carduri.

Nimic din toate acestea nu poate fi rezolvat prin forță brută scriind un cod mai bun. Este vorba despre documente, contracte și cozi de așteptare pentru revizuire.

Cum arată procesul de aprobare pe iPhone?

Conform cerințelor publicate de Apple, procesul decurge astfel: trebuie să deții un cont de dezvoltator Apple la nivel de organizație (titularul contului depune personal cererea), să colaborezi cu un PSP acceptat pentru regiunile tale, să soliciți autorizația, să integrezi API-ul ProximityReader sau SDK-ul PSP-ului tău, să urmezi ghidurile de design Apple pentru ecranul de plată și să trimiți aplicația spre revizuire. Documentația Apple menționează, de asemenea, că funcția este disponibilă doar în țările și regiunile acceptate, astfel încât disponibilitatea în sine este decisă pentru tine, piață cu piață.

Citește din nou această listă ca fondator sau comerciant, nu ca dezvoltator. Niciun pas nu înseamnă „scrie funcționalitatea”. Funcționalitatea este partea ușoară; autorizația este bariera de netrecut.

Unde se îndreaptă efortul după ce plata prin atingere funcționează?

O plată prin atingere aprobată îți oferă o tranzacție, nu un punct de vânzare. În momentul în care banii se mișcă, totul în jurul plății trebuie să fie corect: coșul de cumpărături pe baza căruia se decontează, taxele de pe bon, fluxul de rambursare și raportarea care se reconciliază (fiecare leu asociat unei vânzări, în fiecare zi). Am descoperit aceeași lacună când am analizat dacă poți construi un POS cu Lovable sau Replit: generarea unei interfețe este rapidă, dar stratul comercial de dedesubt este cel care consumă cel mai mult timp.

Tap to pay aduce, de asemenea, propriile sale particularități operaționale. În implementarea noastră, vânzarea trebuie înregistrată pe același dispozitiv care preia plata prin atingere și funcționează doar în aplicația nativă, niciodată într-un browser. Astfel de constrângeri nu apar în nicio broșură. Le descoperi, găsești soluții tehnice, apoi scrii articolul de ajutor. Iar când un telefon pe tejghea nu mai este suficient, ajungi oricum la decizii reale privind echipamentele hardware.

Deci, cât de greu este să îți construiești propria aplicație tap to pay?

Greu într-un mod specific: scrierea codului este cea mai mică parte, în timp ce parteneriatul cu procesatorul, autorizația Apple, certificarea de laborator pe Android și revizuirea aplicației reprezintă cea mai mare parte, iar niciuna dintre acestea nu depinde de efortul de programare. Pentru noi a meritat, deoarece o platformă POS împarte acest cost la fiecare comerciant care o folosește. Tap to pay este acum un buton de finalizare a plății pe care comercianții noștri îl activează, iar acceptarea unei plăți Tap to Pay este o rutină de tejghea în cinci pași. Dacă plățile sunt produsul tău, acest parcurs dificil este prețul de intrare. Dacă plățile sunt doar modul în care ești plătit, construirea propriei aplicații tap to pay nu are sens din punct de vedere financiar; versiunea finalizată există deja în aplicațiile POS, iar comisioanele sunt cele care contează cu adevărat în comparație.

Regula generală: dacă o funcționalitate are nevoie de permisiunea altcuiva pentru a exista, niciun cod ingenios nu o poate scurta.