Quanto è difficile creare la propria app Tap to Pay? (Ci abbiamo provato)

Più difficile di quanto suggeriscano gli opuscoli degli SDK, e la difficoltà non risiede principalmente nel codice. Abbiamo integrato il Tap to Pay nell'app Final POS, quindi questa risposta deriva dall'esperienza diretta, non dalla lettura della documentazione. Se vuoi creare la tua app tap to pay, pianifica un breve progetto software racchiuso all'interno di un progetto di autorizzazione molto più lungo: una partnership con un processore di pagamento, un'abilitazione manuale da parte di Apple o una valutazione di laboratorio su Android e la revisione dell'app, il tutto prima del primo pagamento effettivo.

Una rapida avvertenza: le regole delle piattaforme e del settore delle carte cambiano spesso. Tutto ciò che segue è accurato al momento della pubblicazione, quindi considera i dettagli come un'istantanea del momento.

Cosa fa effettivamente un'app tap to pay?

Il tap to pay trasforma il telefono stesso in un lettore di carte. Nessun terminale, nessun dongle: il cliente avvicina una carta contactless o un portafoglio digitale come Apple Pay o Google Pay direttamente al dispositivo del commerciante, e il pagamento viene elaborato tramite il chip NFC del telefono (la radio a corto raggio utilizzata per i pagamenti contactless). Se la terminologia ti sembra complessa, abbiamo analizzato la differenza tra i pagamenti mobile tap e il Tap to Pay su dispositivi mobili.

Ecco la trappola. Leggere un tag NFC è davvero un progetto da fine settimana; gli hobbisti lo fanno continuamente. Leggere una carta di pagamento è tutt'altra cosa. Le carte parlano il protocollo EMV (il protocollo chip del settore delle carte), i dati della carta devono rimanere crittografati end-to-end e solo il software certificato è autorizzato a gestirli.

Perché non puoi semplicemente leggere la carta da solo?

Perché ogni livello dello stack richiede un'autorizzazione prima che il tuo codice possa essere eseguito pubblicamente.

• Apple non concede alle app l'accesso diretto all'NFC per i pagamenti. Devi utilizzare il suo framework ProximityReader, protetto da un' abilitazione Tap to Pay su iPhone (un permesso speciale che Apple concede caso per caso). Apple richiede inoltre l'integrazione con un payment service provider (PSP) supportato (la società che sposta effettivamente il denaro). Il PSP fornisce le configurazioni certificate del lettore caricate sul dispositivo del commerciante e si fa carico dell'onere della certificazione.

• Android offre agli sviluppatori un accesso NFC più aperto, ma un'app di accettazione dei pagamenti deve comunque essere valutata da un laboratorio indipendente riconosciuto dal PCI rispetto allo standard PCI MPoC (le regole di sicurezza del settore delle carte per i telefoni che fungono da terminali di pagamento).

• Al di sotto di entrambe le piattaforme, è necessario un rapporto di acquiring: un processore disposto a liquidare il denaro per i tuoi commercianti, nel rispetto delle regole dei circuiti delle carte.

Nulla di tutto questo può essere risolto semplicemente scrivendo codice migliore. Si tratta di burocrazia, contratti e code di revisione.

Come funziona il percorso di approvazione su iPhone?

In base ai requisiti pubblicati da Apple, il percorso è il seguente: possedere un account Apple Developer a livello aziendale (l'intestatario dell'account deve presentare personalmente la richiesta), collaborare con un PSP supportato per le tue aree geografiche, richiedere l'abilitazione, integrare l'API ProximityReader o l'SDK del tuo PSP, seguire le linee guida di progettazione di Apple per la schermata di pagamento e inviare l'app per la revisione. La documentazione di Apple rileva inoltre che la funzionalità è attiva solo nei paesi e nelle aree geografiche supportate, quindi la disponibilità stessa viene decisa per te, mercato per mercato.

Rileggi questo elenco come fondatore o commerciante, piuttosto che come sviluppatore. Nessuno di questi passaggi consiste nello "scrivere la funzionalità". La funzionalità è la parte più semplice; l'abilitazione è l'ostacolo principale.

Dove si concentra il lavoro una volta che il pagamento contactless funziona?

Un pagamento contactless approvato ti offre una transazione, non un punto vendita. Nel momento in cui il denaro si sposta, tutto ciò che ruota attorno al pagamento deve essere corretto: il carrello a cui si riferisce, le tasse sullo scontrino, il percorso di rimborso e una reportistica che si riconcili (ogni dollaro abbinato a una vendita, ogni giorno). Abbiamo riscontrato lo stesso divario quando abbiamo analizzato se sia possibile creare un POS con Lovable o Replit: generare un'interfaccia è rapido, ma è il livello commerciale sottostante a richiedere molto tempo.

Il tap to pay porta con sé anche alcune peculiarità operative. Nella nostra implementazione, la vendita deve essere registrata sullo stesso dispositivo che accetta il pagamento contactless, e funziona solo nell'app nativa, mai in un browser. Vincoli del genere non compaiono in nessun opuscolo. Li scopri, trovi soluzioni ingegneristiche e poi scrivi l'articolo di supporto. E quando un telefono sul bancone non basta più, ti trovi comunque a dover prendere decisioni reali sull'hardware.

Quindi, quanto è difficile creare la propria app tap to pay?

È difficile in un modo specifico: la scrittura del codice è la parte più piccola, mentre la partnership con il processore, l'abilitazione di Apple, la certificazione di laboratorio su Android e la revisione dell'app costituiscono la maggior parte del lavoro, e nessuna di queste risponde agli sforzi di sviluppo. Per noi ne è valsa la pena, perché una piattaforma POS distribuisce questo costo su ogni commerciante che la utilizza. Il tap to pay è ora un pulsante di pagamento che i nostri commercianti possono attivare, e accettare un pagamento Tap to Pay è una procedura al bancone in cinque passaggi. Se i pagamenti sono il tuo prodotto, questa trafila è il prezzo da pagare per entrare nel mercato. Se i pagamenti sono solo il modo in cui vieni pagato, creare la tua app tap to pay non ha senso dal punto di vista finanziario; la versione finita esiste già all'interno delle app POS, e le commissioni sono il vero elemento di confronto.

Regola generale: se una funzionalità ha bisogno dell'autorizzazione di qualcun altro per esistere, non c'è quantità di codice intelligente che possa abbreviare i tempi.